idnits 2.17.1 draft-ietf-msec-tesla-intro-04.txt: -(629): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(635): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(969): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(974): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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 3667, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1053. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1031. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1038. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1044. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == There are 4 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 237: '... 2. TESLA MUST be bootstrapped at...' RFC 2119 keyword, line 247: '... These MUST be cryptographically s...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 472 has weird spacing: '...ure, we see ...' == Line 473 has weird spacing: '...derived using...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 2004) is 7062 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 2246 (ref. '1') (Obsoleted by RFC 4346) -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '12' -- Possible downref: Non-RFC (?) normative reference: ref. '13' -- Possible downref: Non-RFC (?) normative reference: ref. '14' -- Possible downref: Non-RFC (?) normative reference: ref. '15' ** Obsolete normative reference: RFC 1305 (ref. '16') (Obsoleted by RFC 5905) -- Possible downref: Non-RFC (?) normative reference: ref. '17' -- Possible downref: Non-RFC (?) normative reference: ref. '18' -- Possible downref: Non-RFC (?) normative reference: ref. '19' -- Possible downref: Non-RFC (?) normative reference: ref. '20' -- Possible downref: Non-RFC (?) normative reference: ref. '21' -- Possible downref: Non-RFC (?) normative reference: ref. '22' ** Downref: Normative reference to an Informational RFC: RFC 1760 (ref. '23') Summary: 12 errors (**), 0 flaws (~~), 5 warnings (==), 27 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Perrig, Canetti, Song, Tygar, Briscoe 3 MSEC Working Group CMU / IBM / CMU / UC Berkeley / BT 4 INTERNET-DRAFT 5 Expires: June 2005 December 2004 7 TESLA: Multicast Source Authentication Transform Introduction 8 10 STATUS OF THIS MEMO 12 By submitting this Internet-Draft, I certify that any applicable 13 patent or other IPR claims of which I am aware have been disclosed, 14 or will be disclosed, and any of which I become aware will be 15 disclosed, in accordance with RFC 3668. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/1id-abstracts.html 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 Abstract 33 This document introduces TESLA, short for Timed Efficient Stream 34 Loss-tolerant Authentication. TESLA allows all receivers to check the 35 integrity and authenticate the source of each packet in multicast or 36 broadcast data streams. TESLA requires no trust between receivers; 37 uses low cost operations per packet at both sender and receiver; can 38 tolerate any level of loss without retransmissions; and requires no 39 per-receiver state at the sender. TESLA can protect receivers against 40 denial of service attacks in certain circumstances. Each receiver 41 must be loosely time synchronized with the source in order to verify 42 messages, but otherwise receivers need send no messages. TESLA alone 43 cannot support non-repudiation of the data source to third parties. 45 This informational document is intended to assist in writing 46 standardizable and secure specifications for protocols based on TESLA 47 in different contexts. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Notation . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Functionality . . . . . . . . . . . . . . . . . . . . . . 4 54 2.1. Threat Model and Security Guarantee . . . . . . . . . . . 5 55 2.2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 5 56 3. The Basic TESLA Protocol . . . . . . . . . . . . . . . . 6 57 3.1. Protocol sketch . . . . . . . . . . . . . . . . . . . . . 6 58 3.2. Sender Setup . . . . . . . . . . . . . . . . . . . . . . 7 59 3.3. Bootstrapping Receivers . . . . . . . . . . . . . . . . . 8 60 3.3.1. Time Synchronization. . . . . . . . . . . . . . . . . . . 9 61 3.4. Broadcasting Authenticated Messages . . . . . . . . . . . 9 62 3.5. Authentication at Receiver . . . . . . . . . . . . . . . 10 63 3.6. Determining the Key Disclosure Delay . . . . . . . . . . 12 64 3.7. An alternative delay description method . . . . . . . . . 12 65 3.8. Denial of service protection. . . . . . . . . . . . . . . 13 66 3.8.1. Additional group authentication . . . . . . . . . . . . . 14 67 3.8.2. Not re-using keys . . . . . . . . . . . . . . . . . . . . 15 68 3.8.3. Sender buffering. . . . . . . . . . . . . . . . . . . . . 17 69 3.9. Some extensions . . . . . . . . . . . . . . . . . . . . . 17 70 4. Layer placement . . . . . . . . . . . . . . . . . . . . . 17 71 5. IANA considerations . . . . . . . . . . . . . . . . . . . 18 72 6. Security considerations . . . . . . . . . . . . . . . . . 18 73 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 18 74 8. References . . . . . . . . . . . . . . . . . . . . . . . 18 75 A. Author Contact Information . . . . . . . . . . . . . . . 21 76 B. Full Copyright Statement, IPR Notice and Disclaimer . . . 22 78 1. Introduction 80 In multicast, a single packet can reach millions of receivers. This 81 unfortunately also introduces the danger that an attacker can 82 potentially also reach millions of receivers with a malicious packet. 83 Through source authentication, receivers can ensure that a received 84 multicast packet originates from the correct source. In these 85 respects, a multicast is equivalent to a broadcast to a superset of 86 the multicast receivers. 88 In unicast communication, we can achieve data authentication through 89 a simple mechanism: the sender and the receiver share a secret key to 90 compute a message authentication code (MAC) of all communicated data. 91 When a message with a correct MAC arrives, the receiver is assured 92 that the sender generated that message. Standard mechanisms achieve 93 unicast authentication this way, for example TLS or IPsec [1,2]. 95 Symmetric MAC authentication is not secure in a broadcast setting. 96 Consider a sender that broadcasts authentic data to mutually 97 mistrusting receivers. The symmetric MAC is not secure: every 98 receiver knows the MAC key, and hence could impersonate the sender 99 and forge messages to other receivers. Intuitively, we need an 100 asymmetric mechanism to achieve authenticated broadcast, such that 101 every receiver can verify the authenticity of messages it receives, 102 without being able to generate authentic messages. Achieving this in 103 an efficient way is a challenging problem [3]. 105 The standard approach to achieve such asymmetry for authentication is 106 to use asymmetric cryptography, e.g., a digital signature. Digital 107 signatures have the required asymmetric property: the sender 108 generates the signature with its private key, and all receivers can 109 verify the signature with the sender's public key, but a receiver 110 with the public key alone cannot generate a digital signature for a 111 new message. A digital signature provides non-repudiation, a stronger 112 property than authentication. However, digital signatures have a high 113 cost: they have a high computation overhead for both the sender and 114 the receiver, and most signatures also have a high bandwidth 115 overhead. Since we assume broadcast settings where the sender does 116 not retransmit lost packets, and the receiver still wants to 117 immediately authenticate each packet it receives, we would need to 118 attach a digital signature to each message. Because of the high 119 overhead of asymmetric cryptography, this approach would restrict us 120 to low-rate streams, and to senders and receivers with powerful 121 workstations. We can try to amortize one digital signature over 122 multiple messages. However, such an approach is still expensive in 123 contrast to symmetric cryptography, since symmetric cryptography is 124 in general 3 to 5 orders of magnitude more efficient than asymmetric 125 cryptography. In addition, the straight-forward amortization of one 126 digital signature over multiple packets requires reliability, as the 127 receiver needs to receive all packets to verify the signature. A 128 number of schemes that follow this approach are [4,5,6,7,8]. See [9] 129 for more details. 131 This document presents the Timed Efficient Stream Loss-tolerant 132 Authentication protocol (TESLA). TESLA uses mainly symmetric 133 cryptography, and uses time delayed key disclosure to achieve the 134 required asymmetry property. However, TESLA requires loosely 135 synchronized clocks between the sender and the receivers. See more 136 details in Section 3.3.1. Other schemes that follow a similar 137 approach to TESLA are [10,11,12]. 139 1.1. Notation 141 To denote the subscript or an index of a variable, we use the 142 underscore between the variable name and the index, e.g., the key K 143 with index i is K_i, the key K with index i+d is K_{i+d}. To write a 144 superscript we use the caret, e.g., function F with the argument x 145 executed i times is F^i(x). 147 2. Functionality 149 TESLA provides delayed per-packet data authentication and integrity 150 checking. The key idea to providing both efficiency and security is a 151 delayed disclosure of keys. The delayed key disclosure results in an 152 authentication delay. In practice, the delay is on the order of one 153 RTT (round-trip-time). 155 TESLA has the following properties: 157 o Low computation overhead for generation and verification of 158 authentication information 160 o Low communication overhead 162 o Limited buffering required for the sender and the receiver, hence 163 timely authentication for each individual packet 165 o Strong robustness to packet loss 167 o Scales to a large number of receivers 169 o Protects receivers against denial of service attacks in certain 170 circumstances if configured appropriately 172 o Each receiver cannot verify message authenticity unless it is 173 loosely time synchronized with the source, where synchronization 174 can take place at session set-up. Once the session is in 175 progress, receivers need not send any messages or 176 acknowledgements. 178 o Non-repudiation is not supported - each receiver can know that a 179 stream is from an authentic source, but not prove this to others 180 later. 182 TESLA can be used either in the network layer, or in the transport 183 layer, or in the application layer. Delayed authentication, however, 184 requires buffering of packets until authentication is completed. 185 Certain applications intolerant of delay may be willing to process 186 packets in parallel to being buffered awaiting authentication, as 187 long as roll-back is possible if packets are later found to be 188 unauthenticated. For instance, an interactive video may play-out 189 packets still awaiting authentication, but if they are later found to 190 be unauthenticated, it could stop further play-out and warn the 191 viewer that the last x msec were unauthenticated and should be 192 ignored. However, in the remainder of this document, for brevity, we 193 will assume packets are not processed in parallel to buffering. 195 2.1. Threat Model and Security Guarantee 197 We design TESLA to be secure against a powerful adversary with the 198 following capabilities: 200 o Full control over the network. The adversary can eavesdrop, 201 capture, drop, re-send, delay, and alter packets. 203 o Access to a fast network with negligible delay. 205 o The adversary's computational resources may be very large, but 206 not unbounded. In particular, this means that the adversary can 207 perform efficient computations, such as computing a reasonable 208 number of pseudo-random function applications and MACs with 209 negligible delay. Nonetheless, the adversary cannot find the key 210 of a pseudo-random function (or distinguish it from a random 211 function) with non-negligible probability. 213 The security property of TESLA guarantees that the receiver never 214 accepts M_i as an authentic message unless the sender really sent 215 M_i. A scheme that provides this guarantee is called a secure 216 broadcast authentication scheme. 218 Since TESLA expects the receiver to buffer packets before 219 authentication, the receiver needs to protect itself from a potential 220 denial-of-service (DOS) attack due to a flood of bogus packets (see 221 section 3.8). 223 2.2. Assumptions 225 TESLA makes the following assumptions in order to provide security: 227 1. The sender and the receiver must be able to loosely 228 synchronize. Specifically, each receiver must be able to 229 compute an upper bound on the lag of the receiver clock 230 relative to the sender clock. We denote this quantity by D_t. 231 (That is, D_t = sender time - receiver time). We note that an 232 upper bound on D_t can be easily obtained via a simple 233 two-message exchange. (Such an exchange can be piggybacked on 234 any secure session initiation protocol. Alternatively, standard 235 protocols such as NTP [16] can be used. 237 2. TESLA MUST be bootstrapped at session set-up through a 238 regular data authentication system. One option is to use a 239 digital signature algorithm for this purpose, in which case 240 the receiver is required to have an authentic copy of either 241 the sender's public key certificate or a root key certificate 242 in case of a PKI (public-key infrastructure). Alternatively, 243 this initialization step can be done using any secure session 244 initiation protocol. 246 3. TESLA uses cryptographic MAC and PRF (pseudo-random functions). 247 These MUST be cryptographically secure. Further details on the 248 instantiation of the MAC and PRF are in Section 3.4. 250 4. We would like to emphasize that the security of TESLA does NOT 251 rely on any assumptions on network propagation delay. 253 3. The Basic TESLA Protocol 255 TESLA is described in several academic publications: A book on 256 broadcast security [13], a journal paper [14], and two conference 257 papers [8,15]. Please refer to these publications for in-depth proofs 258 of security, experimental results, etc. 260 We first outline the main ideas behind TESLA. 262 3.1. Protocol sketch 264 As we argue in the introduction, broadcast authentication requires 265 a source of asymmetry. TESLA uses time for asymmetry. We first make 266 sure that the sender and receivers are loosely time synchronized as 267 described above. Next, the sender forms a one-way chain of keys, 268 where each key in chain is associated with a time interval (say, a 269 second). Here is the basic approach: 271 o The sender attaches a MAC to each packet. The MAC is computed 272 over the contents of the packet. For each packet, the sender 273 uses the current key from the one-way chain as a cryptographic 274 key to compute the MAC. 276 o The sender discloses a key from the one-way chain after some 277 pre-defined time delay. (e.g., the key used in time interval i 278 is disclosed at time interval i+3.) 280 o Each receiver receives the packet. Each receiver knows the 281 schedule for disclosing keys and, since it has an upper bound 282 on the local time at the sender, it can check that the key used 283 to compute the MAC was not yet disclosed by the sender. If so, 284 then the receiver buffers the packet. Otherwise the packet is 285 dropped due to inability to authenticate. Note that we do not 286 know for sure whether a "late packet" is a bogus one or simply 287 a delayed packet. We drop the packet since we are unable to 288 authenticate it. (Of course, an implementation may choose to 289 not drop packets and use them unauthenticated.) 291 o Each receiver checks that the disclosed key belongs to the 292 hash-chain (by checking against previously released keys in the 293 chain) and then checks the correctness of the MAC. If the MAC 294 is correct, the receiver accepts the packet. 296 Note that one-way chains have the property that if intermediate 297 values of the one-way chain are lost, they can be recomputed using 298 subsequent values in the chain . So, even if some key disclosures are 299 lost, a receiver can recover the corresponding keys and check the 300 correctness of earlier packets. 302 We now describe the stages of the basic TESLA protocol in this 303 order: sender setup, receiver bootstrap, sender transmission of 304 authenticated broadcast messages, and receiver authentication of 305 broadcast messages. 307 3.2. Sender Setup 309 The sender divides the time into uniform intervals of duration T_int. 310 The sender assigns one key from the one-way chain to each time 311 interval in sequence. 313 The sender determines the length N of the one-way chain K_0, K_1, 314 ..., K_N, and this length limits the maximum transmission duration 315 before a new one-way chain must be created. The sender picks a random 316 value for K_N. Using a pseudo-random function (PRF) f, the sender 317 constructs the one-way function F: F(k) = f_k(0). The rest of the 318 chain is computed recursively using K_i = F(K_{i+1}). Note that this 319 gives us K_i = F^{N-i}(K_N), so the receiver can compute any value in 320 the key chain from K_N even if is does not have intermediate values. 321 The key K_i will be used to authenticate packets sent in time 322 interval i. 324 Jakobsson [21], and Coppersmith and Jakobsson [22] present a storage 325 and computation efficient mechanism for one-way chains. For a chain 326 of length N, storage is about log(N) elements, and the computation 327 overhead to reconstruct each element is also about log(N). 329 The sender determines the duration of a time interval, T_int, and the 330 key disclosure delay, d. (T_int is measured in time units, say 331 milliseconds, and d is measured in number of time intervals. That is, 332 a key that is used for time interval i will be disclosed in time 333 interval i+d.) It is stressed that the scheme remains secure for any 334 values of T_int and d. Still, correct choice of T_int and d is 335 crucial for the usability of the scheme. The choice is influenced by 336 the estimated network delay, the length of the transmission, and the 337 tolerable delay at the receiver. T_int that is too short will cause 338 the keys to run out too soon. T_int that is too long will cause 339 excessive delay in authentication for some of the packets (those that 340 were sent at the beginning of a time period). Delay d that is too 341 short will cause too many packets to be unverifiable by the receiver. 342 Delay d that is too long will cause excessive delay in 343 authentication. 345 The sender estimates a reasonable upper bound on the network delay 346 between the sender and any receiver as m milliseconds. This includes 347 any delay expected in the stack (see section 4 on layer placement). 348 If the sender expects to send a packet every n milliseconds, then a 349 reasonable value for T_int is max(n,m). Based on T_int, a rule of 350 thumb for determining the key disclosure delay, d, is given in 351 section 3.6. 353 The above value for T_int is neither an upper or lower bound, merely 354 the value that reduces key change processing to a minimum without 355 causing authentication delay to be higher than necessary. So if the 356 application can tolerate higher authentication delay then T_int can 357 be made appropriately larger. Also, if m (or n) increases during the 358 session, perhaps due to congestion or a late joiner on a high delay 359 path, T_int need not be revised. 361 Finally, the sender needs to allow each receiver to synchronize its 362 time with the sender. See more details on how this can be done in 363 section 3.3.1. (It is stressed that estimating the network delay is a 364 separate task than the time synchronization between the sender and 365 the receivers.) 367 3.3. Bootstrapping Receivers 369 Before a receiver can authenticate messages with TESLA, it needs to 370 have: 372 o An upper bound D_t on the lag of its own clock with respect to 373 the clock of the sender. (That is, if the local time reading is 374 t, the current time reading at the sender is at most t+D_t.). 376 o One authenticated key of the one-way key chain. (Typically, this 377 will be the last key in the chain, i.e. K_0, this key will be 378 signed by the sender, and all receivers will verify the signature 379 against the public key of the signer. 381 o The disclosure schedule of keys: 383 - T_int, the interval duration. 384 - T_0, the start time of interval 1. 385 - N, the length of the one-way key chain. 386 - d, the key disclosure delay d (in number of intervals). 388 The receiver can perform the time synchronization and getting the 389 authenticated TESLA parameters in a two-round message exchange, as 390 described below. We stress again that time synchronization can be 391 performed as part of the registration protocol between any receiver 392 (including late joiners) and the sender, or between any receiver and 393 a group controller. 395 3.3.1. Time Synchronization 397 Various approaches exist for time synchronization [16,17,18,19]. 398 TESLA only requires the receiver to know an upper bound on the delay 399 of its local clock with respect to the sender's clock, so a simple 400 algorithm is sufficient. TESLA can be used with direct, indirect, and 401 delayed synchronization as three default options. The specific 402 synchronization method will be part of each instantiation of TESLA. 404 For completeness, we sketch a simple method for direct 405 synchronization between the sender and a receiver: 407 o The receiver sends a (sync t_r) message to the sender and records 408 its local time t_r at the moment of sending. 410 o Upon receipt of the (sync t_r) message, the sender records its 411 local time t_s and sends (synch, t_r,t_s) to the receiver. 413 o Upon receiving (synch,t_r,t_s), the receiver sets D_t = t_s - 414 t_r + S, where S is an estimated bound on the clock drift 415 throughout the duration of the session. 417 Note: 418 o Assuming that the messages are authentic (i.e., the message 419 received by the receiver was actually sent by the sender), and 420 assuming that the clock drift is at most S, then at any point 421 throughout the session we have that T_s < T_r + D_t, where T_s 422 is the current time at the sender and T_r is the current time at 423 the receiver. 425 o The exchange of sync messages needs to be authenticated. This can 426 be done in a number of ways, for instance a secure NTP protocol, 427 or in conjunction with a session set-up protocol. 429 For indirect time synchronization (eg, synchronization via a group 430 controller), the sender and the controller engage in a protocol for 431 finding the value D^0_t between the sender and the controller. Next, 432 each receiver R interacts with the group controller (say, when 433 registering to the group) and finds the value D^R_t between the group 434 controller and R. The overall value of D_t within R is set to the sum 435 D_t = D^R_t + D^0_t. 437 3.4. Broadcasting Authenticated Messages 439 Each key in the one-way key chain corresponds to a time interval. 440 Every time a sender broadcasts a message, it appends a MAC to the 441 message, using the key corresponding to the current time interval. 442 The key remains secret for the next d-1 intervals, so messages a 443 sender broadcasts in interval j effectively disclose key K_j-d. We 444 call d the key disclosure delay. 446 We do not want to use the same key multiple times in different 447 cryptographic operations, that is, to use key K_j to derive the 448 previous key of the one-way key chain K_{j-1}, and to use the same 449 key K_j as the key to compute the MACs in time interval j may 450 potentially lead to a cryptographic weakness. Using a pseudo-random 451 function (PRF) f', we construct the one-way function F': F'(k) = 452 f'_k(1). We use F' to derive the key to compute the MAC of messages 453 in each interval. The sender derives the MAC key as follows: K'_i = 454 F'(K_i). Figure 1 depicts the one-way key chain construction and MAC 455 key derivation. To broadcast message M_j in interval i the sender 456 constructs the packet 458 P_j = {M_j || i || MAC(K'_i,M_j) || K_{i-d}} 460 where || denotes concatenation. 462 F(K_i) F(K_{i+1}) F(K_{i+2}) 463 K_{i-1} <------- K_i <------- K_{i+1} <------- K_{i+2} 465 | | | 466 | F'(K_{i-1}) | F'(K_i) | F'(K_{i+1}) 467 | | | 468 V V V 470 K'_{i-1} K'_i K'_{i+1} 472 Figure 1: At the top of the figure, we see the one-way key chain 473 (derived using the one-way function F), and the derived MAC keys 474 (derived using the one-way function F'). 476 3.5. Authentication at Receiver 478 Once a sender discloses a key, we must assume that all parties might 479 have access to that key. An adversary could create a bogus message 480 and forge a MAC using the disclosed key. So whenever a packet 481 arrives, the receiver must verify that the MAC is based on a safe 482 key; a safe key is one that is still secret (only known by the 483 sender). We define a safe packet or safe message to be one with a MAC 484 that is computed with a safe key. 486 If a packet proves safe it will be buffered, only to be released when 487 its own key, disclosed in a later packet, proves its authenticity. 488 Although a newly arriving packet cannot immediately be authenticated, 489 it may disclose a new key so that earlier, buffered packets can be 490 authenticated. Any newly disclosed key must be checked to determine 491 whether it is genuine, then authentication of buffered packets that 492 have been waiting for it can proceed. 494 We now describe TESLA authentication at the receiver with more 495 precision, listing all of these steps in the exact order they should 496 be carried out: 498 1. Safe packet test: When the receiver receives packet P_j which 499 carries an interval index i, and a disclosed key K_{i-d}, it 500 first records local time T at which the packet arrived. The 501 receiver then computes an upper bound t_j on the sender's clock 502 at the time when the packet arrived: t_j = T + D_t. To test 503 whether the packet is safe, the receiver then computes the 504 highest interval x the sender could possibly be in, namely x = 505 floor((t_j - T_0) / T_int). The receiver verifies that x < i + 506 d (where i is the interval index), which implies that the 507 sender is not yet in the interval during which it discloses the 508 key K_i. 510 Even if the packet is safe, the receiver cannot yet verify the 511 authenticity of this packet sent in interval i without key K_i 512 that will be disclosed later. Instead, it adds the triplet ( i, 513 M_j, MAC( K'_i, M_j) ) to a buffer, and verifies the 514 authenticity after it learns K'_i. 516 If the packet is unsafe, then the receiver considers the packet 517 unauthenticated. It should discard unsafe packets but, at its 518 own risk it may choose to use them unverified. 520 2. New key index test: Next the receiver checks whether a key K_v 521 has already been disclosed with the same or later index v than 522 the current disclosed key K_{i-d}, that is with v >= i-d. 524 3. Key verification test: If the disclosed key index is new, the 525 receiver checks the legitimacy of K_{i-d} by verifying, for 526 some earlier disclosed key K_v (v1, 551 the receiver can also verify the authenticity of the stored packets 552 of intervals v+1 ... i-d-1. 554 3.6. Determining the Key Disclosure Delay 556 An important TESLA parameter is the key disclosure delay d. Although 557 the choice of the disclosure delay does not affect the security of 558 the system, it is an important performance factor. A short disclosure 559 delay will cause packets to lose their safety property, so receivers 560 will not be able to authenticate them; but a long disclosure delay 561 leads to a long authentication delay for receivers. We recommend 562 determining the disclosure delay as follows: in direct time 563 synchronization let the RTT, 2m, be a reasonable upper bound on the 564 round trip time between the sender and any receiver including worst 565 case congestion delay and worst case buffering delay in host stacks. 566 Then choose d = ceil( 2m / T_int) + 1. Note that rounding up the 567 quotient ensures that d >= 2. Also note that a disclosure delay of 568 one time interval (d=1) does not work. Consider packets sent close to 569 the boundary of the time interval: after the network propagation 570 delay and the receiver time synchronization error, a receiver will 571 not be able to authenticate the packet, because the sender will 572 already be in the next time interval, when it discloses the 573 corresponding key. 575 Measuring the delay to each receiver before determining m will still 576 not adequately predict the upper bound on delay to late joiners, or 577 where congestion delay rises later in the session. It may be adequate 578 to use a hard-coded historic estimate of worst-case delay (e.g. round 579 trip delays to any host on the intra-planetary Internet rarely exceed 580 500msec if routing remains stable). If such authentication delay is 581 too pessimistic, the adaptive approach of section 3.7 may be an 582 alternative, at the expense of extra packet overhead. 584 We stress that the security of TESLA does not rely on any assumptions 585 on network propagation delay: If the delay is longer than expected 586 then authentic packets may be considered unauthenticated. Still, no 587 inauthentic packet will be accepted as authentic. 589 3.7. An alternative delay description method 591 The above description instructs the sender to include the time 592 interval i in each packet. The receiver then uses i to determine the 593 time at which the key authenticating the packet is disclosed. This 594 method limits the the sender to a pre-determined schedule of 595 disclosing keys. 597 Alternatively, the sender may directly include in each packet the 598 time t_p at which it is going to disclose the key for this packet. 599 This way, the receiver does not need to know the duration of 600 intervals or the delay factor d. All the receiver needs to know is 601 the bound D_t on the clock skew and T_0, the sender's local time at 602 the initiation of the session. Then the receiver records the local 603 time T when the packet has arrived, and verifies that 605 T <= T_0 + D_t + t_p. 607 Else the packet is considered unauthenticated. 609 Another advantage of this method is that the sender is able to change 610 the duration of intervals and the key disclosure delay dynamically 611 throughout the session. It is stressed, however, that the interval 612 index i must still be included in the packet, to allow the receiver 613 to know which key K_i should be used to verify the packet. 615 3.8. Denial of service protection 617 Because TESLA authentication is delayed, receivers seem vulnerable to 618 flooding attacks that cause them to buffer excess packets, even 619 though they may eventually prove to be inauthentic. When TESLA is 620 deployed in an environment with a threat of flooding attacks, the 621 receiver can take a number of extra precautions. 623 First we list simple DoS mitigation precautions that can and should 624 be taken by any receiver independently of others, thus requiring no 625 changes to the protocol or sender behaviour. We precisely specify 626 where these extra steps interleave with the receiver authentication 627 steps already given in section 3.5. 629 �� o Session validity test: Before the safe packet test (step 1), check 630 that arriving packets have a valid source IP address and port 631 number for the session, that they do not replay a message already 632 received in the session and that they are not significantly larger 633 than the packet sizes expected in the session. 635 �� o Reasonable misordering test: Before the key verification test (step 636 3), check the disclosed key index i-d of the arriving packet is 637 within g of the previous highest disclosed key index v, thus for 638 example i-d-v <= g. g sets the threshold beyond which an out of 639 order key index is assumed to be malicious rather than just 640 misordered. Without this test an attacker could exploit the 641 iterated test in step 3 to make receivers consume inordinate CPU 642 time checking along the hash chain for what appear to be extremely 643 misordered packets. 645 Each receiver can independently adapt g to prevailing attack 646 conditions, for instance using the following algorithm. Initially, 647 g should be set to g_max (say 16). But whenever an arriving packet 648 fails the reasonable misordering test above or the key verification 649 test (step 3), g should be dropped to g_min (>0 and typically 1). 650 At each successful key verification (step 3), g should be 651 incremented by 1 unless it is already g_max. These precautions will 652 guarantee that sustained attack packets cannot cause the receiver 653 to execute more than an average of g_min hashes each, unless they 654 are paced against genuine packets. In the latter case attacks are 655 limited to g_max/(g_max-g_min) hashes per each genuine packet. 657 g_max and g_min should be chosen knowing that they limit the 658 average gap in a packet sequence to g.max(n,m)/n packets (see 659 section 3.2 for definitions of n & m). So with g=1, m=100msec RTT 660 and n=4msec inter-packet period, reordering would be limited to 661 gaps of 25 packet on average. Bigger naturally occurring gaps would 662 have to be written off as if they were losses. 664 Stronger DoS protection requires both senders and receivers to 665 arrange additional constraints on the protocol. Below we outline 666 three alternative extensions to basic TESLA; the first adding group 667 authentication, the second not re-using keys during a time interval 668 and the third moving buffering to the sender. 670 It is important to understand the applicability of each scheme, as 671 the first two schemes use slightly more (but bounded) resources in 672 order to prevent attackers from consuming unbounded resources. Adding 673 group authentication requires larger per packet overhead. Never 674 re-using a key requires both ends to process two hashes per packet 675 (rather than per time interval) and the sender must store or 676 re-generate a longer hash chain. The merits of each scheme, 677 summarised after describing each below, must be weighed against these 678 additional costs. 680 3.8.1. Additional group authentication 682 This scheme simply involves addition of a group MAC to every packet. 683 That is, a shared key K_g common to the whole group is communicated 684 as an additional step during receiver bootstrap (section 3.3). Then, 685 during broadcast of message M_j (section 3.4) the sender computes the 686 group MAC of each packet MAC(K_g, P_j), which it appends to the 687 packet header. Note that the group MAC covers the whole packet P_j, 688 that is the concatenation of the message M_j and the additional TESLA 689 authentication material, using the formula in section 3.4. 690 Immediately on packet arrival, each receiver can check that each 691 packet came from a group member, by recomputing and comparing the 692 group MAC. 694 It should be noted that TESLA source authentication is only necessary 695 when other group members cannot be trusted to refrain from spoofing 696 the source, otherwise simpler group authentication would be 697 sufficient. Therefore, additional group authentication will only make 698 sense in scenarios where other group members are trusted to refrain 699 from flooding the group, but they are still not trusted to refrain 700 from spoofing the source. 702 3.8.2. Not re-using keys 704 In TESLA as described so far, each MAC key was used repeatedly for 705 all the packets sent in a time interval. If instead the sender were 706 to guarantee never to use a MAC key more than once, each disclosed 707 key could assume an additional purpose on top of authenticating a 708 previously buffered packet. Each key would also immediately show each 709 receiver that the sender of each arriving packet knew the next key 710 back along the hash chain, which is now only ever disclosed once, 711 similar to S/KEY [23]. Therefore a reasonable receiver strategy would 712 be to discard any arriving packets that disclosed a key seen already. 713 The fill rate of the receiver's buffer would then be clocked by each 714 packet revealed by the genuine sender, preventing memory flooding 715 attacks. 717 An attacker with control of a network element or of a faster bypass 718 network could intercept messages and overtake or replace them with 719 different messages but the same keys. However, as long as packets are 720 only buffered if they also pass the delay safety test, such bogus 721 packets will fail TESLA verification after the disclosure delay. 722 Admittedly, receivers could be fooled into discarding genuine 723 messages that had been overtaken by bogus ones. But it is hard to 724 overtake messages without compromising a network element. And any 725 attacker that can compromise a network element can discard genuine 726 messages anyway. We will now describe this scheme in more detail. 728 For the sender the scheme is hardly different from TESLA. It merely 729 uses an interval duration short enough to ensure a new key back along 730 the hash chain for each packet. So the rule of thumb given in section 731 3.2 for an efficient re-keying interval T_int no longer applies. 732 Instead, T_int is simply n, the inter-arrival time between packets in 733 milliseconds. The rule of thumb for calculating d, the key disclosure 734 delay, remains unchanged from that given in section 3.6, or the 735 explicit disclosure delay method in section 3.7 can be used. 737 If the packet rate is likely to vary, for safety n should be taken as 738 the minimum inter-departure time between any two packets. (In fact, n 739 need not be so strict; it can be the minimum average packet 740 inter-departure time over any burst of d packets expected throughout 741 the session.) 743 Note that if the packet rate slows down, whenever no packets are sent 744 in a key change interval the key index must increment along the hash 745 chain once for each missed interval. (During a burst, if the less 746 strict definition of n above has been used, packets may need to 747 depart before their key change interval. The sender can safely 748 continue changing the key each packet, using keys from future key 749 intervals, because if n has been chosen as defined above, such bursts 750 will never sustain long enough to cause the associated key to be 751 disclosed less than the disclosure delay later.) 753 To be absolutely clear, the precise guarantees that the sender keeps 754 to by following the above guidance are: 756 o not to re-use a MAC key 758 o not to use a MAC key K_i after its time interval i 760 o not to disclose key K_i sooner than the disclosure delay d * T_int 761 following the packet it protects 763 Sender setup, receiver bootstrapping and broadcasting authenticated 764 messages are otherwise all identical to the descriptions in sections 765 3.2, 3.3 and 3.4 respectively. However, the following step must be 766 added to the receiver authentication steps in section 3.5: 768 o After step 2, if a packet arrives carrying a key index i-d that has 769 already been received, it should not be buffered. 771 This simple scheme would suffice against DoS, were it not for the 772 fact that a network sometimes misorders packets without being 773 compromised. Even without control of a network element, an attacker 774 can opportunistically exploit such openings to fool a receiver into 775 buffering a bogus packet and discarding a later genuine one. A 776 receiver can choose to set aside a fixed size cache and manage it to 777 minimise the chances of discarding a genuine packet. However, given 778 such vulnerabilities are rare and unpredictable, it is simpler to 779 count these events as additions to the network loss rate. As always, 780 TESLA authentication will still uncover any bogus packets after the 781 disclosure delay. 783 To summarise, avoiding re-using keys has the following properties, 784 even under extreme flooding attacks: 786 o After delayed TESLA authentication, packets arriving within the 787 disclosure delay will always be identified as authentic if they are 788 and inauthentic if they are not. 790 o The fill rate of the receiver's buffer is clocked by each packet 791 revealed by the genuine sender, preventing memory flooding attacks. 793 o An attacker with control of a network element can cause any loss 794 rate it chooses (but that's always true anyway). 796 o Where attackers do not have control of any network elements, the 797 effective loss rate is bounded by the sum of the network's actual 798 loss rate and its re-ordering rate. 800 3.8.3. Sender buffering 802 Buffering of packets can be moved to the sender side, then receivers 803 can authenticate packets immediately upon receipt. This method is 804 described in [15]. 806 3.9. Some extensions 808 Let us mention two salient extensions of the basic TESLA scheme. A 809 first extension allows having multiple TESLA authentication chains 810 for a single stream, where each chain uses a different delay for 811 disclosing the keys. This extension is typically used to deal with 812 heterogeneous network delays within a single multicast transmission. 813 A second extension allows having most of the buffering of packets at 814 the sender side (rather than at the receiver side). Both extensions 815 are described in [15]. 817 The requirement in TESLA to receive a key in a later packet for 818 authentication prevents a receiver from authenticating the last part 819 of a message. Thus, to enable authentication of the last part of a 820 message or of the last message before a transmission suspension, the 821 sender needs to send an empty message with the key to enable 822 authentication. 824 4. Layer placement 826 TESLA authentication can be performed at any layer in the networking 827 stack. Three natural places are in the network, transport, or the 828 application layer. We list some considerations regarding the choice 829 of layer: 831 o Performing TESLA in the network layer has the advantage that the 832 transport or application layer only receives authenticated data, 833 potentially aiding a reliability protocol and mitigating denial 834 of service attacks. (Indeed, reliable multicast tools based on 835 forward error correction are highly susceptible to denial of 836 service due to bogus packets.) 838 o Performing TESLA in either the transport or the application layer 839 has the advantage that the network layer remains unchanged; but 840 it has the potential drawback that packets are obtained by the 841 application layer only after being processed by the transport 842 layer. Consequently, if buffering is used in the transport then 843 this may introduce additional and unpredictable delays on top of 844 the unavoidable network delays. 846 o It should be kept in mind that, since TESLA relies upon timing of 847 packets, deploying TESLA on top of a protocol or layer which 848 aggressively buffers packets and hides the true packet arrival 849 time will significantly reduce TESLA's performance. 851 5. IANA Considerations 853 This document has no actions for IANA. 855 6. Security Considerations 857 See the academic publications on TESLA [8,14,20] for several 858 security analyses. Regarding the security of implementations, by 859 far the most delicate point is the verification of the timing 860 conditions. Care should be taken to make sure that: (a) the 861 value bound D_t on the clock skew is calculated according to the 862 spec at session set-up; (b) the receiver records the arrival time 863 of the packet as soon as possible after the packet's arrival, and 864 computes the safety condition correctly. 866 Finally, in common with all authentication schemes, if verification 867 is located separately from the ultimate destination application (e.g. 868 an IPSec tunnel end point), a trusted channel must be present between 869 verification and the application. For instance, the interface between 870 the verifier and the application might simply assume that packets 871 received by the application must have been verified by the verifier 872 (because otherwise they would have been dropped). The application is 873 then vulnerable to reception of packets that have managed to bypass 874 the verifier. 876 7. Acknowledgments 878 We would like to thank the following for their feedback and support: 879 Mike Luby, Mark Baugher, Mats Naslund, Dave McGrew, Ross Finlayson, 880 Sylvie Laniepce, Lakshminath Dondeti, Russ Housley and the IESG 881 reviewers 883 8. References 885 All references are informative. 887 [1] T. Dierks and C. Allen, "The TLS protocol version 1.0." Internet 888 Request for Comments RFC 2246, January 1999. Proposed standard. 890 [2] IPsec, "IP Security Protocol, IETF working group." 891 http://www.ietf.org/html.charters/ipsec-charter.html. 893 [3] D. Boneh, G. Durfee, and M. Franklin, "Lower bounds for multicast 894 message authentication," in Advances in Cryptology -- EUROCRYPT '2001 895 (B. Pfitzmann, ed.), vol. 2045 of Lecture Notes in Computer Science , 896 (Innsbruck, Austria), pp. 434--450, Springer-Verlag, Berlin Germany, 897 2001. 899 [4] R. Gennaro and P. Rohatgi, "How to Sign Digital Streams," tech. 900 rep., IBM T.J.Watson Research Center, 1997. 902 [5] P. Rohatgi, "A compact and fast hybrid signature scheme for mul- 903 ticast packet authentication," in 6th ACM Conference on Computer and 904 Communications Security , November 1999. 906 [6] P. Rohatgi, "A hybrid signature scheme for multicast source 907 authentication," Internet Draft, Internet Engineering Task Force, 908 June 1999. Work in progress. 910 [7] C. K. Wong and S. S. Lam, "Digital signatures for flows and mul- 911 ticasts," in Proc. IEEE ICNP `98 , 1998. 913 [8] A. Perrig, R. Canetti, J. Tygar, and D. X. Song, "Efficient 914 authentication and signing of multicast streams over lossy channels," 915 in IEEE Symposium on Security and Privacy , May 2000. 917 [9] R. Canetti, J. Garay, G. Itkis, D. Micciancio, M. Naor, and B. 918 Pinkas, "Multicast security: A taxonomy and some efficient construc- 919 tions," in Infocom '99 , 1999. 921 [10] S. Cheung, "An efficient message authentication scheme for link 922 state routing," in 13th Annual Computer Security Applications Confer- 923 ence , 1997. 925 [11] F. Bergadano, D. Cavagnino, and B. Crispo, "Chained stream 926 authentication," in Selected Areas in Cryptography 2000 , (Waterloo, 927 Canada), August 2000. A talk describing this scheme was given at IBM 928 Watson in August 1998. 930 [12] F. Bergadano, D. Cavalino, and B. Crispo, "Individual single 931 source authentication on the mbone," in ICME 2000 , Aug 2000. A talk 932 containing this work was given at IBM Watson, August 1998. 934 [13] A. Perrig and J. D. Tygar, Secure Broadcast Communication in 935 Wired and Wireless Networks Kluwer Academic Publishers, Oct. 2002. 936 ISBN 0792376501. 938 [14] A. Perrig, R. Canetti, J. D. Tygar, and D. Song, "The tesla 939 broadcast authentication protocol," RSA CryptoBytes , vol. 5, no. 940 Summer, 2002. 942 [15] A. Perrig, R. Canetti, D. Song, and J. D. Tygar, "Efficient and 943 secure source authentication for multicast," in Network and Dis- 944 tributed System Security Symposium, NDSS '01 , pp. 35--46, February 945 2001. 947 [16] D. L. Mills, "Network Time Protocol (Version 3) Specification, 948 Implementation and Analysis." Internet Request for Comments, March 949 1992. RFC 1305. 951 [17] B. Simons, J. Lundelius-Welch, and N. Lynch, "An overview of 952 clock synchronization," in Fault-Tolerant Distributed Computing (B. 953 Simons and A. Spector, eds.), no. 448 in LNCS, pp. 84--96, Springer- 954 Verlag, Berlin Germany, 1990. 956 [18] D. Mills, "Improved algorithms for synchronizing computer net- 957 work clocks," in Proceedings of the conference on Communications 958 architectures, protocols and applications, SIGCOMM 94 , (London, 959 England), pp. 317--327, 1994. 961 [19] L. Lamport and P. Melliar-Smith, "Synchronizing clocks in the 962 presence of faults," J. ACM , vol. 32, no. 1, pp. 52--78, 1985. 964 [20] Philippa Broadfoot and Gavin Lowe, "Analysing a Stream 965 Authentication Protocol using Model Checking. In Proceedings of the 966 7th European Symposium on Research in Computer Security (ESORICS), 967 2002. 969 [21] M. Jakobsson, "Fractal hash sequence representation and traver� 970 sal." Cryptology ePrint Archive, http://eprint.iacr.org/2002/001/, 971 Jan. 2002. 973 [22] D. Coppersmith and M. Jakobsson, "Almost optimal hash sequence 974 traversal," in Proceedings of the Sixth International Financial Cryp� 975 tography Conference (FC '02) , March 2002. 977 [23] N. Haller, "The S/KEY one-time password system," IETF RFC 1760, 978 February 1995. 980 A. Author Contact Information 982 Adrian Perrig 983 ECE Department 984 Carnegie Mellon University 985 Pittsburgh, PA 15218 986 US 987 perrig@cmu.edu 989 Ran Canetti 990 IBM Research 991 30 Saw Mill River Rd 992 Hawthorne, NY 10532 993 US 994 canetti@watson.ibm.com 996 Dawn Song 997 ECE Department 998 Carnegie Mellon University 999 Pittsburgh, PA 15218 1000 US 1001 dawnsong@cmu.edu 1003 Doug Tygar 1004 UC Berkeley 1005 102 South Hall, 4600 1006 Berkeley, CA 94720-4600 1007 US 1008 tygar@cs.berkeley.edu 1010 Bob Briscoe 1011 BT Research 1012 B54/77, BT Labs 1013 Martlesham Heath 1014 Ipswich, IP5 3RE 1015 UK 1016 bob.briscoe@bt.com 1017 B. Full Copyright Statement, IPR Notice and Disclaimer 1019 Copyright (C) The Internet Society (2004). This document is 1020 subject to the rights, licenses and restrictions contained in BCP 1021 78, and except as set forth therein, the authors retain all their 1022 rights. 1024 The IETF takes no position regarding the validity or scope of any 1025 Intellectual Property Rights or other rights that might be claimed 1026 to pertain to the implementation or use of the technology 1027 described in this document or the extent to which any license 1028 under such rights might or might not be available; nor does it 1029 represent that it has made any independent effort to identify any 1030 such rights. Information on the procedures with respect to rights 1031 in RFC documents can be found in BCP 78 and BCP 79. 1033 Copies of IPR disclosures made to the IETF Secretariat and any 1034 assurances of licenses to be made available, or the result of an 1035 attempt made to obtain a general license or permission for the use 1036 of such proprietary rights by implementers or users of this 1037 specification can be obtained from the IETF on-line IPR repository 1038 at http://www.ietf.org/ipr. 1040 The IETF invites any interested party to bring to its attention 1041 any copyrights, patents or patent applications, or other 1042 proprietary rights that may cover technology that may be required 1043 to implement this standard. Please address the information to the 1044 IETF at ietf-ipr@ietf.org. 1046 This document and the information contained herein are provided on 1047 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1048 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 1049 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 1050 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 1051 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 1052 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 1053 PARTICULAR PURPOSE. 1055 Change log (to be removed before publication) 1057 Main changes from draft-03 are: 1059 * Abstract 1061 Completely re-written to fit length guidelines 1063 * Section 2. Functionality: 1065 Added some clarification of the properties of TESLA 1067 * Section 3. The Basic TESLA Protocol 1069 Clarified why other TESLA publications are not normative 1070 references. 1072 * Section 3.2 Sender Setup 1074 Removed the duplicate rule of thumb for determining d, and replaced 1075 with reference forward to section 3.6. Replaced the imprecise 1076 definition of m with half the precise definition of RTT from 1077 section 3.6: 1079 o Section 3.2 said d = ceil(2m/T_int); 1081 o Section 3.6 said d = ceil(RTT/T_int) + 1 1083 o Section 3.2 defined m as "the average network delay" 1085 o Section 3.6 defined RTT as "a reasonable upper bound on the round 1086 trip time between the sender and any receiver" 1088 Added extra discussion of choice of key interval wrt congestion 1089 and late joiners. 1091 * Section 3.3 Bootstrapping Receivers 1093 Clarified that any receiver including late joiners can do time 1094 synchronization independently of others. 1096 * Section 3.5 Receiver authentication 1098 I had to completely re-arrange this to better allow the DoS 1099 section to refer back to it. This was tough. Firstly, I enumerated 1100 each step and gave them names (which should also help when other 1101 standards refer to this one), so I could interleave steps 1102 later in the DoS section. Secondly, the original text focused on 1103 one packet, staying with it during buffering then eventual 1104 verification. Instead, I traced the procedures that would be 1105 triggered as a packet arrived. This involved leaving it in the 1106 buffer for later and tracing through to the earlier packets it 1107 released from the buffer. 1109 * Section 3.6 Determining the Key Disclosure Delay 1111 Added extra discussion of choice of disclosure delay wrt congestion 1112 and late joiners. 1114 * Section 3.8 Denial of service protection 1116 Added whole new section 1118 * Section 6 Security Considerations 1120 Removed high level discussion of DoS 1122 * Throughout 1124 Spell-checked, fixed cross-referencing & nits, formatted. 1126 * Fixed all the other IESG comments in 1128 1131 IANA considerations, boilerplate stuff, Acknowledgements, other 1132 content issues covered in the relevant sections.