idnits 2.17.1 draft-faurite-rmt-tesla-for-alc-norm-01.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 1324. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1301. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1308. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1314. ** 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 (February 24, 2006) is 6633 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 1305 (Obsoleted by RFC 5905) ** Obsolete normative reference: RFC 2030 (Obsoleted by RFC 4330) ** 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 Summary: 10 errors (**), 0 flaws (~~), 4 warnings (==), 8 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: August 28, 2006 S. Faurite 5 INRIA 6 February 24, 2006 8 The Use of TESLA in the ALC and NORM Protocols 9 draft-faurite-rmt-tesla-for-alc-norm-01.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 August 28, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.1. Conventions Used in this Document . . . . . . . . . . . . 4 52 1.2. Terminology and Notations . . . . . . . . . . . . . . . . 4 53 2. Using TESLA with ALC and NORM . . . . . . . . . . . . . . . . 6 54 2.1. ALC and NORM Specificities that Impact TESLA . . . . . . . 6 55 2.2. The Need for Secure Time Synchronization . . . . . . . . . 7 56 2.2.1. Direct Time Synchronization . . . . . . . . . . . . . 7 57 2.2.2. Indirect Time Synchronization . . . . . . . . . . . . 7 58 3. Sender Operations . . . . . . . . . . . . . . . . . . . . . . 9 59 3.1. TESLA Parameters . . . . . . . . . . . . . . . . . . . . . 9 60 3.1.1. Key Chains . . . . . . . . . . . . . . . . . . . . . . 9 61 3.1.2. Time Interval Schedule . . . . . . . . . . . . . . . . 10 62 3.2. TESLA Messages and Authentication Tags . . . . . . . . . . 10 63 3.2.1. Bootstrap Information . . . . . . . . . . . . . . . . 10 64 3.2.2. Direct Time Synchronization Response . . . . . . . . . 11 65 3.2.3. Authentication Tag . . . . . . . . . . . . . . . . . . 12 66 3.3. TESLA Messages and Authentication Tag Format . . . . . . . 12 67 3.3.1. Bootstrap Information Format . . . . . . . . . . . . . 12 68 3.3.2. Format of a Direct Time Synchronization Response . . . 18 69 3.3.3. Format of a Standard Authentication Tag . . . . . . . 19 70 3.3.4. Format of an Authentication Tag with a New Key 71 Chain Commitment . . . . . . . . . . . . . . . . . . . 19 72 3.3.5. Format of an Authentication Tag with an Old Chain 73 Last Key Disclosure . . . . . . . . . . . . . . . . . 20 74 4. Receiver Operations . . . . . . . . . . . . . . . . . . . . . 21 75 4.1. Initialization of a Receiver . . . . . . . . . . . . . . . 21 76 4.1.1. Processing the Bootstrap Information Message . . . . . 21 77 4.1.2. Time Synchronization . . . . . . . . . . . . . . . . . 21 78 4.1.3. Format of a Direct Time Synchronization Request . . . 22 79 4.2. Authentication of Received Packets . . . . . . . . . . . . 23 80 5. Integration in the ALC and NORM Protocols . . . . . . . . . . 24 81 5.1. Authentication Header Extension Format . . . . . . . . . . 24 82 5.2. Use of Authentication Header Extensions . . . . . . . . . 26 83 5.3. Managing Silent Periods . . . . . . . . . . . . . . . . . 26 84 6. Security Considerations . . . . . . . . . . . . . . . . . . . 28 85 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 86 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 87 8.1. Normative References . . . . . . . . . . . . . . . . . . . 30 88 8.2. Informative References . . . . . . . . . . . . . . . . . . 30 89 Appendix A. IANA Considerations . . . . . . . . . . . . . . . . . 32 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 91 Intellectual Property and Copyright Statements . . . . . . . . . . 34 93 1. Introduction 95 Many applications using multicast and broadcast communications 96 require that each receiver be able to authenticate the source of any 97 packet it receives as well as its integrity. For instance, ALC 98 [RFC3450] and NORM [RFC3940] are two Content Delivery Protocols (CDP) 99 designed to transfer reliably objects (e.g. files) between a 100 session's sender and several receivers. 102 The NORM protocol is based on bidirectional transmissions. Each 103 receiver acknowledges data received or, in case of packet erasures, 104 asks for retransmissions. The ALC protocol defines unidirectional 105 transmissions. Reliability can be achieved by means of cyclic 106 transmissions of the content within a carousel, or by the use of 107 proactive Forward Error Correction codes (FEC), or by the joint use 108 of these mechanisms. Being purely unidirectional, ALC is massively 109 scalable, while NORM is intrinsically limited in terms of the number 110 of receivers that can be handled in a session. Both protocols have 111 in common the fact that they operate at application level, on top of 112 an erasure channel (e.g. the Internet) where packets can be lost 113 (erased) during the transmission. With some use case, an attacker 114 might impersonate the the ALC or NORM session's sender and inject 115 forged packets to the receivers, thereby corrupting the objects 116 reconstructed by the receivers. 118 The situation is much more complex in case of group communications 119 than it is with unicast communications. Indeed, in the latter case a 120 simple solution exist: the sender and receiver can share a secret key 121 to compute a Message Authentication Code (MAC) of all messages 122 exchanged. This is no longer feasible in case of a multicast and 123 broadcast communications since sharing a group key between the sender 124 and all receivers and using the same MAC scheme means that any group 125 member can impersonate the sender and send forged messages to other 126 receivers. 128 The usual solution to provide the source authentication and message 129 integrity services in case of multicast and broadcast communications 130 consists in relying on asymmetric cryptography and using digital 131 signatures. Yet this solution is limited by high computational costs 132 and high transmission overheads. The Timed Efficient Stream Loss- 133 tolerant Authentication protocol (TESLA) is an alternative solution 134 that provides the two required services, while being compatible with 135 high rate transmissions over lossy channels. 137 This document explains how to integrate the TESLA source 138 authentication and packet integrity protocol to the ALC and NORM 139 content delivery protocols. Since the FLUTE application [RFC3926] is 140 built on top of ALC, it will directly benefit from the services 141 offered by TESLA at the transport layer. 143 This specification only considers the authentication/integrity of the 144 packets generated by the session's sender. This specification does 145 not consider the packets that will be generated by receivers, for 146 instance the feedback packets of NORM. Adding authentication/ 147 integrity to the packets sent by receivers is outside the scope of 148 this document. Of course, this remark does not apply to ALC where 149 transmissions are purely unidirectional. 151 For more information on the TESLA protocol and its principles, please 152 refer to [RFC4082][Perrig.book04]. For more information on ALC, NORM 153 and FLUTE, please refer to [RFC3450], [RFC3940] and [RFC3926] 154 respectively, or [Neumann.ccr05]. 156 1.1. Conventions Used in this Document 158 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 159 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 160 document are to be interpreted as described in [RFC2119]. 162 1.2. Terminology and Notations 164 The following notations and definitions are used throughout this 165 document: 167 o PRF is the Pseudo Random Function; 169 o MAC is the Message Authentication Code; 171 o HMAC is the Keyed-Hash Message Authentication Code; 173 o t_s is the sender local time value at some absolute time; 175 o t_r is the receiver local time value at the same absolute time; 177 o T_0, the start time corresponding to the beginning of the session 178 (NTP timestamp); 180 o T_int, the interval duration (in milliseconds); 182 o d, the key disclosure delay (in number of intervals); 184 o D_t, the upper bound of the lag of the receiver's clock with 185 respect to the clock of the sender (in sign/second/sub-second 186 format); 188 o D^0_t, the upper bound on the lag of the sender's clock with 189 respect to the time reference in indirect time synchronization 190 mode; 192 o D^R_t, the upper bound on the lag of the receivers's clock with 193 respect to the time reference in indirect time synchronization 194 mode; 196 o N is the number of keys in a key chain. When several chains are 197 used, all chains MUST have the same length, N; 199 o N_tx_old_kck is the number of intervals during which the last key 200 of the old key chain SHOULD be sent, after switching to a new key 201 chain and waiting for the disclosure delay d; 203 o N_tx_new_kcc is the number of intervals during which the 204 commitment to a new key chain SHOULD be sent, before switching to 205 the new key chain; 207 2. Using TESLA with ALC and NORM 209 2.1. ALC and NORM Specificities that Impact TESLA 211 The ALC and NORM protocols have features and requirements that 212 largely impact the way TESLA can be used. 214 In case of ALC: 216 o ALC is massively scalable: nothing in the protocol specification 217 limits the number of receivers that join an on-going session. 218 Therefore an ALC session potentially includes a huge number (e.g. 219 millions or more) receivers; 221 o ALC can work on top of purely unidirectional transport channels: 222 this is one of the assets of ALC, and examples of unidirectional 223 channels include satellites (even if a back channel might exist) 224 and DVB-H systems. 226 o ALC defines an on-demand content delivery model [RFC3451] where 227 receivers can arrive at any time, at their own discretion, 228 download the content and leave the session. Other models (e.g. 229 push or streaming) are also defined. 231 o ALC sessions are potentially very long: with some use cases, in 232 particular in an on-demand mode, a session can last several months 233 during which the content is continuously transmitted within a 234 carousel. The content can either be static (e.g. in case of a 235 software update) or be regularly updated (e.g. in case of a web 236 site). 238 Depending on the use case, some of the above features may not apply. 239 For instance ALC can also be used over a bidirectional channel, or 240 ALC can be used for small groups. 242 In case of NORM: 244 o NORM has been designed for limited size sessions: unlike ALC, NORM 245 is not massively scalable. The reason is that NORM relies on 246 feedback messages and the source may collapse if the feedback 247 message rate is too high; 249 o NORM requires a bidirectional transport channel: yet the back 250 channel is not necessarily a high rate channel since only low to 251 medium rate control traffic will flow on it. Networks with an 252 asymmetric connectivity (e.g. a high rate satellite downlink and a 253 low-rate RTC based return channel) is appropriate; 255 2.2. The Need for Secure Time Synchronization 257 The security offered by TESLA relies heavily on time. Therefore the 258 session's sender and each receiver need to be time synchronized in a 259 secure way. To that purpose, two general methods exist: 261 o direct time synchronization, and 263 o indirect time synchronization. 265 2.2.1. Direct Time Synchronization 267 When direct time synchronization is used, each receiver asks the 268 sender for a time synchronization. The source then directly answers 269 to each request, signing the reply. The security of this 270 synchronization method is guaranteed, but there are two potential 271 issues: 273 o a bidirectional channel MUST exist between the source and each 274 receiver, 276 o the source may collapse it the rate of requests is too high. 278 Direct time synchronization may not be an issue with NORM since 279 bidirectional communications already take place. Yet direct time 280 synchronization may be an issue with ALC since: there might not be 281 any back channel to the session's sender and there are potentially a 282 huge number of receivers. 284 2.2.2. Indirect Time Synchronization 286 When indirect time synchronization is used, the source and each 287 receiver must synchronize securely via an external time reference. 288 Several possibilities exist: 290 o sender and receivers can synchronize through a NTPv3 (Network Time 291 Protocol version 3) [RFC1305] hierarchy of servers. The 292 authentication mechanism of NTPv3 MUST be used in order to 293 authenticate each NTP message individually. It prevents for 294 instance an attacker to impersonate a NTP server; 296 o similarly sender and receivers can synchronize through a NTPv4 297 (Network Time Protocol version 4) [I-D.ietf-ntp-ntpv4-proto] 298 hierarchy of servers. The Autokey security protocol of NTPv4 MUST 299 be used in order to authenticate each NTP message individually; 301 o similarly, they can synchronize through a SNTPv4 (Simple Network 302 Time Protocol version 4) [RFC2030] hierarchy of servers. The 303 authentication features of SNTPv4 must then be used. Note that 304 TESLA only needs a loose (but secure) time synchronization, which 305 is in line with the time synchronization service offered by SNTP; 307 o they can synchronize through a GPS or Galileo (or similar) device 308 that also provide a high precision time reference. This time 309 reference is in general trusted, yet depending on the use case, 310 this trust will or not be acceptable; 312 o they can synchronize thanks to a dedicated hardware, embedded on 313 each sender and receiver, that offers a clock with a time-drift 314 that is negligible in front of the TESLA time accuracy 315 requirements. This feature enables a device to synchronize its 316 embedded clock with the official time reference from time to time, 317 when feasible (in an extreme case once, at manufacturing time), 318 and then to remain autonomous for some time, depending on the 319 known maximum clock drift. 321 A bidirectional channel is required by the NTP/SNTP schemes. On the 322 opposite, with the GPS/Galileo and high precision clock schemes, no 323 such assumption is made. In situations where ALC is used on purely 324 unidirectional transport channels (Section 2.1), using the NTP/SNTP 325 schemes is not possible. Another aspect is the scalability 326 requirement of ALC, and to a lesser extent NORM. From this point of 327 view, the above mechanisms usually do not raise any problem, unlike 328 the direct synchronization schemes. Therefore, using indirect time 329 synchronization is a good candidate, in particular with ALC. 331 In any case, this document does not explain in details how to achieve 332 time synchronization, whether it follows a direct or indirect sheme. 333 The document only provides general guidelines. The details are 334 outside the scope of this document. 336 3. Sender Operations 338 3.1. TESLA Parameters 340 3.1.1. Key Chains 342 The sender divides the time into uniform intervals of duration T_int. 343 The sender then computes a one-way key chain of N keys, and assigns 344 one key from the chain to each interval in sequence. In order to 345 compute this chain, it must first select a Primary Key, choose two 346 PRF function F and F'. Then it computes all the previous keys using 347 K_{i-1} = F(K_i). The key for MAC calculation can then be derived 348 from the corresponding K_i key by K'_i=F'(K_i). The randomness of 349 the Primary key is vital to the security since no one should be able 350 to guess it. 352 The key chain has a finite length, N, so the TESLA session must 353 finish before the end of the key chain. But the longer the key 354 chain, the higher the memory and computation required to cope with 355 it. Another solution consists in switching to a new key chain when 356 necessary [Perrig.book04]. 358 To do so, the sender commits the new key chain with the old key 359 chain. Let's say that the old key chain stops at K_N and the new key 360 chain starts at K_{N+1}. Then the sender includes the commitment 361 F(K_{N+1}) to the new key chain to packets authenticated with the old 362 key chain. This commitment SHOULD be sent during N_tx_new_kcc 363 intervals before the end of the old key chain. Since several packets 364 are usually sent during a time interval, the sender should alternate 365 between sending a disclosed key of the old key chain, and the 366 commitment to the new key chain. 368 The receiver will keep the commitment, until the key K_{N+1} is 369 disclosed, at interval N+1+d. Then the receiver will be able to test 370 the validity of that key by computing F(K_{N+1}) and comparing it to 371 the commitment. 373 When the key chain is changed, it becomes impossible to recover a 374 previous key from the old key chain. This is a problem if the 375 receiver lost the packets disclosing the last key of the old key 376 chain. A solution consists in re-sending the last key, K_N, of the 377 old key chain. This SHOULD be done during N_tx_old_kck intervals at 378 the beginning of the new key chain, after the disclosure delay d. 379 Since several packets are usually sent during a time interval, the 380 sender should alternate between sending a disclosed key of the new 381 key chain, and the last key of the old key chain. 383 In some cases a receiver having experienced a very long disconnection 384 might have lost the commitment of the new chain. Therefore this 385 receiver will be unable to authenticate any packet related to the new 386 chain and all the following ones. The solution for this receiver to 387 catch up consists in receiving the bootstrap information. This can 388 happen by waiting for the next periodic transmission (indirect time 389 synchronization), by requesting it (direct time synchronization), or 390 through an external mechanism (Section 3.2.1). 392 3.1.2. Time Interval Schedule 394 The sender must determine the following parameters: 396 o T_0, the start time corresponding to the beginning of the session; 398 o T_int, the interval duration, usually ranging from 100 399 milliseconds to 1 second; 401 o d, the key disclosure delay (in number of intervals). It is the 402 time to wait before disclosing a key; 404 o N, the number of keys in a key chain; 406 The correct choice of T_int, d, and N is crucial for the usability of 407 the scheme. For instance, a T_int*d product that is too long will 408 cause excessive delay in the authentication process. A T_int*d 409 product that is is too short will cause too many packets to be 410 unverifiable by some receivers. A N*T_int product that is too small 411 will cause the sender to switch too often to new key chains. A N 412 that is too long with respect to the expected session duration, if 413 this latter is known, will require the sender to compute too many 414 keys without using them all. [RFC4082] (sections 3.2 and 3.6) gives 415 general guidelines for initializing these parameters. 417 3.2. TESLA Messages and Authentication Tags 419 At a sender, TESLA produces two types of signaling information: 421 o The bootstrap information, which is a digitally signed packet 422 containing all the information required to bootstrap TESLA at a 423 receiver. 425 o The authentication tag, which is sent in all packets (see 426 Section 5 for exceptions) and contains the MAC of the packet. 428 3.2.1. Bootstrap Information 430 In order to initialize the TESLA component at a receiver, the sender 431 must communicate some key information. This TESLA bootstrap 432 information MUST be securely transmitted, in particular a receiver 433 must be able to check the packet source and the packet integrity 434 using standard protocols. Any digital signature will do. 436 The bootstrap information can be sent in point to point after a 437 direct synchronization request/response exchange. The bootstrap 438 information can also be broadcast to all receivers, for instance 439 periodically, either in indirect time synchronization mode, or in 440 direct synchronization mode when a large number of clients arrive at 441 the same time. 443 More specifically, the periodic broadcast of the bootstrap 444 information message will be required when: 446 o the ALC session uses an ``on-demand'' mode, clients arriving at 447 their own discretion; 449 o some clients experience an intermittent connectivity. This is 450 particularly true when several key chains are used in an ALC or 451 NORM session, since there is a risk that some receivers loose all 452 the commitments to the new key chain. 454 A balance must be found between the signaling overhead and the 455 maximum initial waiting time at the receiver before starting the 456 delayed authentication process. A frequency of a few seconds for the 457 transmission of this bootstrap information is often a reasonable 458 value. 460 The bootstrap information message will be broadcast a limited number 461 of times, at the beginning of the session, in other cases. This is 462 true in particular with ALC or NORM sessions in ``push'' mode, when 463 all clients have a high probability of receiving at least one packet. 464 An extreme case consists in sending the bootstrap information only 465 once. 467 In some use cases, the bootstrapping information MAY be sent to 468 receivers through an external mechanism, for instance in a way 469 similar to [I-D.ietf-msec-bootstrapping-tesla]. How to do that is 470 outside the scope of this document. 472 3.2.2. Direct Time Synchronization Response 474 In direct time synchronization mode, receivers will send request 475 messages to the session's sender and include their local time, t_r 476 (Section 4.1.2). Upon receipt of this request, the sender records 477 its local time, t_s, and sends a response message that contains both 478 t_r and t_s ([RFC4082], section 3.3.1). This message is unicast to 479 the receiver. This direct time synchronization response message MUST 480 be securely transmitted, in particular the receiver must be able to 481 check the packet source and the packet integrity using standard 482 protocols. Any digital signature will do. 484 The Direct time synchronization messages are distinct from the 485 Bootstrap Information message. Therefore, if a large number of 486 receivers try to initialize their TESLA component at the same time (a 487 reasonable assumption in "push" mode), a single Bootstrap Information 488 message can be broadcast to all of them. Otherwise, a separate 489 Bootstrap Information message can be broadcast to each client after 490 the direct time synchronization response message. 492 The same session might include receivers that use either time 493 synchronization mode. A common Bootstrap Information message enables 494 both kinds of receivers to initialize their TESLA component. 496 3.2.3. Authentication Tag 498 Every authenticated packet must have an authentication tag, 499 containing the MAC of the message and either a disclosed key or a 500 commitment to a new key chain. 502 The computation of the MAC, MAC(K_i, M), includes the ALC or NORM 503 header (with the various header extensions) and the payload when 504 applicable. The UDP/IP/MAC headers are not included. During this 505 computation, the MAC(K_i, M) field of the authentication tag (see 506 Section 3.3.3 Section 3.3.4 Section 3.3.5) MUST be set to 0. 508 3.3. TESLA Messages and Authentication Tag Format 510 This section specifies the format of the various kinds of TESLA 511 messages and authentication tags sent by the session's sender. 513 3.3.1. Bootstrap Information Format 514 0 1 2 3 515 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 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 | KC PRF type | MAC PRF type | HMAC func type| Signature type| 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 | K_j Key length | Signature length | 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 |# cert |rsv|B|A| d | T_int | 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 | N | 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 | Id j of K_j | 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 | | 528 ~ K_j +-+-+-+-+-+-+-+-+ 529 | | Padding | 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 | | 532 + T_0 + 533 | (NTP timestamp) | 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 | | 536 ~ Signature extension ~ 537 | | 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 |P| | 540 ~-+ D^0_t (optional, present if A==1) ~ 541 | (NTP timestamp diff, with P==1 if positive) | 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 | | 544 ~ NTP extension (optional, present if B==1) ~ 545 | | 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 Figure 1: Bootstrap information format. 550 The format of the bootstrap information is depicted in Figure 1. 552 o The key chain PRF type is the reference number of the F function 553 used to calculate the key chain (Appendix A). 555 o The MAC PRF type is the reference number of the F' function used 556 to derive the MAC key from the key chain (Appendix A). 558 o The HMAC function type is the reference number of the function 559 used to compute the HMAC of the packets (Appendix A). 561 o Signature type is the reference number of the digital signature 562 used to authenticate this bootstrap information (Appendix A). 564 o # of certs is the number of certificates present in the signature 565 extension. 567 o A is a flag indicating whether or not the P flag and D^0_t field 568 are present (A==1) or not (A==0). The P flag and D^0_t field are 569 needed in indirect time synchronization mode. 571 o d is an unsigned integer that defines the key disclosure delay (in 572 number of intervals). d MUST be greater or equal to 2. 574 o T_int is an unsigned integer that defines the interval duration 575 (in milliseconds) one interval. 577 o K_j Key length is the length in bits of key K_j. 579 o Signature length is the number of bytes of the signature included 580 in the signature extension. 582 o N is the number of keys of the key chain. 584 o Id j of K_j is an unsigned integer corresponding to the index of 585 the interval of the key released in this bootstrap information. 586 For performance reasons, the sender SHOULD always send a bootstrap 587 information with the highest Id j possible since this will reduce 588 the number of computation for the receivers that join later. 590 o K_j is the key corresponding to the interval j. If i is the 591 current interval we MUST have: j < i - d. 593 o T_0 is the start time corresponding to the beginning of the 594 session, i.e. interval 0. It is a NTP timestamp. 596 o The signature extension is described in Section 3.3.1.1. It's 597 format depends on the "# of certs" field. 599 o P is optional. It is a flag indicating whether the D^0_t NTP 600 timestamp difference is positive (P==1) or negative (P==0). It is 601 only used in indirect time synchronization mode when the A flag is 602 1. 604 o D^0_t is optional. It is the upper bound on the lag of the 605 sender's clock with respect to the time reference. When several 606 time references are specified (e.g. several NTP servers), then 607 D^0_t is the maximum upper bound on the lag with each time 608 reference. D^0_t is composed of two unsigned integers, as with 609 NTP timestamps: the first 31 bits give the time difference in 610 seconds (the MSB is used by the P flag); the remaining 32 bits 611 give the sub-second time difference. It is only used in indirect 612 time synchronization mode when flag A==1. 614 * ----- Editor's note: a first alternative would be to use 615 floating point arithmetic, IEEE754 for carrying D^0_t. NTP 616 timestamp difference is usually performed with double floating 617 point arithmetic internally (at least in TESLA and NTPv4), so 618 it makes sense. Is single-precision (32-bit) sufficient or 619 should double-precision (64-bit) be used? A second alternative 620 would be to use a signed integer representing the difference in 621 sub-second units (e.g. in milliseconds). This is simple but it 622 requires NTP timestamp/ms conversions on both sides. ----- 624 o The NTP extension is optional is described in Section 3.3.1.2. 625 Its presence can be detected by the total length of the signature. 627 3.3.1.1. Signature Extension Format 629 The signature extension format when the "# of certs" field is 630 strictly greater than 0 (2 in this example) is: 632 0 1 2 3 633 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 634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 | cert 1 type | cert 1 length | | 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 637 | | 638 ~ Certificate 1 +-+-+-+-+-+-+-+-+ 639 | | Padding | 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 | cert 2 type | cert 2 length | | 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 643 | | 644 ~ Certificate 2 +-+-+-+-+-+-+-+-+ 645 | | Padding | 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 | | 648 ~ Signature +-+-+-+-+-+-+-+-+ 649 | | Padding | 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 Figure 2: Signature extension format when #cert==2. 654 In Figure 2: 656 o Type of certificate identifies the algorithm used for the 657 certificate (see Appendix A). 659 o The certificate length is the length in bytes of the certificate. 661 o The certificate field contains a certificate signed by an external 662 authority and that certifies the sender's public key. This field 663 is padded (with 0) up to a multiple of 32 bits. 665 o The signature is a digital signature using the type and length 666 specified in the main part of the bootstrap information message. 667 This field is padded (with 0) up to a multiple of 32 bits. 669 The signature extension format when the "# of certs" field is zero 670 (i.e. when no certificate is provided) is: 672 0 1 2 3 673 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 674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 675 | | 676 ~ Signature +-+-+-+-+-+-+-+-+ 677 | | Padding | 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 680 Figure 3: Signature extension format when #cert==0. 682 In Figure 3: 684 o The signature is a digital signature using the type and length 685 specified in the main part of the bootstrap information message. 686 This field is padded (with 0) up to a multiple of 32 bits. 688 3.3.1.2. NTP Extension Format 690 In some use cases, when NTP or SNTP is used in indirect 691 synchronization mode, the session's sender must have a way to 692 indicate to receivers one or more NTP server that will act as time 693 reference (Section 4.1.2). 695 0 1 2 3 696 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 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 | total length | # of entries | reserved (0) | cert type | 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 | FQDN 1 length | cert 1 length | | 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 702 | | 703 ~ NTP Server 1 FQDN +-+-+-+-+-+-+-+-+ 704 | | Padding | 705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 706 | | 707 ~ NTP Certificate 1 (optional) +-+-+-+-+-+-+-+-+ 708 | | Padding | 709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 | FQDN 2 length | cert 2 length | | 711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 712 | | 713 ~ NTP Server 2 FQDN +-+-+-+-+-+-+-+-+ 714 | | Padding | 715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 716 | | 717 ~ NTP Certificate 2 (optional) +-+-+-+-+-+-+-+-+ 718 | | Padding | 719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 Figure 4: Optional NTP information format, when two NTP servers are 722 specified 724 Figure 4 shows the optional NTP information format, when two NTP 725 servers are specified: 727 o The total length is the total length in units of 32 bit words of 728 this NTP information extension; 730 o The # of entries is the number of NTP entries; 732 o Type of certificates identifies the algorithm used for all the 733 certificates that may be provided (see Appendix A). 735 o The FQDN length is the number of bytes of the NTP server fully 736 qualified domain name; 738 o The NTP server FQDN is a string containing the NTP server Fully 739 Qualified Domain Name (e.g. "ntp.foo.bar."). This field is padded 740 (with 0) up to a multiple of 32 bits; 742 o The NTP Certificate is optional. The content delivery server can 743 use it to self-certify the NTP public key. The certificate length 744 indicates whether this field is present or not. This field is 745 padded (with 0) up to a multiple of 32 bits. 747 ----- Editor's note: Providing only NTP Server FQDN is perhaps too 748 limitative. It should be possible to use either a FQDN or an 749 IPv4/IPv6 address. ----- 751 3.3.2. Format of a Direct Time Synchronization Response 753 0 1 2 3 754 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 755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 | | 757 + t_s (NTP timestamp) + 758 | | 759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 | | 761 + t_r (NTP timestamp) + 762 | | 763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 764 |# cert | reserved (0) | 765 +-------+-------------------------------------------------------+ 766 | | 767 ~ Signature extension ~ 768 | | 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 771 Figure 5: Format of a Direct Time Synchronization Response 773 The response to a direct time synchronization request contains the 774 following information: 776 o t_s, the sender local time value when receiving the direct time 777 synchronization request message; 779 o t_r, the receiver local time value contained in the direct time 780 synchronization request message; 782 o # of certs is the number of certificates present in the signature 783 extension. 785 o The signature extension is described in Section 3.3.1.1. It's 786 format depends on the "# of certs" field. 788 3.3.3. Format of a Standard Authentication Tag 790 0 1 2 3 791 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 792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 793 | Id i of K_i | 794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 795 | | 796 ~ Disclosed Key K_{i-d} +-+-+-+-+-+-+-+-+ 797 | | Padding | 798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 799 | | 800 ~ MAC(K_i, M) +-+-+-+-+-+-+-+-+ 801 | | Padding | 802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 804 Figure 6: Format of the authentication tag 806 Figure 6 shows the format of the authentication tag: 808 o The Id i is the index of the key used for computing the MAC of 809 this packet. 811 o The disclosed key MUST be the key used for interval i-d. 813 o MAC(K_i, M) is the message authentication code of the current 814 packet, including the ALC or NORM header (including the header 815 extensions), plus the payload when applicable. 817 3.3.4. Format of an Authentication Tag with a New Key Chain Commitment 819 During the last N_tx_new_kcc intervals of the current key chain, the 820 sender MUST send a commitment to the next key chain. This is done by 821 replacing the disclosed key of the authentication tag with the new 822 key chain commitment, F(K_{N+1}). Figure 7 shows the corresponding 823 format. 825 0 1 2 3 826 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 827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 828 | Id i of K_i | 829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 830 | | 831 ~ New Key Commitment F(K_{N+1}) +-+-+-+-+-+-+-+-+ 832 | | Padding | 833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 834 | | 835 ~ MAC(K_i, M) +-+-+-+-+-+-+-+-+ 836 | | Padding | 837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 839 Figure 7: Format of the authentication tag with a new key chain 840 commitment 842 3.3.5. Format of an Authentication Tag with an Old Chain Last Key 843 Disclosure 845 During the first N_tx_old_kcc intervals of the new key chain after 846 the disclosing interval, d, the sender MUST send a commitment to the 847 old key chain. This is done by replacing the disclosed key of the 848 authentication tag with the last key of the old chain. Figure 8 849 shows the corresponding format. 851 0 1 2 3 852 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 853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 854 | Id i of K_i | 855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 856 | | 857 ~ Last Key of Old Chain, K_N +-+-+-+-+-+-+-+-+ 858 | | Padding | 859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 860 | | 861 ~ MAC(K_i, M) +-+-+-+-+-+-+-+-+ 862 | | Padding | 863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 865 Figure 8: Format of the authentication tag with an old chain last key 866 disclosure 868 4. Receiver Operations 870 4.1. Initialization of a Receiver 872 A receiver must be initialized before being able to authenticate the 873 source of incoming packets. Two actions must be performed: 875 o receive and process a bootstrap information message, and 877 o calculate an upper bound of the sender's local time, and to that 878 purpose, he must perform time synchronization. 880 4.1.1. Processing the Bootstrap Information Message 882 A receiver must first receive a packet containing the bootstrap 883 information, digitally signed by the sender, and verify its 884 signature. Because the packet is signed, the receiver also needs to 885 know the public key of the sender. The present document does not 886 specify how the public key of the sender is communicated reliably and 887 in a secure way to all possible receivers. Once the bootstrap 888 information has been verified, the receiver can initialize its TESLA 889 component. The receiver SHOULD then ignore the following bootstrap 890 information messages, if any. There is an exception though: when a 891 new key chain is used and a receiver missed all the commitments for 892 this new key chain, then this latter SHOULD process any new Bootstrap 893 information message. 895 Before TESLA has been initialized, a receiver MUST ignore all packets 896 other than the bootstrap information message. Yet, a receiver MAY 897 buffer incoming packets, recording the reception time of each packet, 898 and proceed with delayed authentication later, once the receiver will 899 be fully initialized. In that case, the buffer must be carefully 900 sized. 902 4.1.2. Time Synchronization 904 First of all, the receiver must know whether the ALC or NORM session 905 relies on direct or indirect synchronization. This information is 906 communicated by an out-of-band mechanism (for instance when 907 describing the various parameters of a FLUTE session in case of ALC). 908 In some cases, both mechanisms might be acceptable in the same 909 session. 911 4.1.2.1. Direct Time Synchronization 913 In case of a direct time synchronization, a receiver MUST first 914 synchronize with the sender. To that purpose, the receiver sends a 915 direct time synchronization request message. This message includes 916 the local time (NTP timestamp) at the receiver when sending the 917 message. This timestamp will be integrated in the sender's response. 918 Figure 9 details the direct time synchronization message format. 920 4.1.2.2. Indirect Time Synchronization 922 With the indirect time synchronization method, the sender MAY provide 923 in its bootstrap information, the URL or IP address of the NTP 924 server(s) he trusts along with an OPTIONAL certificate for each NTP 925 server. When several NTP servers are specified, a receiver MUST 926 choose one of them. This document does not specify how the choice is 927 made, but for the sake of scalability, the clients SHOULD NOT use the 928 same server if several possibilities are offered. The NTP 929 synchronization between the NTP server and the receiver MUST be 930 authenticated, either using the certificate provided by the content 931 delivery server, or another certificate the client may obtain for 932 this NTP server. 934 Then the receiver computes the time offset between itself and the NTP 935 server chosen. Note that the receiver does not need to update the 936 local time, since this operation would often require some privileges, 937 computing the time offset is sufficient. 939 Since the offset between the server and the time reference is 940 indicated in the bootstrap information message, the receiver can now 941 calculate an upper bound of the sender's local time. 943 4.1.3. Format of a Direct Time Synchronization Request 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_r (NTP timestamp) + 950 | | 951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 953 Figure 9: Format of a Direct Time Synchronization Request 955 The direct time synchronization request (Figure 9) contains the 956 following information: 958 o t_r, the receiver local time value when sending this direct time 959 synchronization request message; 961 4.2. Authentication of Received Packets 963 The receiver can now authenticate incoming packets. To that purpose, 964 he MUST follow different steps ([RFC4082] section 3.5): 966 1. The receiver parses the different packet headers. If the TESLA 967 authentication tag is not present, the receiver MUST reject the 968 packet. 970 2. Then proceed with the TESLA safe test: (1) check that the key 971 used to compute the MAC of this packet has not already been 972 disclosed, and (2) check the disclosed key by computing the 973 necessary number of PRF functions to obtain a previously safe 974 disclosed key. If any of these two tests fail, the receiver MUST 975 reject the packet. 977 3. Then, according to the [RFC3451], when applicable, perform 978 congestion control even if the packet has not yet been 979 authenticated. If this feature leads to a potential DoS attack, 980 it does not compromise the security features offered by TESLA and 981 enables a rapid reaction in front of congestion problems. 983 4. Then buffer the packet for a later authentication, once the 984 corresponding key will be received or deduced from another key. 986 5. If the disclosed key is a new one, then the receiver can 987 authenticate previously stored packets using this key or any key 988 derived from this one. 990 6. If a packet fails to be authenticated, then this packet MUST be 991 rejected. 993 7. If a packet is successfully authenticated, then the receiver 994 continues processing it. 996 ----- Editor's note: [RFC4082] explains that unauthenticated 997 packets SHOULD be destroyed, and if not this is at the own risk of 998 the receiver. We choose the other strategy, requiring that unsafe 999 packets be destroyed when the client decides to use TESLA. But 1000 the client can at any time choose to continue an ALC or NORM 1001 session in unsafe mode, ignoring TESLA extensions. ----- 1003 5. Integration in the ALC and NORM Protocols 1005 5.1. Authentication Header Extension Format 1007 The integration of TESLA in ALC or NORM is similar and relies on the 1008 header extension mechanism defined in both protocols. More precisely 1009 we further specify the EXT_AUTH=1 header extension defined in 1010 [RFC3451]. 1012 Several fields are added in addition to the HET (Header Extension 1013 Type) and HEL (Header Extension Length) fields (Figure 10). 1015 0 1 2 3 1016 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 1017 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1018 | HET (=1) | HEL |Scheme |Version| Resvd |Type | 1019 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1020 | | 1021 ~ ~ 1022 | Content | 1023 ~ ~ 1024 | | 1025 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1027 Figure 10: Format of the TESLA EXT_AUTH header extension. 1029 The fields of the TESLA EXT_AUTH header extension are: 1031 Scheme (Authentication Scheme) field (4 bits): 1033 "Scheme" identifies the source authentication scheme or protocol 1034 in use. The value 0 is reserved for TESLA. 1036 Version field (4 bits): 1038 "Version" identifies the version number of the TESLA 1039 authentication scheme. The value 0 is reserved for the current 1040 specification. 1042 Resvd (Reserved) field (5 bits): 1044 The "resvd" field is not used in the current specification and 1045 MUST be set to zero by the sender. 1047 Type field(3 bits): 1049 The "Type" field identifies the type of TESLA information carried 1050 in this header extension. This specification defines the 1051 following types: 1053 * 0: bootstrap information, sent by the sender periodically or 1054 after a direct synchronization request; 1056 * 1: authentication information for the on-going key chain, sent 1057 by the sender along with each packet; 1059 * 2: authentication information along with a new key chain 1060 commitment, sent by the sender when approaching the end of a 1061 key chain; 1063 * 3: authentication information along with an old key chain 1064 commitment, sent by the sender some time after moving to a new 1065 key chain; 1067 * 4: direct time synchronization request, sent by a NORM 1068 receiver. This type of message is invalid in case of an ALC 1069 session since ALC is restricted to unidirectional 1070 transmissions. Yet an external mechanism may provide the 1071 direct time synchronization functionality; 1073 * 5: direct synchronization response, sent by a NORM sender. 1074 This type of message is invalid in case of an ALC session since 1075 ALC is restricted to unidirectional transmissions. Yet an 1076 external mechanism may provide the direct time synchronization 1077 functionality; 1079 Content (variable length, multiple of 32 bits): 1081 This is the TESLA information carried in the header extension, 1082 whose type is given by the "Type" field. 1084 All receivers MUST recognize EXT_AUTH but MAY NOT be able to parse 1085 its content, for instance because they do not include the TESLA 1086 building block. In that case these receivers MUST ignore the 1087 EXT_AUTH extensions. In case of NORM, the packets sent by receivers 1088 MAY contain a direct synchronization request but MUST NOT contain any 1089 of the other four TESLA EXT_AUTH header extensions. 1091 All authentication schemes using the EXT_AUTH header extension MUST 1092 reserve the same 4 bit "Scheme" field after the HET/HEL fields. This 1093 way, several authentication schemes can be used in the same ALC or 1094 NORM session. For instance, in case of NORM, TESLA can be used for 1095 the downstream traffic while another scheme is used for the upstream 1096 traffic. 1098 5.2. Use of Authentication Header Extensions 1100 Each packet sent by the sessions's sender MUST contain exactly one 1101 TESLA EXT_AUTH header extension. 1103 The "bootstrap information" TESLA EXT_AUTH (Type=1) MUST be sent in a 1104 stand-alone control packet, rather than packets containing 1105 application data. The reason is the large size of this bootstrap 1106 information which largely increases the maximum ALC/LCT or NORM 1107 header size. By having the bootstrap information header extension in 1108 stand-alone packets, the maximum payload size of data packets is only 1109 affected by the unavoidable authentication tag, not by any additional 1110 large header extension sent at a low frequency. With NORM, the 1111 "bootstrap information" TESLA EXT_AUTH MUST be sent in a NORM_INFO 1112 message. With ALC, the "bootstrap information" TESLA EXT_AUTH MUST 1113 be sent in a control packet, i.e. containing no encoding symbol. 1115 The three "authentication information" TESLA EXT_AUTH (Type=2, 3, or 1116 4) MUST be attached to the ALC or NORM packet (data or control 1117 packet) that they protect. 1119 With NORM, the direct synchronization request extension header 1120 (Type=5) is sent by a receiver in a (TBD) NORM packet (see editor's 1121 note below). There is no authentication information header extension 1122 in this case since this draft only considers the authentication/ 1123 integrity of the packets generated by the session's sender. 1125 ----- Editor's note: what type of NORM packet should be used to 1126 that purpose? NORM_REPORT is one possibility. ----- 1128 With ALC, the direct synchronization request information cannot be 1129 included in an ALC packet, since ALC is restricted to unidirectional 1130 transmissions, from the session's sender to the receivers. An 1131 external mechanism, out of the scope of this document, must be used 1132 with ALC for carrying direct synchronization requests to the 1133 session's sender. 1135 5.3. Managing Silent Periods 1137 An ALC or NORM sender may stop transmitting packet for some time, for 1138 various reasons. It can be the end of the session and all packets 1139 have already been sent. The use scenario may consist in a succession 1140 of busy periods, when fresh objects are available, and silent 1141 periods. In both cases, this is an issue since the authentication of 1142 the packets sent during the last d intervals requires that the 1143 associated keys be revealed, which can only take place after d 1144 additional intervals. To resolve this boundary problem, the 1145 session's sender MUST sent null packets containing the TESLA EXT_AUTH 1146 header extension along with the authentication information (Type=2) 1147 for at least d intervals after the end of the regular ALC or NORM 1148 packet transmissions. The transmission rate of these null packets 1149 must be sufficient to guaranty that each receiver receives at least 1150 that containing the last key with a sufficiently high probability. 1152 6. Security Considerations 1154 The security of the TESLA protocol is discussed in [RFC4082]. 1155 Security considerations specific to its use in ALC and NORM remain 1156 TBD... 1158 7. Acknowledgments 1160 The authors are grateful to David L. Mills. MORE TO COME... 1162 8. References 1164 8.1. Normative References 1166 [RFC1305] Mills, D., "Network Time Protocol (Version 3) 1167 Specification, Implementation", RFC 1305, March 1992. 1169 [RFC2030] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 1170 for IPv4, IPv6 and OSI", RFC 2030, October 1996. 1172 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1173 Requirement Levels", RFC 2119, BCP 14, March 1997. 1175 [RFC3450] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., and J. 1176 Crowcroft, "Asynchronous Layered Coding (ALC) Protocol 1177 Instantiation", RFC 3450, December 2002. 1179 [RFC3451] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., Handley, 1180 M., and J. Crowcroft, "Layered Coding Transport (LCT) 1181 Building Block", RFC 3451, December 2002. 1183 [RFC3926] Paila, T., Luby, M., Lehtonen, R., Roca, V., and R. Walsh, 1184 "FLUTE - File Delivery over Unidirectional Transport", 1185 RFC 3926, October 2004. 1187 [RFC3940] Adamson, B., Bormann, C., Handley, M., and J. Macker, 1188 "Negative-acknowledgment (NACK)-Oriented Reliable 1189 Multicast (NORM) Protocol", RFC 3940, November 2004. 1191 [RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B. 1192 Briscoe, "Timed Efficient Stream Loss-Tolerant 1193 Authentication (TESLA): Multicast Source Authentication 1194 Transform Introduction", RFC 4082, June 2005. 1196 8.2. Informative References 1198 [I-D.ietf-msec-bootstrapping-tesla] 1199 Fries, S. and H. Tschofenig, "Bootstrapping TESLA", 1200 draft-ietf-msec-bootstrapping-tesla-03 (work in progress), 1201 January 2006. 1203 [I-D.ietf-ntp-ntpv4-proto] 1204 Burbank, J., "The Network Time Protocol Version 4 Protocol 1205 Specification", draft-ietf-ntp-ntpv4-proto-01 (work in 1206 progress), October 2005. 1208 [Neumann.ccr05] 1209 Neumann, C., Roca, V., and R. Walsh, "Large Scale Content 1210 Distribution Protocols", ACM Computer Communication 1211 Review (CCR), Vol. 35 No. 5, October 2005. 1213 [Perrig.book04] 1214 Perrig, A. and J. Tygar, "Secure Broadcast Communication 1215 in Wired and Wireless Networks", Kluwer Academic 1216 Publishers ISBN 0-7923-7650-1, 2004. 1218 Appendix A. IANA Considerations 1220 This document requires an IANA registration for the following 1221 attributes: 1223 Cryptographic pseudo-random function, TESLA-PRF: 1225 The currently defined values are: 1227 +--------------+-------+ 1228 | PRF function | Value | 1229 +--------------+-------+ 1230 | HMAC-SHA1 | 0 | 1231 +--------------+-------+ 1233 Cryptographic message authentication code (MAC): 1235 The currently defined values are: 1237 +--------------+-------+ 1238 | MAC function | Value | 1239 +--------------+-------+ 1240 | HMAC-SHA1 | 0 | 1241 +--------------+-------+ 1243 Signature type: 1245 The currently defined values are: 1247 +------------------------------------+-------+ 1248 | Signature type | Value | 1249 +------------------------------------+-------+ 1250 | PKCS #1: RSA Cryptography Standard | 0 | 1251 +------------------------------------+-------+ 1253 Certificate type: 1255 The currently defined values are: 1257 +------------------------------------+-------+ 1258 | Certificate type | Value | 1259 +------------------------------------+-------+ 1260 | PKCS #1: RSA Cryptography Standard | 0 | 1261 +------------------------------------+-------+ 1263 Authors' Addresses 1265 Vincent Roca 1266 INRIA 1267 655, av. de l'Europe 1268 Zirst; Montbonnot 1269 ST ISMIER cedex 38334 1270 France 1272 Email: vincent.roca@inrialpes.fr 1273 URI: http://planete.inrialpes.fr/~roca/ 1275 Aurelien Francillon 1276 INRIA 1277 655, av. de l'Europe 1278 Zirst; Montbonnot 1279 ST ISMIER cedex 38334 1280 France 1282 Email: aurelien.francillon@inrialpes.fr 1283 URI: http://planete.inrialpes.fr/~francill/ 1285 Sebastien Faurite 1286 INRIA 1287 655, av. de l'Europe 1288 Zirst; Montbonnot 1289 ST ISMIER cedex 38334 1290 France 1292 Intellectual Property Statement 1294 The IETF takes no position regarding the validity or scope of any 1295 Intellectual Property Rights or other rights that might be claimed to 1296 pertain to the implementation or use of the technology described in 1297 this document or the extent to which any license under such rights 1298 might or might not be available; nor does it represent that it has 1299 made any independent effort to identify any such rights. Information 1300 on the procedures with respect to rights in RFC documents can be 1301 found in BCP 78 and BCP 79. 1303 Copies of IPR disclosures made to the IETF Secretariat and any 1304 assurances of licenses to be made available, or the result of an 1305 attempt made to obtain a general license or permission for the use of 1306 such proprietary rights by implementers or users of this 1307 specification can be obtained from the IETF on-line IPR repository at 1308 http://www.ietf.org/ipr. 1310 The IETF invites any interested party to bring to its attention any 1311 copyrights, patents or patent applications, or other proprietary 1312 rights that may cover technology that may be required to implement 1313 this standard. Please address the information to the IETF at 1314 ietf-ipr@ietf.org. 1316 Disclaimer of Validity 1318 This document and the information contained herein are provided on an 1319 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1320 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1321 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1322 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1323 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1324 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1326 Copyright Statement 1328 Copyright (C) The Internet Society (2006). This document is subject 1329 to the rights, licenses and restrictions contained in BCP 78, and 1330 except as set forth therein, the authors retain all their rights. 1332 Acknowledgment 1334 Funding for the RFC Editor function is currently provided by the 1335 Internet Society.