idnits 2.17.1 draft-ietf-msec-tesla-for-alc-norm-00.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 on line 1557. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1534. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1541. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1547. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: All receivers MUST recognize EXT_AUTH but MAY NOT be able to parse its content, for instance because they do not include the TESLA building block. In that case these receivers MUST ignore the EXT_AUTH extensions. In case of NORM, the packets sent by receivers MAY contain a direct synchronization request but MUST NOT contain any of the other four TESLA EXT_AUTH header extensions. -- 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 (June 15, 2006) is 6524 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3450 (Obsoleted by RFC 5775) ** Obsolete normative reference: RFC 3451 (Obsoleted by RFC 5651) ** Obsolete normative reference: RFC 3926 (Obsoleted by RFC 6726) ** Obsolete normative reference: RFC 3940 (Obsoleted by RFC 5740) ** Downref: Normative reference to an Informational RFC: RFC 4082 == Outdated reference: A later version (-13) exists of draft-ietf-ntp-ntpv4-proto-01 -- Obsolete informational reference (is this intentional?): RFC 1305 (Obsoleted by RFC 5905) -- Obsolete informational reference (is this intentional?): RFC 4330 (Obsoleted by RFC 5905) Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RMT V. Roca 3 Internet-Draft A. Francillon 4 Expires: December 17, 2006 S. Faurite 5 INRIA 6 June 15, 2006 8 The Use of TESLA in the ALC and NORM Protocols 9 draft-ietf-msec-tesla-for-alc-norm-00.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 December 17, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 This document explains how to integrate the TESLA source 43 authentication and packet integrity protocol to the ALC and NORM 44 content delivery protocols. This document only considers the 45 authentication/integrity of the packets generated by the session's 46 sender. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 1.1. Conventions Used in this Document . . . . . . . . . . . . 5 52 1.2. Terminology and Notations . . . . . . . . . . . . . . . . 5 53 2. Using TESLA with ALC and NORM . . . . . . . . . . . . . . . . 7 54 2.1. ALC and NORM Specificities that Impact TESLA . . . . . . . 7 55 2.2. The Need for Secure Time Synchronization . . . . . . . . . 8 56 2.2.1. Direct Time Synchronization . . . . . . . . . . . . . 8 57 2.2.2. Indirect Time Synchronization . . . . . . . . . . . . 8 58 3. Time Synchronization and Delay Bound Calculations . . . . . . 10 59 3.1. Delay Bound Calculation in Direct Time Synchronization 60 Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 61 3.2. Delay Bound Calculation in Indirect time 62 Synchronization Mode . . . . . . . . . . . . . . . . . . . 10 63 3.2.1. Single time reference . . . . . . . . . . . . . . . . 10 64 3.2.2. Multiple time references . . . . . . . . . . . . . . . 11 65 4. Sender Operations . . . . . . . . . . . . . . . . . . . . . . 12 66 4.1. TESLA Parameters . . . . . . . . . . . . . . . . . . . . . 12 67 4.1.1. Key Chains . . . . . . . . . . . . . . . . . . . . . . 12 68 4.1.2. Time Interval Schedule . . . . . . . . . . . . . . . . 13 69 4.2. TESLA Messages and Authentication Tags . . . . . . . . . . 13 70 4.2.1. Bootstrap Information . . . . . . . . . . . . . . . . 14 71 4.2.2. Direct Time Synchronization Response . . . . . . . . . 14 72 4.2.3. Authentication Tag . . . . . . . . . . . . . . . . . . 15 73 4.3. TESLA Messages and Authentication Tag Format . . . . . . . 15 74 4.3.1. Bootstrap Information Format . . . . . . . . . . . . . 15 75 4.3.2. Format of a Direct Time Synchronization Response . . . 23 76 4.3.3. Format of a Standard Authentication Tag . . . . . . . 25 77 4.3.4. Format of an Authentication Tag with a New Key 78 Chain Commitment . . . . . . . . . . . . . . . . . . . 26 79 4.3.5. Format of an Authentication Tag with an Old Chain 80 Last Key Disclosure . . . . . . . . . . . . . . . . . 26 81 5. Receiver Operations . . . . . . . . . . . . . . . . . . . . . 28 82 5.1. Initialization of a Receiver . . . . . . . . . . . . . . . 28 83 5.1.1. Processing the Bootstrap Information Message . . . . . 28 84 5.1.2. Time Synchronization . . . . . . . . . . . . . . . . . 28 85 5.1.3. Format of a Direct Time Synchronization Request . . . 29 86 5.2. Authentication of Received Packets . . . . . . . . . . . . 30 87 6. Integration in the ALC and NORM Protocols . . . . . . . . . . 31 88 6.1. Authentication Header Extension Format . . . . . . . . . . 31 89 6.2. Use of Authentication Header Extensions . . . . . . . . . 33 90 6.3. Managing Silent Periods . . . . . . . . . . . . . . . . . 33 91 7. Security Considerations . . . . . . . . . . . . . . . . . . . 35 92 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36 93 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 94 9.1. Normative References . . . . . . . . . . . . . . . . . . . 37 95 9.2. Informative References . . . . . . . . . . . . . . . . . . 37 97 Appendix A. IANA Considerations . . . . . . . . . . . . . . . . . 39 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40 99 Intellectual Property and Copyright Statements . . . . . . . . . . 41 101 1. Introduction 103 Many applications using multicast and broadcast communications 104 require that each receiver be able to authenticate the source of any 105 packet it receives as well as its integrity. For instance, ALC 106 [RFC3450] and NORM [RFC3940] are two Content Delivery Protocols (CDP) 107 designed to transfer reliably objects (e.g. files) between a 108 session's sender and several receivers. 110 The NORM protocol is based on bidirectional transmissions. Each 111 receiver acknowledges data received or, in case of packet erasures, 112 asks for retransmissions. The ALC protocol defines unidirectional 113 transmissions. Reliability can be achieved by means of cyclic 114 transmissions of the content within a carousel, or by the use of 115 proactive Forward Error Correction codes (FEC), or by the joint use 116 of these mechanisms. Being purely unidirectional, ALC is massively 117 scalable, while NORM is intrinsically limited in terms of the number 118 of receivers that can be handled in a session. Both protocols have 119 in common the fact that they operate at application level, on top of 120 an erasure channel (e.g. the Internet) where packets can be lost 121 (erased) during the transmission. With some use case, an attacker 122 might impersonate the the ALC or NORM session's sender and inject 123 forged packets to the receivers, thereby corrupting the objects 124 reconstructed by the receivers. 126 The situation is much more complex in case of group communications 127 than it is with unicast communications. Indeed, in the latter case a 128 simple solution exist: the sender and receiver can share a secret key 129 to compute a Message Authentication Code (MAC) of all messages 130 exchanged. This is no longer feasible in case of a multicast and 131 broadcast communications since sharing a group key between the sender 132 and all receivers and using the same MAC scheme means that any group 133 member can impersonate the sender and send forged messages to other 134 receivers. 136 The usual solution to provide the source authentication and message 137 integrity services in case of multicast and broadcast communications 138 consists in relying on asymmetric cryptography and using digital 139 signatures. Yet this solution is limited by high computational costs 140 and high transmission overheads. The Timed Efficient Stream Loss- 141 tolerant Authentication protocol (TESLA) is an alternative solution 142 that provides the two required services, while being compatible with 143 high rate transmissions over lossy channels. 145 This document explains how to integrate the TESLA source 146 authentication and packet integrity protocol to the ALC and NORM 147 content delivery protocols. Since the FLUTE application [RFC3926] is 148 built on top of ALC, it will directly benefit from the services 149 offered by TESLA at the transport layer. 151 This specification only considers the authentication/integrity of the 152 packets generated by the session's sender. This specification does 153 not consider the packets that will be generated by receivers, for 154 instance the feedback packets of NORM. Adding authentication/ 155 integrity to the packets sent by receivers is outside the scope of 156 this document. Of course, this remark does not apply to ALC where 157 transmissions are purely unidirectional. 159 For more information on the TESLA protocol and its principles, please 160 refer to [RFC4082][Perrig04]. For more information on ALC, NORM and 161 FLUTE, please refer to [RFC3450], [RFC3940] and [RFC3926] 162 respectively, or [Neumann05]. 164 1.1. Conventions Used in this Document 166 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 167 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 168 document are to be interpreted as described in [RFC2119]. 170 1.2. Terminology and Notations 172 The following notations and definitions are used throughout this 173 document: 175 o PRF is the Pseudo Random Function; 177 o MAC is the Message Authentication Code; 179 o HMAC is the Keyed-Hash Message Authentication Code; 181 o t_s is the sender local time value at some absolute time; 183 o t_r is the receiver local time value at the same absolute time; 185 o T_0, the start time corresponding to the beginning of the session 186 (NTP timestamp); 188 o T_int, the interval duration (in milliseconds); 190 o d, the key disclosure delay (in number of intervals); 192 o D_t, the upper bound of the lag of the receiver's clock with 193 respect to the clock of the sender; 195 o S_sr, an estimated bound of the clock drift between the sender and 196 a receiver throughout the duration of the session; 198 o D^0_t, the upper bound of the lag of the sender's clock with 199 respect to the time reference in indirect time synchronization 200 mode; 202 o D^R_t, the upper bound of the lag of the receiver s's clock with 203 respect to the time reference in indirect time synchronization 204 mode; 206 o D_err, an upper bound of the time error between all the time 207 references, in indirect time synchronization mode; 209 o N is the number of keys in a key chain. When several chains are 210 used, all the chains MUST have the same length, N; 212 o N_tx_old_kck is the number of intervals during which the last key 213 of the old key chain SHOULD be sent, after switching to a new key 214 chain and waiting for the disclosure delay d; 216 o N_tx_new_kcc is the number of intervals during which the 217 commitment to a new key chain SHOULD be sent, before switching to 218 the new key chain; 220 2. Using TESLA with ALC and NORM 222 2.1. ALC and NORM Specificities that Impact TESLA 224 The ALC and NORM protocols have features and requirements that 225 largely impact the way TESLA can be used. 227 In case of ALC: 229 o ALC is massively scalable: nothing in the protocol specification 230 limits the number of receivers that join a session. Therefore an 231 ALC session potentially includes a huge number (e.g. millions or 232 more) of receivers; 234 o ALC can work on top of purely unidirectional transport channels: 235 this is one of the assets of ALC, and examples of unidirectional 236 channels include satellite (even if a back channel might exist in 237 some use cases) and DVB-H systems; 239 o ALC defines an on-demand content delivery model [RFC3451] where 240 receivers can arrive at any time, at their own discretion, 241 download the content and leave the session. Other models (e.g. 242 push or streaming) are also defined; 244 o ALC sessions are potentially very long: with some use cases a 245 session can last several months during which the content is 246 continuously transmitted within a carousel. The content can be 247 either static (e.g. a software update) or dynamic (e.g. a web 248 site). 250 Depending on the use case, some of the above features may not apply. 251 For instance ALC can also be used over a bidirectional channel, or 252 ALC can be used for small groups. 254 In case of NORM: 256 o NORM has been designed for limited or medium size sessions: 257 Indeed, NORM relies on feedback messages and the sender may 258 collapse if the feedback message rate is too high; 260 o NORM requires a bidirectional transport channel: the back channel 261 is not necessarily a high rate channel since only low to medium 262 rate control traffic will flow on it. Networks with an asymmetric 263 connectivity (e.g. a high rate satellite downlink and a low-rate 264 RTC based return channel) are appropriate; 266 2.2. The Need for Secure Time Synchronization 268 The security offered by TESLA relies heavily on time. Therefore the 269 session's sender and each receiver need to be time synchronized in a 270 secure way. To that purpose, two general methods exist: 272 o direct time synchronization, and 274 o indirect time synchronization. 276 2.2.1. Direct Time Synchronization 278 When direct time synchronization is used, each receiver asks the 279 sender for a time synchronization. To that purpose, a receiver sends 280 a "Direct Time Synchronization Request" (Section 5.1.3). The sender 281 then directly answers to each request with a "Direct Time 282 Synchronization Response" (Section 4.3.2), signing this reply. Upon 283 receiving this response, a receiver first verifies the signature, and 284 then calculates an upper bound of the lag of his clock with respect 285 to the clock of the sender, D_t. The details on how to calculate D_t 286 are given in Section 3.1. 288 This synchronization method is both simple and secure. Yet there are 289 two potential issues: 291 o a bidirectional channel MUST exist between the sender and each 292 receiver, 294 o the sender may collapse if the incoming request rate is too high. 296 Direct time synchronization is not be an issue with NORM since (1) 297 bidirectional communications already take place, and (2) NORM 298 scalability is anyway limited. 300 But direct time synchronization is potentially incompatible with ALC 301 since (1) there might not be a back channel to the session's sender, 302 and (2) there are potentially a huge number of receivers and 303 therefore a risk that the sender collapses. 305 2.2.2. Indirect Time Synchronization 307 When indirect time synchronization is used, the sender and each 308 receiver must synchronize securely via an external time reference. 309 Several possibilities exist: 311 o sender and receivers can synchronize through a NTPv3 (Network Time 312 Protocol version 3) [RFC1305] hierarchy of servers. The 313 authentication mechanism of NTPv3 MUST be used in order to 314 authenticate each NTP message individually. It prevents for 315 instance an attacker to impersonate a NTP server; 317 o similarly sender and receivers can synchronize through a NTPv4 318 (Network Time Protocol version 4) [I-D.ietf-ntp-ntpv4-proto] 319 hierarchy of servers. The Autokey security protocol of NTPv4 MUST 320 be used in order to authenticate each NTP message individually; 322 o similarly, they can synchronize through a SNTPv4 (Simple Network 323 Time Protocol version 4) [RFC4330] hierarchy of servers. The 324 authentication features of SNTPv4 must then be used. Note that 325 TESLA only needs a loose (but secure) time synchronization, which 326 is in line with the time synchronization service offered by SNTP; 328 o they can synchronize through a GPS or Galileo (or similar) device 329 that also provide a high precision time reference. This time 330 reference is in general trusted, yet depending on the use case, 331 this trust will or not be acceptable; 333 o they can synchronize thanks to a dedicated hardware, embedded on 334 each sender and receiver, that offers a clock with a time-drift 335 that is negligible in front of the TESLA time accuracy 336 requirements. This feature enables a device to synchronize its 337 embedded clock with the official time reference from time to time, 338 when feasible (in an extreme case once, at manufacturing time), 339 and then to remain autonomous for some time, depending on the 340 known maximum clock drift. 342 A bidirectional channel is required by the NTP/SNTP schemes. On the 343 opposite, with the GPS/Galileo and high precision clock schemes, no 344 such assumption is made. In situations where ALC is used on purely 345 unidirectional transport channels (Section 2.1), using the NTP/SNTP 346 schemes is not possible. Another aspect is the scalability 347 requirement of ALC, and to a lesser extent of NORM. From this point 348 of view, the above mechanisms usually do not raise any problem, 349 unlike the direct synchronization schemes. Therefore, using indirect 350 time synchronization is a good candidate, in particular with ALC. 352 The details on how to calculate an upper bound of the lag of a 353 receiver's clock with respect to the clock of the sender, D_t, are 354 given in Section 3.2. 356 3. Time Synchronization and Delay Bound Calculations 358 3.1. Delay Bound Calculation in Direct Time Synchronization Mode 360 In direct time synchronization mode, synchronization between a 361 receiver and the sender follows the following protocol [RFC4082]: 363 o The receiver sends a "Direct Time Synchronization Request" message 364 to the sender, that includes t_r, the receiver local time at the 365 moment of sending (Section 5.1.3). 367 o Upon receipt of this message, the sender records its local time, 368 t_s, and sends to the receiver a "Direct Time Synchronization 369 Response" that includes t_r (taken from the request) and t_s 370 (Section 4.3.2), signing this reply. 372 o Upon receiving this response, the receiver first verifies that he 373 actually sent a request with t_r and then checks the signature. 374 Then he calculates D_t = t_s - t_r + S_sr, where S_sr is an 375 estimated bound of the clock drift between the sender and the 376 receiver throughout the duration of the session. 378 After this initial synchronization, at any point throughout the 379 session, the receiver knows that: T_s < T_r + D_t, where T_s is the 380 current time at the sender and T_r is the current time at the 381 receiver. 383 3.2. Delay Bound Calculation in Indirect time Synchronization Mode 385 In indirect time synchronization, the sender and the receivers must 386 synchronize indirectly with one or several time references. 388 3.2.1. Single time reference 390 Let's assume that there is a single time reference. 392 o The sender uses a direct time synchronization scheme (but not 393 necessarily the one specified in Section 3.1, see below) to 394 calculate D^0_t, the upper bound of the lag of the sender's clock 395 with respect to the time reference. This D^0_t value is 396 communicated to receivers within the Bootstrap Information 397 (Section 4.3.1). 399 o Similarly, a receiver R uses a direct time synchronization scheme 400 (same remark) to calculate D^R_t, the upper bound of the lag of 401 the receiver's clock with respect to the time reference. 403 o Then, for receiver R, the overall upper bound of the lag of the 404 receiver's clock with respect to the clock of the sender, D_t, is 405 the sum: D_t = D^0_t + D^R_t. 407 The way to calculate D^0_t and D^R_t depends on the time 408 synchronization mechanism used (Section 2.2.2). In some cases, it is 409 part of the time synchronization scheme specifications. In other 410 cases, it can be achieved by using the direct time synchronization 411 scheme of Section 3.1, for instance in case synchronization is 412 achieved via a group controller [RFC4082]. 414 3.2.2. Multiple time references 416 Let's now assume that there are several time references (e.g. several 417 (S)NTP servers). The sender and receivers use the direct time 418 synchronization scheme to synchronize with the various time 419 references. It results in D^0_t and D^R_t. Let D_err be an upper 420 bound of the time error between all the time references. Then, the 421 overall value of D_t within receiver R is set to the sum: D_t = D^0_t 422 + D^R_t + D_err. 424 In some cases, the D_t value is is part of the time synchronization 425 scheme specifications. For instance NTPv3 [RFC1305] defines 426 algorithms that are "capable of accuracies in the order of a 427 millisecond, even after extended periods when synchronization to 428 primary reference sources has been lost". In practice, depending on 429 the NTP server stratum, the accuracy might be a little bit worse. In 430 that case, D_t = security_factor * (1ms + 1ms), where the 431 security_factor is meant to compensate several sources of inaccuracy 432 in NTP. 434 ----- Editor's note: is this D_t = security_factor * (1ms + 1ms) 435 rule of thumb acceptable? ----- 437 4. Sender Operations 439 4.1. TESLA Parameters 441 4.1.1. Key Chains 443 The sender divides the time into uniform intervals of duration T_int. 444 The sender then computes a one-way key chain of N keys, and assigns 445 one key from the chain to each interval in sequence. In order to 446 compute this chain, he must first select a Primary Key, K_N, and a 447 PRF function, f. The functions F and F' are then defined as: 448 F(k)=f_k(0) and F'(k)=f_k(1). The sender computes all the keys of 449 key chain, starting with K_N, using: K_{i-1} = F(K_i). The key for 450 MAC calculation can then be derived from the corresponding K_i key by 451 K'_i=F'(K_i). The randomness of the Primary Key, K_N, is vital to 452 the security since no one should be able to guess it. 454 The key chain has a finite length, N, so the TESLA session must 455 finish before the end of the key chain. But the longer the key 456 chain, the higher the memory and computation required to cope with 457 it. Another solution consists in switching to a new key chain when 458 necessary [Perrig04]. 460 To do so, the sender commits the new key chain with the old key 461 chain. Let's say that the old key chain stops at K_N and the new key 462 chain starts at K_{N+1}. Then the sender includes the commitment 463 F(K_{N+1}) to the new key chain to packets authenticated with the old 464 key chain. This commitment SHOULD be sent during N_tx_new_kcc 465 intervals before the end of the old key chain. Since several packets 466 are usually sent during a interval, the sender should alternate 467 between sending a disclosed key of the old key chain, and the 468 commitment to the new key chain. 470 The receiver will keep the commitment, until the key K_{N+1} is 471 disclosed, at interval N+1+d. Then the receiver will be able to test 472 the validity of that key by computing F(K_{N+1}) and comparing it to 473 the commitment. 475 When the key chain is changed, it becomes impossible to recover a 476 previous key from the old key chain. This is a problem if the 477 receiver lost the packets disclosing the last key of the old key 478 chain. A solution consists in re-sending the last key, K_N, of the 479 old key chain. This SHOULD be done during N_tx_old_kck intervals at 480 the beginning of the new key chain, after the disclosure delay d. 481 Since several packets are usually sent during a interval, the sender 482 should alternate between sending a disclosed key of the new key 483 chain, and the last key of the old key chain. 485 In some cases a receiver having experienced a very long disconnection 486 might have lost the commitment of the new chain. Therefore this 487 receiver will be unable to authenticate any packet related to the new 488 chain and all the following ones. The solution for this receiver to 489 catch up consists in receiving the bootstrap information. This can 490 happen by waiting for the next periodic transmission (indirect time 491 synchronization), by requesting it (direct time synchronization), or 492 through an external mechanism (Section 4.2.1). 494 4.1.2. Time Interval Schedule 496 The sender must determine the following parameters: 498 o T_0, the start time corresponding to the beginning of the session; 500 o T_int, the interval duration, usually ranging from 100 501 milliseconds to 1 second; 503 o d, the key disclosure delay (in number of intervals). It is the 504 time to wait before disclosing a key; 506 o N, the number of keys in a key chain; 508 The correct choice of T_int, d, and N is crucial for the usability of 509 the scheme. For instance, a T_int * d product that is too long will 510 cause excessive delay in the authentication process. A T_int * d 511 product that is is too short will cause too many packets to be 512 unverifiable by some receivers. A N * T_int product that is too 513 small will cause the sender to switch too often to new key chains. A 514 N that is too long with respect to the expected session duration, if 515 this latter is known, will require the sender to compute too many 516 keys without using them all. [RFC4082] (sections 3.2 and 3.6) gives 517 general guidelines for initializing these parameters. 519 4.2. TESLA Messages and Authentication Tags 521 At a sender, TESLA produces two types of signaling information: 523 o The bootstrap information, which is a digitally signed packet 524 containing all the information required to bootstrap TESLA at a 525 receiver. 527 o The authentication tag, which is sent in all packets (see 528 Section 6 for exceptions) and contains the MAC of the packet. 530 4.2.1. Bootstrap Information 532 In order to initialize the TESLA component at a receiver, the sender 533 must communicate some key information. This TESLA bootstrap 534 information MUST be securely transmitted, in particular a receiver 535 must be able to check the packet source and the packet integrity 536 using standard protocols. Any digital signature will do. 538 The bootstrap information can be sent in point to point after a 539 direct synchronization request/response exchange. The bootstrap 540 information can also be broadcast to all receivers, for instance 541 periodically, either in indirect time synchronization mode, or in 542 direct synchronization mode when a large number of clients arrive at 543 the same time. 545 More specifically, the periodic broadcast of the bootstrap 546 information message will be required when: 548 o the ALC session uses an ``on-demand'' mode, clients arriving at 549 their own discretion; 551 o some clients experience an intermittent connectivity. This is 552 particularly true when several key chains are used in an ALC or 553 NORM session, since there is a risk that some receivers loose all 554 the commitments to the new key chain. 556 A balance must be found between the signaling overhead and the 557 maximum initial waiting time at the receiver before starting the 558 delayed authentication process. A frequency of a few seconds for the 559 transmission of this bootstrap information is often a reasonable 560 value. 562 The bootstrap information message will be broadcast a limited number 563 of times, at the beginning of the session, in other cases. This is 564 true in particular with ALC or NORM sessions in ``push'' mode, when 565 all clients have a high probability of receiving at least one packet. 566 An extreme case consists in sending the bootstrap information only 567 once. 569 In some use cases, the bootstrapping information MAY be sent to 570 receivers through an external mechanism, for instance in a way 571 similar to [RFC4442]. How to do that is outside the scope of this 572 document. 574 4.2.2. Direct Time Synchronization Response 576 In Direct Time Synchronization, upon receipt of a synchronization 577 request, the sender records its local time, t_s, and sends a response 578 message that contains both t_r and t_s (Section 3.1). This message 579 is unicast to the receiver. This Direct Time Synchronization 580 Response message MUST be securely transmitted, in particular the 581 receiver must be able to check the packet source and the packet 582 integrity using standard protocols. Any digital signature will do. 583 The receiver MUST also be able the associate this response and his 584 request, which is the reason why t_r is included in the message. 586 The Direct Time Synchronization Response messages are distinct from 587 the Bootstrap Information message. Therefore, if a large number of 588 receivers try to initialize their TESLA component at the same time (a 589 reasonable assumption in "push" mode), a single Bootstrap Information 590 message can be broadcast to all of them. In some situations, when 591 there is a limited number of receivers, a sender can also choose to 592 unicast a Bootstrap Information message to each client individually 593 after the direct time synchronization response message. The choice 594 is outside the scope of this document. 596 Note that a single session might include receivers that use the 597 direct time synchronization mode while others use indirect mode. 599 4.2.3. Authentication Tag 601 Every authenticated packet must have an authentication tag 602 containing: 604 o the index of the interval (which is also the index of the key used 605 for computing the MAC of this packet: i; 607 o the MAC of the message: MAC(K'_i, M), where K'_i=F'(K_i); 609 o and either a disclosed key or a commitment to a new key chain. 611 The computation of MAC(K'_i, M), includes the ALC or NORM header 612 (with the various header extensions) and the payload when applicable. 613 The UDP/IP/MAC headers are not included. During this computation, 614 the MAC(K'_i, M) field of the authentication tag (see Section 4.3.3 615 Section 4.3.4 Section 4.3.5) MUST be set to 0. 617 4.3. TESLA Messages and Authentication Tag Format 619 This section specifies the format of the various kinds of TESLA 620 messages and authentication tags sent by the session's sender. 622 4.3.1. Bootstrap Information Format 623 0 1 2 3 624 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 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 | Reserved |A|B| # Cert| T_int | 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 | d | PRF Type | HMAC Func Type| Signature Type| 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 | Key length | Signature Length | 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 | | 633 + T_0 + 634 | (NTP timestamp) | 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 636 | N (Number of Keys in chain) | 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 | i (Interval Index of K_i) | 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 | | 641 ~ K_i +-+-+-+-+-+-+-+-+ 642 | | Padding | 643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 644 | | 645 ~ Signature Extension ~ 646 | | 647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 648 |P| | 649 +-+ D^0_t Extension (optional, present if A==1) + 650 | (NTP timestamp diff, positive if P==1, negative if p==0) | 651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 | | 653 ~ NTP Extension (optional, present if B==1) ~ 654 | | 655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 Figure 1: Bootstrap information format. 659 The format of the bootstrap information is depicted in Figure 1. The 660 fields are: 662 "Reserved" field (10 bits): 664 This is a reserved field that MUST be set to zero in this 665 specification. 667 "A" flag (1 bit): 669 A==0 indicates that the P flag and D^0_t field are not present. 670 A==1 indicates that the P flag and D^0_t field are present (which 671 is required in. indirect time synchronization mode). 673 "B" flag (1 bit): 675 B==0 indicates that the NTP extension is not present. B==1 676 indicates that the NTP extension is present. 678 "# Cert." (Number of Certificates) field (8 bits): 680 The "Number of Certificates" indicates the number of certificates 681 present in the signature extension. 683 "T_int" field (8 bits): 685 T_int is an unsigned integer that defines the interval duration 686 (in milliseconds). 688 "d" field (8 bits): 690 d is an unsigned integer that defines the key disclosure delay (in 691 number of intervals). d MUST be greater or equal to 2. 693 "PRF Type" field (8 bits): 695 "PRF Type" is the reference number of the f function used to 696 derive the F (for key chain) and F' (for MAC keys) functions 697 (Appendix A). 699 "HMAC Function Type" field (8 bits): 701 The "HMAC Function Type" is the reference number of the function 702 used to compute the HMAC of the packets (Appendix A). 704 "Signature Type" field (8 bits): 706 The "Signature Type" is the reference number (Appendix A) of the 707 digital signature used to authenticate this bootstrap information 708 and included in the "Signature Extension" field. 710 "Key Length" field (16 bits): 712 The "Key length" is an unsigned integer that indicates the length 713 in bits of key K_i. 715 "Signature Length" field (16 bits): 717 The "Signature Length" is an unsigned integer that indicates the 718 signature field size in bytes in the "Signature Extension" field. 719 This is NOT the total length of the "Signature Extension" field. 721 "T_0" field (8 bits): 723 "T_0" is an NTP timestamp that indicates the time when this 724 session begun. 726 "N" field (8 bits): 728 "N" is an unsigned integer that indicates the number of keys in 729 the current key chain. 731 "i" (Interval Index of K_i) field (8 bits): 733 "i" is an unsigned integer that indicates the interval index 734 associated to the key disclosed in this bootstrap information, 735 K_i. For performance reasons, the sender SHOULD always send a 736 bootstrap information with the highest possible index i since this 737 will reduce the required computation needed to validate key K_j 738 with j > i. But using interval O and K_0 remains valid. In any 739 case, if j is the current interval index, then it is REQUIRED that 740 i < j - d. 742 "K_i" field (variable size): 744 "K_i" is the key corresponding to interval i. If j is the current 745 interval index, then it is REQUIRED that i < j - d. 747 "Signature Extension" (variable size): 749 The "Signature Extension" is mandatory. It is described in 750 Section 4.3.1.1. It's format depends on the "# of certificates" 751 field, and the total length of this extension is given by 752 "Signature length". 754 "P" flag (optional, 1 bit if present): 756 The "P" flag is optional. It is only used in indirect time 757 synchronization mode when the A flag is 1. This flag indicates 758 whether the D^0_t NTP timestamp difference is positive (P==1) or 759 negative (P==0). 761 "D^0_t" field (optional, 63 bits if present): 763 The "D^0_t" field is optional (controlled by the A flag). It is 764 only used in indirect time synchronization mode. It is the upper 765 bound of the lag of the sender's clock with respect to the time 766 reference. When several time references are specified (e.g. 767 several NTP servers), then D^0_t is the maximum upper bound of the 768 lag with each time reference. D^0_t is composed of two unsigned 769 integers, as with NTP timestamps: the first 31 bits give the time 770 difference in seconds (the MSB is used by the P flag), and the 771 remaining 32 bits give the sub-second time difference. 773 ----- Editor's note: a first alternative would be to use 774 floating point arithmetic, IEEE754 for carrying D^0_t. NTP 775 timestamp difference is usually performed with double floating 776 point arithmetic internally (at least in TESLA and NTPv4), so 777 it makes sense. A second alternative would be to use a signed 778 integer representing the difference in sub-second units (e.g. 779 in milliseconds). This is simple but it requires NTP 780 timestamp/ms conversions on both sides. The use of the "P" 781 flag seems simpler... ----- 783 "NTP Extension" (optional, variable size): 785 The "NTP extension" is optional (controlled by the B flag). It is 786 only used in indirect time synchronization mode with (S)NTP 787 synchronization. This extension is described in Section 4.3.1.2. 789 Note that the first seven 32-bit words are mandatory fixed length 790 fields. The K_i and Signature Extension fields are mandatory but 791 variable length fields. The remaining D^0_t and NTP Extension fields 792 are only present in indirect synchronization mode. 794 4.3.1.1. Signature Extension Format 796 The Signature Extension format can be deduced from the "# Cert" and 797 "Signature Length" field of the Bootstrapping Information generic 798 part. Note that "Signature Length" only refers to the "Signature" 799 field and DOES NOT include the various certificates. 801 The signature extension format when the "# of certificates" field is 802 strictly greater than 0 (2 in this example) is: 804 0 1 2 3 805 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 806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 807 | Cert 1 Type | Cert 1 Length | | 808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 809 | | 810 ~ Certificate 1 +-+-+-+-+-+-+-+-+ 811 | | Padding | 812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 813 | Cert 2 Type | Cert 2 Length | | 814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 815 | | 816 ~ Certificate 2 +-+-+-+-+-+-+-+-+ 817 | | Padding | 818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 819 | | 820 ~ Signature +-+-+-+-+-+-+-+-+ 821 | | Padding | 822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 824 Figure 2: Signature extension format when #cert==2. 826 In Figure 2: 828 "Cert Type" (8 bits): 830 The type of certificate identifies the algorithm used for the 831 certificate (see Appendix A). 833 "Cert Length" (8 bits): 835 The certificate length is the length in bytes of the certificate. 837 "Certificate" field (variable size): 839 The certificate field contains a certificate signed by an external 840 authority and that certifies the sender's public key. This field 841 is padded (with 0) up to a multiple of 32 bits. 843 "Signature" field (variable size): 845 The signature field contains a digital signature using the type 846 and length specified in the main part of the bootstrap information 847 message. This field is padded (with 0) up to a multiple of 32 848 bits. 850 The signature extension format when the "# of certificates" field is 851 zero (i.e. when no certificate is provided) is: 853 0 1 2 3 854 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 855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 856 | | 857 ~ Signature +-+-+-+-+-+-+-+-+ 858 | | Padding | 859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 861 Figure 3: Signature extension format when #cert==0. 863 4.3.1.2. NTP Extension Format 865 In some use cases, when NTP or SNTP is used in indirect 866 synchronization mode, the session's sender must have a way to 867 indicate to receivers one or more NTP server that will act as time 868 reference (Section 5.1.2). 870 0 1 2 3 871 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 872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 873 | Total Length | # of Entries | Reserved (0) | Cert Type | 874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 875 | FQDN 1 Length | Cert 1 Length | | 876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 877 | | 878 ~ NTP Server 1 FQDN +-+-+-+-+-+-+-+-+ 879 | | Padding | 880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 881 | | 882 ~ NTP Certificate 1 (optional) +-+-+-+-+-+-+-+-+ 883 | | Padding | 884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 885 | FQDN 2 Length | Cert 2 Length | | 886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 887 | | 888 ~ NTP Server 2 FQDN +-+-+-+-+-+-+-+-+ 889 | | Padding | 890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 891 | | 892 ~ NTP Certificate 2 (optional) +-+-+-+-+-+-+-+-+ 893 | | Padding | 894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 896 Figure 4: Optional NTP information format, when two NTP servers are 897 specified 899 Figure 4 shows the optional NTP information format, when two NTP 900 servers are specified: 902 "Total Length" field (8 bits): 904 The total length is the total length in units of 32 bit words of 905 this NTP information extension. 907 "# of Entries" field (8 bits): 909 The number of entries is the number of NTP entries. 911 "Cert Type" field (8 bits): 913 The type of certificates identifies the algorithm used for all the 914 certificates that are provided in this NTP Extension (see 915 Appendix A). 917 "FQDN Length" field (8 bits): 919 The FQDN length is the number of bytes of the NTP server fully 920 qualified domain name. 922 "Cert Length" field (8 bits): 924 The certificate length is the length in bytes of the (optional) 925 NTP certificate field. 927 "NTP Server FQDN" field (variable length): 929 The NTP server FQDN is a string containing the NTP server Fully 930 Qualified Domain Name (e.g. "ntp.foo.bar."). This field is padded 931 (with 0) up to a multiple of 32 bits. 933 "NTP Certificate" field (optional, variable size): 935 The NTP Certificate is optional. The content delivery sender can 936 use it to self-certify the NTP public key. The "Certificate 937 Length" field indicates whether this field is present or not. 938 This field is padded (with 0) up to a multiple of 32 bits. 940 ----- Editor's note: Providing only NTP Server FQDN is perhaps too 941 limitative. It should be possible to use either a FQDN or an 942 IPv4/IPv6 address. ----- 944 4.3.2. Format of a Direct Time Synchronization Response 945 0 1 2 3 946 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 947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 948 | | 949 + t_s (NTP timestamp) + 950 | | 951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 952 | | 953 + t_r (NTP timestamp) + 954 | | 955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 956 | Rsvd | # Cert| Signature Type| Signature Length | 957 +-------+-------------------------------------------------------+ 958 | | 959 ~ Signature extension ~ 960 | | 961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 963 Figure 5: Format of a Direct Time Synchronization Response 965 The response to a direct time synchronization request contains the 966 following information: 968 "Rsvd" (Reserverd) field (4 bits): 970 This is a reserved field that MUST be set to zero in this 971 specification. 973 "t_s" (NTP timestamp, 64 bits): 975 t_s is an NTP timestamp that corresponds to the sender local time 976 value when receiving the direct time synchronization request 977 message; 979 "t_r" (NTP timestamp, 64 bits): 981 t_r is an NTP timestamp that contains the receiver local time 982 value received in the direct time synchronization request message; 984 "# Cert." (Number of Certificates) field (8 bits): 986 The Number of Certificates indicates the number of certificates 987 present in the signature extension. 989 "Signature Type" field (8 bits): 991 The Signature Type is the reference number (Appendix A) of the 992 digital signature used to authenticate this message and included 993 in the "Signature Extension" field. 995 "Signature Length" field (16 bits): 997 Signature length is an unsigned integer that indicates the 998 signature field size in bytes in the "Signature Extension" field. 999 This is NOT the total length of the "Signature Extension" field. 1001 "Signature Extension" (variable size): 1003 The signature extension is described in Section 4.3.1.1. It's 1004 format depends on the "# of certificates" field, and the total 1005 length of this extension is given by "Signature length". 1007 4.3.3. Format of a Standard Authentication Tag 1009 0 1 2 3 1010 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 1011 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1012 | i (Interval Index of K'_i) | 1013 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1014 | | 1015 ~ Disclosed Key K_{i-d} +-+-+-+-+-+-+-+-+ 1016 | | Padding | 1017 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1018 | | 1019 ~ MAC(K'_i, M) +-+-+-+-+-+-+-+-+ 1020 | | Padding | 1021 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1023 Figure 6: Format of the authentication tag 1025 Figure 6 shows the format of the authentication tag: 1027 "i" field (32 bits): 1029 i is the interval index associated to the key (K'_i) used to 1030 compute the MAC of this packet; 1032 "Disclosed Key" (variable size): 1034 The "Disclosed Key" is the key used for interval i-d: K_{i-d}; 1036 MAC(K'_i, M) (variable size): 1038 MAC(K'_i, M) is the message authentication code of the current 1039 packet, including the ALC or NORM header (with the header 1040 extensions if any) and the payload (when applicable). 1042 4.3.4. Format of an Authentication Tag with a New Key Chain Commitment 1044 During the last N_tx_new_kcc intervals of the current key chain, the 1045 sender MUST send a commitment to the next key chain. This is done by 1046 replacing the disclosed key of the authentication tag with the new 1047 key chain commitment, F(K_{N+1}). Figure 7 shows the corresponding 1048 format. 1050 0 1 2 3 1051 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 1052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1053 | i (Interval Index of K'_i) | 1054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1055 | | 1056 ~ New Key Commitment F(K_{N+1}) +-+-+-+-+-+-+-+-+ 1057 | | Padding | 1058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1059 | | 1060 ~ MAC(K'_i, M) +-+-+-+-+-+-+-+-+ 1061 | | Padding | 1062 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1064 Figure 7: Format of the authentication tag with a new key chain 1065 commitment 1067 4.3.5. Format of an Authentication Tag with an Old Chain Last Key 1068 Disclosure 1070 During the first N_tx_old_kck intervals of the new key chain after 1071 the disclosing interval, d, the sender MUST send a commitment to the 1072 old key chain. This is done by replacing the disclosed key of the 1073 authentication tag with the last key of the old chain. Figure 8 1074 shows the corresponding format. 1076 0 1 2 3 1077 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 1078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1079 | i (Interval Index of K'_i) | 1080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1081 | | 1082 ~ Last Key of Old Chain, K_N +-+-+-+-+-+-+-+-+ 1083 | | Padding | 1084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1085 | | 1086 ~ MAC(K'_i, M) +-+-+-+-+-+-+-+-+ 1087 | | Padding | 1088 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1090 Figure 8: Format of the authentication tag with an old chain last key 1091 disclosure 1093 5. Receiver Operations 1095 5.1. Initialization of a Receiver 1097 A receiver must be initialized before being able to authenticate the 1098 source of incoming packets. Two actions must be performed: 1100 o receive and process a bootstrap information message, and 1102 o calculate an upper bound of the sender's local time, and to that 1103 purpose, he must perform time synchronization. 1105 5.1.1. Processing the Bootstrap Information Message 1107 A receiver must first receive a packet containing the bootstrap 1108 information, digitally signed by the sender, and verify its 1109 signature. Because the packet is signed, the receiver also needs to 1110 know the public key of the sender. The present document does not 1111 specify how the public key of the sender is communicated reliably and 1112 in a secure way to all possible receivers. Once the bootstrap 1113 information has been verified, the receiver can initialize its TESLA 1114 component. The receiver SHOULD then ignore the following bootstrap 1115 information messages, if any. There is an exception though: when a 1116 new key chain is used and a receiver missed all the commitments for 1117 this new key chain, then this latter SHOULD process any new Bootstrap 1118 information message. 1120 Before TESLA has been initialized, a receiver MUST ignore all packets 1121 other than the bootstrap information message. Yet, a receiver MAY 1122 chose to buffer incoming packets, recording the reception time of 1123 each packet, and proceed with delayed authentication later, once the 1124 receiver will be fully initialized. In that case, the buffer must be 1125 carefully sized in order to prevent memory starvation (e.g. an 1126 attacker who sends faked packets before the session actually starts 1127 can exhaust the memory of receivers who do not limit the maximum 1128 incoming buffer size). 1130 5.1.2. Time Synchronization 1132 First of all, the receiver must know whether the ALC or NORM session 1133 relies on direct or indirect synchronization. This information is 1134 communicated by an out-of-band mechanism (for instance when 1135 describing the various parameters of a FLUTE session in case of ALC). 1136 In some cases, both mechanisms might be acceptable in the same 1137 session. 1139 5.1.2.1. Direct Time Synchronization 1141 In case of a direct time synchronization, a receiver MUST first 1142 synchronize with the sender. To that purpose, the receiver sends a 1143 direct time synchronization request message. This message includes 1144 the local time (NTP timestamp) at the receiver when sending the 1145 message. This timestamp will be integrated in the sender's response. 1146 Figure 9 details the direct time synchronization message format. 1148 5.1.2.2. Indirect Time Synchronization 1150 With the indirect time synchronization method, the sender MAY provide 1151 in its bootstrap information, the URL or IP address of the NTP 1152 server(s) he trusts along with an OPTIONAL certificate for each NTP 1153 server. When several NTP servers are specified, a receiver MUST 1154 choose one of them. This document does not specify how the choice is 1155 made, but for the sake of scalability, the clients SHOULD NOT use the 1156 same server if several possibilities are offered. The NTP 1157 synchronization between the NTP server and the receiver MUST be 1158 authenticated, either using the certificate provided by the content 1159 delivery server, or another certificate the client may obtain for 1160 this NTP server. 1162 Then the receiver computes the time offset between itself and the NTP 1163 server chosen. Note that the receiver does not need to update the 1164 local time, since this operation would often require some privileges, 1165 computing the time offset is sufficient. 1167 Since the offset between the server and the time reference is 1168 indicated in the bootstrap information message, the receiver can now 1169 calculate an upper bound of the sender's local time. 1171 5.1.3. Format of a Direct Time Synchronization Request 1173 0 1 2 3 1174 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 1175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1176 | | 1177 + t_r (NTP timestamp) + 1178 | | 1179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1181 Figure 9: Format of a Direct Time Synchronization Request 1183 The direct time synchronization request (Figure 9) contains the 1184 following information: 1186 "t_r" (NTP timestamp, 64 bits): 1188 t_r is an NTP timestamp that contains the receiver local time 1189 value when sending this direct time synchronization request 1190 message; 1192 5.2. Authentication of Received Packets 1194 The receiver can now authenticate incoming packets. To that purpose, 1195 he MUST follow different steps ([RFC4082] section 3.5): 1197 1. The receiver parses the different packet headers. If the TESLA 1198 authentication tag is not present, the receiver MUST reject the 1199 packet. 1201 2. Then proceed with the TESLA safe test: (1) check that the key 1202 used to compute the MAC of this packet has not already been 1203 disclosed, and (2) check the disclosed key by computing the 1204 necessary number of PRF functions to obtain a previously safe 1205 disclosed key. If any of these two tests fail, the receiver MUST 1206 reject the packet. 1208 3. Then, according to the [RFC3451], when applicable, perform 1209 congestion control even if the packet has not yet been 1210 authenticated. If this feature leads to a potential DoS attack, 1211 it does not compromise the security features offered by TESLA and 1212 enables a rapid reaction in front of congestion problems. 1214 4. Then buffer the packet for a later authentication, once the 1215 corresponding key will be received or deduced from another key. 1217 5. If the disclosed key is a new one, then the receiver can 1218 authenticate previously stored packets using this key or any key 1219 derived from this one. 1221 6. If a packet fails to be authenticated, then this packet MUST be 1222 rejected. 1224 7. If a packet is successfully authenticated, then the receiver 1225 continues processing it. 1227 ----- Editor's note: [RFC4082] explains that unauthenticated 1228 packets SHOULD be destroyed, and if not this is at the own risk of 1229 the receiver. We choose the other strategy, requiring that unsafe 1230 packets be destroyed when the client decides to use TESLA. But 1231 the client can at any time choose to continue an ALC or NORM 1232 session in unsafe mode, ignoring TESLA extensions. ----- 1234 6. Integration in the ALC and NORM Protocols 1236 6.1. Authentication Header Extension Format 1238 The integration of TESLA in ALC or NORM is similar and relies on the 1239 header extension mechanism defined in both protocols. More precisely 1240 we further specify the EXT_AUTH=1 header extension defined in 1241 [RFC3451]. 1243 Several fields are added in addition to the HET (Header Extension 1244 Type) and HEL (Header Extension Length) fields (Figure 10). 1246 0 1 2 3 1247 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 1248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1249 | HET (=1) | HEL |Scheme | V | Resvd |Type | 1250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1251 | | 1252 ~ ~ 1253 | Content | 1254 ~ ~ 1255 | | 1256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1258 Figure 10: Format of the TESLA EXT_AUTH header extension. 1260 The fields of the TESLA EXT_AUTH header extension are: 1262 "Scheme ID" (Authentication Scheme Identifier) field (4 bits): 1264 The "Scheme ID" identifies the source authentication scheme or 1265 protocol in use. The value 0 is reserved for TESLA. 1267 "V" (Version) field (4 bits): 1269 "Version" identifies the version number of the TESLA 1270 authentication scheme. The value 0 is reserved for the current 1271 specification of TESLA. 1273 "Resvd" (Reserved) field (5 bits): 1275 The "Resvd" field is not used in the current specification and 1276 MUST be set to zero by the sender. 1278 "Type" field(3 bits): 1280 The "Type" field identifies the type of TESLA information carried 1281 in this header extension. This specification defines the 1282 following types: 1284 * 0: bootstrap information, sent by the sender periodically or 1285 after a direct synchronization request; 1287 * 1: authentication information for the on-going key chain, sent 1288 by the sender along with each packet; 1290 * 2: authentication information along with a new key chain 1291 commitment, sent by the sender when approaching the end of a 1292 key chain; 1294 * 3: authentication information along with an old key chain 1295 commitment, sent by the sender some time after moving to a new 1296 key chain; 1298 * 4: direct time synchronization request, sent by a NORM 1299 receiver. This type of message is invalid in case of an ALC 1300 session since ALC is restricted to unidirectional 1301 transmissions. Yet an external mechanism may provide the 1302 direct time synchronization functionality; 1304 * 5: direct synchronization response, sent by a NORM sender. 1305 This type of message is invalid in case of an ALC session since 1306 ALC is restricted to unidirectional transmissions. Yet an 1307 external mechanism may provide the direct time synchronization 1308 functionality; 1310 "Content" field (variable length, multiple of 32 bits): 1312 This is the TESLA information carried in the header extension, 1313 whose type is given by the "Type" field. 1315 All receivers MUST recognize EXT_AUTH but MAY NOT be able to parse 1316 its content, for instance because they do not include the TESLA 1317 building block. In that case these receivers MUST ignore the 1318 EXT_AUTH extensions. In case of NORM, the packets sent by receivers 1319 MAY contain a direct synchronization request but MUST NOT contain any 1320 of the other four TESLA EXT_AUTH header extensions. 1322 All authentication schemes using the EXT_AUTH header extension MUST 1323 reserve the same 4 bit "Scheme" field after the HET/HEL fields. This 1324 way, several authentication schemes can be used in the same ALC or 1325 NORM session. For instance, in case of NORM, TESLA can be used for 1326 the downstream traffic while another scheme is used for the upstream 1327 traffic. 1329 6.2. Use of Authentication Header Extensions 1331 Each packet sent by the sessions's sender MUST contain exactly one 1332 TESLA EXT_AUTH header extension. 1334 The "bootstrap information" TESLA EXT_AUTH (Type=1) MUST be sent in a 1335 stand-alone control packet, rather than packets containing 1336 application data. The reason is the large size of this bootstrap 1337 information which largely increases the maximum ALC/LCT or NORM 1338 header size. By having the bootstrap information header extension in 1339 stand-alone packets, the maximum payload size of data packets is only 1340 affected by the unavoidable authentication tag, not by any additional 1341 large header extension sent at a low frequency. With NORM, the 1342 "bootstrap information" TESLA EXT_AUTH MUST be sent in a NORM_INFO 1343 message. With ALC, the "bootstrap information" TESLA EXT_AUTH MUST 1344 be sent in a control packet, i.e. containing no encoding symbol. 1346 The three "authentication information" TESLA EXT_AUTH (Type=2, 3, or 1347 4) MUST be attached to the ALC or NORM packet (data or control 1348 packet) that they protect. 1350 With NORM, the direct synchronization request extension header 1351 (Type=5) is sent by a receiver in a (TBD) NORM packet (see editor's 1352 note below). There is no authentication information header extension 1353 in this case since this draft only considers the authentication/ 1354 integrity of the packets generated by the session's sender. 1356 ----- Editor's note: what type of NORM packet should be used to 1357 that purpose? NORM_REPORT is one possibility. ----- 1359 With ALC, the direct synchronization request information cannot be 1360 included in an ALC packet, since ALC is restricted to unidirectional 1361 transmissions, from the session's sender to the receivers. An 1362 external mechanism, out of the scope of this document, must be used 1363 with ALC for carrying direct synchronization requests to the 1364 session's sender. 1366 6.3. Managing Silent Periods 1368 An ALC or NORM sender may stop transmitting packet for some time, for 1369 various reasons. It can be the end of the session and all packets 1370 have already been sent. The use scenario may consist in a succession 1371 of busy periods, when fresh objects are available, and silent 1372 periods. In both cases, this is an issue since the authentication of 1373 the packets sent during the last d intervals requires that the 1374 associated keys be revealed, which can only take place after d 1375 additional intervals. To resolve this boundary problem, the 1376 session's sender MUST sent null packets containing the TESLA EXT_AUTH 1377 header extension along with the authentication information (Type=2) 1378 for at least d intervals after the end of the regular ALC or NORM 1379 packet transmissions. The transmission rate of these null packets 1380 must be sufficient to guaranty that each receiver receives at least 1381 that containing the last key with a sufficiently high probability. 1383 7. Security Considerations 1385 The security of the TESLA protocol is discussed in [RFC4082]. 1386 Security considerations specific to its use in ALC and NORM remain 1387 TBD... 1389 8. Acknowledgments 1391 The authors are grateful to Ran Canetti and David L. Mills for their 1392 valuable comments when preparing this document. 1394 9. References 1396 9.1. Normative References 1398 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1399 Requirement Levels", RFC 2119, BCP 14, March 1997. 1401 [RFC3450] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., and J. 1402 Crowcroft, "Asynchronous Layered Coding (ALC) Protocol 1403 Instantiation", RFC 3450, December 2002. 1405 [RFC3451] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., Handley, 1406 M., and J. Crowcroft, "Layered Coding Transport (LCT) 1407 Building Block", RFC 3451, December 2002. 1409 [RFC3926] Paila, T., Luby, M., Lehtonen, R., Roca, V., and R. Walsh, 1410 "FLUTE - File Delivery over Unidirectional Transport", 1411 RFC 3926, October 2004. 1413 [RFC3940] Adamson, B., Bormann, C., Handley, M., and J. Macker, 1414 "Negative-acknowledgment (NACK)-Oriented Reliable 1415 Multicast (NORM) Protocol", RFC 3940, November 2004. 1417 [RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B. 1418 Briscoe, "Timed Efficient Stream Loss-Tolerant 1419 Authentication (TESLA): Multicast Source Authentication 1420 Transform Introduction", RFC 4082, June 2005. 1422 9.2. Informative References 1424 [I-D.ietf-ntp-ntpv4-proto] 1425 Burbank, J., "The Network Time Protocol Version 4 Protocol 1426 Specification", draft-ietf-ntp-ntpv4-proto-01.txt (work in 1427 progress), October 2005. 1429 [Neumann05] 1430 Neumann, C., Roca, V., and R. Walsh, "Large Scale Content 1431 Distribution Protocols", ACM Computer Communication 1432 Review (CCR), Vol. 35 No. 5, October 2005. 1434 [Perrig04] 1435 Perrig, A. and J. Tygar, "Secure Broadcast Communication 1436 in Wired and Wireless Networks", Kluwer Academic 1437 Publishers ISBN 0-7923-7650-1, 2004. 1439 [RFC1305] Mills, D., "Network Time Protocol (Version 3) 1440 Specification, Implementation", RFC 1305, March 1992. 1442 [RFC4330] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 1443 for IPv4, IPv6 and OSI", RFC 4330, January 2006. 1445 [RFC4442] Fries, S. and H. Tschofenig, "Bootstrapping Timed 1446 Efficient Stream Loss-Tolerant Authentication (TESLA)", 1447 RFC 4442, March 2006. 1449 Appendix A. IANA Considerations 1451 This document requires an IANA registration for the following 1452 attributes: 1454 Cryptographic pseudo-random function, TESLA-PRF: 1456 The currently defined values are: 1458 +--------------+-------+ 1459 | PRF function | Value | 1460 +--------------+-------+ 1461 | HMAC-SHA1 | 0 | 1462 +--------------+-------+ 1464 Cryptographic message authentication code (MAC): 1466 The currently defined values are: 1468 +--------------+-------+ 1469 | MAC function | Value | 1470 +--------------+-------+ 1471 | HMAC-SHA1 | 0 | 1472 +--------------+-------+ 1474 Signature type: 1476 The currently defined values are: 1478 +------------------------------------+-------+ 1479 | Signature type | Value | 1480 +------------------------------------+-------+ 1481 | PKCS #1: RSA Cryptography Standard | 0 | 1482 +------------------------------------+-------+ 1484 Certificate type: 1486 The currently defined values are: 1488 +------------------------------------+-------+ 1489 | Certificate type | Value | 1490 +------------------------------------+-------+ 1491 | PKCS #1: RSA Cryptography Standard | 0 | 1492 +------------------------------------+-------+ 1494 Authors' Addresses 1496 Vincent Roca 1497 INRIA 1498 655, av. de l'Europe 1499 Zirst; Montbonnot 1500 ST ISMIER cedex 38334 1501 France 1503 Email: vincent.roca@inrialpes.fr 1504 URI: http://planete.inrialpes.fr/~roca/ 1506 Aurelien Francillon 1507 INRIA 1508 655, av. de l'Europe 1509 Zirst; Montbonnot 1510 ST ISMIER cedex 38334 1511 France 1513 Email: aurelien.francillon@inrialpes.fr 1514 URI: http://planete.inrialpes.fr/~francill/ 1516 Sebastien Faurite 1517 INRIA 1518 655, av. de l'Europe 1519 Zirst; Montbonnot 1520 ST ISMIER cedex 38334 1521 France 1523 Email: faurite@lcpc.fr 1525 Intellectual Property Statement 1527 The IETF takes no position regarding the validity or scope of any 1528 Intellectual Property Rights or other rights that might be claimed to 1529 pertain to the implementation or use of the technology described in 1530 this document or the extent to which any license under such rights 1531 might or might not be available; nor does it represent that it has 1532 made any independent effort to identify any such rights. Information 1533 on the procedures with respect to rights in RFC documents can be 1534 found in BCP 78 and BCP 79. 1536 Copies of IPR disclosures made to the IETF Secretariat and any 1537 assurances of licenses to be made available, or the result of an 1538 attempt made to obtain a general license or permission for the use of 1539 such proprietary rights by implementers or users of this 1540 specification can be obtained from the IETF on-line IPR repository at 1541 http://www.ietf.org/ipr. 1543 The IETF invites any interested party to bring to its attention any 1544 copyrights, patents or patent applications, or other proprietary 1545 rights that may cover technology that may be required to implement 1546 this standard. Please address the information to the IETF at 1547 ietf-ipr@ietf.org. 1549 Disclaimer of Validity 1551 This document and the information contained herein are provided on an 1552 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1553 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1554 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1555 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1556 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1557 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1559 Copyright Statement 1561 Copyright (C) The Internet Society (2006). This document is subject 1562 to the rights, licenses and restrictions contained in BCP 78, and 1563 except as set forth therein, the authors retain all their rights. 1565 Acknowledgment 1567 Funding for the RFC Editor function is currently provided by the 1568 Internet Society.