idnits 2.17.1 draft-faurite-rmt-tesla-for-alc-norm-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1086. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1063. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1070. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1076. ** 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 : ---------------------------------------------------------------------------- ** There is 1 instance of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 719 has weird spacing: '...late an upper...' == Line 817 has weird spacing: '...another key....' == Line 870 has weird spacing: '... o the resvd...' -- 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: Each packet sent by the sender MUST contain exactly one of these header extensions when TESLA is used in an ALC or NORM session. All receivers MUST recognize EXT_AUTH but MAY NOT be able to parse its content, for instance because they do not use the TESLA building block, and in that case they SHOULD 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 authentication 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 (July 8, 2005) is 6865 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) == Unused Reference: 'RFC3450' is defined on line 950, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3450 (Obsoleted by RFC 5775) ** Obsolete normative reference: RFC 3451 (Obsoleted by RFC 5651) ** Downref: Normative reference to an Informational RFC: RFC 4082 Summary: 7 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RMT S. Faurite 3 Internet-Draft A. Francillon 4 Expires: January 9, 2006 V. Roca 5 INRIA 6 July 8, 2005 8 TESLA source authentication in the ALC and NORM protocols 9 draft-faurite-rmt-tesla-for-alc-norm-00.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 9, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 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 draft 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 Context . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.2 Conventions Used in this Document . . . . . . . . . . . . 4 53 1.3 Terminology and Notations . . . . . . . . . . . . . . . . 4 54 2. Time Synchronization . . . . . . . . . . . . . . . . . . . . . 6 55 2.1 Direct Time Synchronization . . . . . . . . . . . . . . . 6 56 2.2 Indirect Time Synchronization . . . . . . . . . . . . . . 6 57 2.2.1 Delay Bound Calculation in Indirect time 58 Synchronization . . . . . . . . . . . . . . . . . . . 7 59 3. Sender Operations . . . . . . . . . . . . . . . . . . . . . . 8 60 3.1 TESLA Parameters . . . . . . . . . . . . . . . . . . . . . 8 61 3.1.1 Time Interval Schedule . . . . . . . . . . . . . . . . 8 62 3.1.2 Key Chain . . . . . . . . . . . . . . . . . . . . . . 8 63 3.2 TESLA Signaling . . . . . . . . . . . . . . . . . . . . . 9 64 3.2.1 Bootstrap Information . . . . . . . . . . . . . . . . 9 65 3.2.2 Authentication Tag . . . . . . . . . . . . . . . . . . 10 66 3.3 Signaling Information Format . . . . . . . . . . . . . . . 10 67 3.3.1 Bootstrap Information Format . . . . . . . . . . . . . 10 68 3.3.2 Standard Authentication Tag Format . . . . . . . . . . 16 69 3.3.3 Authentication Tag Format with a New key Chain 70 Commitment . . . . . . . . . . . . . . . . . . . . . . 16 71 3.3.4 Authentication Tag Format with an Old Key Chain 72 Commitment . . . . . . . . . . . . . . . . . . . . . . 17 73 4. Receiver Operations . . . . . . . . . . . . . . . . . . . . . 18 74 4.1 Initialization of a Receiver . . . . . . . . . . . . . . . 18 75 4.1.1 Processing the Bootstrap Information Message . . . . . 18 76 4.1.2 Time Synchronization . . . . . . . . . . . . . . . . . 18 77 4.2 Authentication of Received Packets . . . . . . . . . . . . 19 78 5. Integration in the ALC and NORM Protocols . . . . . . . . . . 21 79 5.1 Authentication Header Extension Format . . . . . . . . . . 21 80 5.2 Use of Authentication Header Extensions . . . . . . . . . 22 81 6. Security Considerations . . . . . . . . . . . . . . . . . . . 24 82 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 83 7.1 Normative References . . . . . . . . . . . . . . . . . . . 25 84 7.2 Informative References . . . . . . . . . . . . . . . . . . 25 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25 86 A. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 87 A.1 Cryptographic pseudo-random function (PRF) . . . . . . . . 27 88 A.2 Cryptographic message authentication code (MAC) . . . . . 27 89 A.3 Signature type . . . . . . . . . . . . . . . . . . . . . . 27 90 A.4 Certificate type . . . . . . . . . . . . . . . . . . . . . 28 91 Intellectual Property and Copyright Statements . . . . . . . . 29 93 1. Introduction 95 1.1 Context 97 This document explains how to integrate the TESLA source 98 authentication and packet integrity protocol to the ALC and NORM 99 protocols. The FLUTE content delivery application, built on top of 100 ALC, can directly benefit from the services offered by TESLA at the 101 transport layer. 103 This draft only considers the authentication/integrity of the packets 104 generated by the session's sender, not the feedback packets that may 105 be generated by receivers with NORM for instance. Because of the low 106 rate and sporadic transmission of feedback packets, an authentication 107 scheme different from TESLA may be more appropriate in that case. Of 108 course, this remark does not apply to ALC since transmissions are 109 purely unidirectional. 111 The security offered by TESLA heavily relies on time. Therefore the 112 sender and each receiver need to be time synchronized in a secure 113 way. Two methods exist: a direct one and an indirect one. The 114 present document explains how to achieve time synchronization in each 115 case. 117 When a broadcaster uses the TESLA with direct time synchronization, 118 each receiver asks the sender for a time synchronization. The source 119 then directly answers to each request, signing the reply. The 120 security of this synchronization method is guaranteed, but the source 121 MAY collapse it the rate of requests exceeds a certain threshold, and 122 a bidirectional channel MUST exist between the source and each 123 receiver. If this may not be an issue with NORM sessions, it will be 124 in case of ALC. 126 When a broadcaster uses TESLA with indirect time synchronization, the 127 source and each receiver must synchronize with another time reference 128 (e.g. one or more NTP servers, or a GPS device) securely. In that 129 case, if the external time reference does not create a bottleneck, 130 there is no scalability penalty. Besides it works with 131 unidirectional connections from the source to the receiver. 132 Therefore this approach is well suited to ALC sessions. 134 TESLA requires the transmission of key control information between 135 the source and each receiver. In particular it defines: 137 o a bootstrapping information message that carries control 138 information needed by a receiver to initialize its TESLA 139 component. Depending on the time synchronization method, this 140 message will be sent either directly to a receiver upon request or 141 broadcast periodically. This latter possibility enables in 142 particular late receivers to catch up, which is required with ALC 143 sessions in ``on-demand'' mode; 145 o an authentication tag is associated to each packet in order to 146 enable the authentication of previously sent packets, and possibly 147 to announce a new or old key commitment; 149 o a direct synchronization request message; 151 The present document explains how to carry this information in the 152 ALC and NORM protocols, using a dedicated authentication protocol 153 header extension, EXT_AUTH=1 (already mentioned in [RFC3451]). 155 For more informations on the TESLA protocol and its principles, 156 please refer to [RFC4082] and the references mentioned in that 157 document. 159 1.2 Conventions Used in this Document 161 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 162 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 163 document are to be interpreted as described in [RFC2119]. 165 1.3 Terminology and Notations 167 The following notations are used throughout this document: 169 o PRF is the Pseudo Random Function. 171 o MAC is the Message Authentication Code. 173 o HMAC is the Keyed-Hash Message Authentication Code. 175 o TN is the reference time at some point. 177 o T_s is the TESLA server local time corresponding to reference time 178 TN. 180 o T_r is the TESLA receiver local time corresponding to reference 181 time TN. 183 o N_tx_old_kcc is ... 185 o N_tx_new_kcc is ... 187 o N is the number of keys of a key chain. When several chains are 188 used, all chains have the same length. 190 o 192 o TODO: finish this list... 194 2. Time Synchronization 196 The security of TESLA relies on time. The sender uses a set of keys 197 to compute the MAC of the messages and discloses these keys later. 198 The receiver MUST ensure that each packet he received cannot have 199 been sent after the disclosure of the corresponding key. 201 To achieve this, the sender and the receiver MUST be synchronized. 202 More precisely, the receiver must know an upper bound of the sender's 203 local time. There are two possibilities: 205 o Direct time synchronization: each receiver asks the sender for a 206 time synchronization. 208 o Indirect time synchronization: each receiver and the sender use an 209 other time reference, like a NTP server or GPS device. 211 2.1 Direct Time Synchronization 213 The receiver sends a synchronization request, that includes a nonce, 214 to the sender and remembers the local receiver time the message was 215 sent, t_r. The sender records its local time upon receiving the 216 request, t_s. The sender sends a reply (a bootstrapping information 217 message, Section 3.2.1) that includes in particular t_s. This 218 answer, plus the nonce that is appended, is digitally signed. The 219 nonce is then removed, and the reply is sent to the receiver. After 220 authenticating the reply, the receiver can estimate an upper bound of 221 the sender's time: D_t = t_s - t_r + S, where S is an estimated bound 222 on the clock drift throughout the duration of the session. See 223 [RFC4082] for further details. 225 Since a bidirectional channel is assumed, this method is well suited 226 to NORM sessions. Section 4.1.2 details the request message in case 227 of NORM. Section 3.2.1 details the bootstrapping information. 229 2.2 Indirect Time Synchronization 231 Indirect time synchronization relies on a time reference, for 232 instance a NTP time server or a GPS synchronized clock. The sender 233 and each receiver then synchronize directly and independently with 234 this third party. In the case of a synchronization through a NTP 235 time server, several time servers SHOULD be available for scalability 236 purpose. 238 There are two drawbacks: 240 o The session's sender looses the control of the synchronization. 241 Since it is vital to the whole security, this synchronization must 242 be fully secured. 244 o When different NTP servers are used, these servers MUST be 245 securely and reliably synchronized between each other. 247 2.2.1 Delay Bound Calculation in Indirect time Synchronization 249 Let's assume the sender and each receiver synchronize with one or 250 several reference time servers. A direct time synchronization 251 between the server and the reference time server results in ds = TN - 252 Ts. A direct time synchronization between a receiver and the same 253 reference time server results in dr = TN - Tr. So: D = ds - dr, is 254 the offset between the TESLA server and the TESLA receiver (since D = 255 (TN - Ts) - (TN - Tr) = Tr - Ts). When a receiver receives packets, 256 he is now able to compute the upper bound on the time server when it 257 sends it. If tr is the time when the receiver gets the packet and ts 258 is the corresponding time of the server, we have tr = Tr + t and ts = 259 Ts + t. The receiver can compute the server time by doing tr - D = 260 (Tr + t) - (Tr - Ts) = ts. 262 For more security, we can substract to D two positive values: 264 o an upper bound on the maximum clock drift between the sender and 265 the receiver during the session. 267 o when the server and the receiver use different NTP time servers : 268 an upper bound on the NTP time error between two different NTP 269 servers. 271 Let Derr be the sum of these upper bounds. 273 So: D = ds - dr - Derr, with Derr > 0. When computing tr - D = ts + 274 Derr, we now have a security margin when we do the TESLA security 275 check, that is we must have received the packet before the disclosing 276 of the key used to compute the MAC of this packet. 278 In the bootstrapping information (see Section 3.3.1), the ds value 279 (which can be negative) is sent. This information does not depend on 280 the receiver, so the bootstraping information can be broadcast to all 281 receivers. 283 3. Sender Operations 285 3.1 TESLA Parameters 287 3.1.1 Time Interval Schedule 289 The sender must choose a time interval schedule. That is it must 290 decide when the different keys needed by TESLA will be used and 291 disclosed. The different parameters are: 293 o T_int: the interval duration usually ranging from 100 milliseconds 294 to 1 second. 296 o d: the key disclosure delay. It is the time to wait (in a number 297 of intervals) to disclose a key. A key is part of a one-way key 298 chain. 300 o N: the length of the key chain. When a key chain is finished it 301 is possible to switch to a new key chain. 303 o TI_0: the starting time of time interval 0. 305 3.1.2 Key Chain 307 The TESLA sender must compute a one-way key chain of N keys. It must 308 first select a Primary Key, choose two PRF function F and F', and 309 then compute all the previous keys using K_{i-1} = F(K_i). The key 310 for MAC calculation can then be derived from the corresponding K_i 311 key by K'_i=F'(K_i). The randomness of the Primary key is vital to 312 the security since no one should be able to guess it. 314 The key chain has a finite length, so the TESLA session must finish 315 before the end of the key chain. But the longer the key chain, the 316 higher the memory and computation required to cope with it. Another 317 solution consists in switching to a new key chain when necessary. 319 To do so, the sender must send a commitment to the new key chain 320 before the end of the current key chain. This commitment is simply 321 F(K_{N+1}) and should be sent during N_tx_new_kcc intervals before 322 the end of the key chain. Generally, several packets are sent during 323 a time interval, so it is possible to alternate between sending a 324 disclosed key and a commitment to the new key chain, which offers the 325 benefit of adding no overhead. See Section 3.3.3 for more 326 informations. 328 The receiver will keep the commitment, until the key K_{N+1} (the 329 first of the new key chain) is disclosed. Then the receiver will be 330 able to test the validity of that key by computing F(K_{N+1}) and 331 comparing it to the commitment. 333 When a key chain is changed, it becomes impossible to recover a 334 previous key from the old key chain. This is a problem if the 335 receiver lost the packets disclosing the last key of the old key 336 chain. A solution consists in re-sending the last key K_N of the old 337 key chain. This is done during N_tx_old_kcc intervals at the 338 beginning of the new key chain. See Section 3.3.4 for more 339 informations. 341 3.2 TESLA Signaling 343 At a sender, TESLA produces two types of signaling information: 345 o The bootstrap information, which is a digitally signed packet 346 containing all the information required to bootstrap TESLA at a 347 receiver. 349 o The authentication tag, which is sent in all packets (see 350 Section 5 for exceptions) and contains the MAC of the packet. 352 3.2.1 Bootstrap Information 354 In order to initialize the TESLA component at a receiver, the sender 355 must communicate some key information. This TESLA bootstrap 356 information MUST be securely transmitted, in particular a receiver 357 must be able to check the packet source and the packet integrity 358 using standard protocols. Any digital signature will do. 360 The bootstrap information can be either sent in point to point, after 361 a direct synchronization request from a receiver, or broadcast to all 362 receivers, for instance periodically, when indirect time 363 synchronization is used. 365 The periodic transmission of the bootstrap information message will 366 be required in indirect time synchronization mode when: 368 o the ALC session uses an ``on-demand'' mode, clients arriving at 369 their own discretion, 371 o the packet containing the bootstrap information has been lost by 372 some clients, 374 A balance must be found between the signaling overhead and the 375 maximum initial waiting time at the receiver before starting the 376 delayed authentication process. A frequency of 1 second for the 377 transmission of this bootstrap information is often a reasonable 378 value. 380 The bootstrap information message MAY be sent only once in other 381 cases, in particular with sessions in ``push'' mode, when all clients 382 will receive with a very high probability the corresponding packet. 384 In some cases, a change in the key chain can lead a receiver having 385 experienced a very long disconnection to loose the commitment of the 386 new chain, and therefore be unable to authenticate any packet related 387 to the new chain and all the following ones. To solve this issue, 388 the sender can extend the T_tx_new_kcc value, but this will remain a 389 partial solution (a receiver may be disconnected during the whole key 390 chain period), or decide to periodically send the bootstrap 391 information message, even in direct time synchronization mode. 393 3.2.2 Authentication Tag 395 Every authenticated packet must have an authentication tag, 396 containing the MAC of the message and a disclosed key. 398 The computation of the MAC, MAC(K_i, M), includes the ALC or NORM 399 header, including the various header extensions, plus the payload 400 when applicable. The UDP/IP/MAC headers are not included. During 401 this computation, the MAC(K_i, M) field of the authentication tag 402 (see Section 3.3.2 Section 3.3.3 Section 3.3.4) MUST be set to 0. 404 3.3 Signaling Information Format 406 This section specifies the format of the various kinds of TESLA 407 signaling information sent by the sender. 409 3.3.1 Bootstrap Information Format 411 ----- Editor's note: This bootstrap information format is based on 412 the expired draft [tesla/spec], modified. The present format is 413 not fully satisfying and will probably be changed in new versions 414 of this I-D. ----- 416 The format of the bootstrap information: 418 0 1 2 3 419 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 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | KC PRF type | MAC PRF type | HMAC func type| Signature type| 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 |# cert |rsvd |P| d (intervals) | T_int (milliseconds) | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | K_j Key length | Signature length | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | N | 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | Id j of K_j | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | | 432 ~ K_j +-+-+-+-+-+-+-+-+ 433 | | Padding | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | | 436 + TI_0 (NTP timestamp) + 437 | | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | | 440 + ds or t_s (NTP timedif) + 441 | | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | | 444 ~ Signature extension ~ 445 | | 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | | 448 ~ NTP informations (Optional) ~ 449 | | 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 Figure 1 454 The reference numbers are described in Appendix A 456 o The key chain PRF type is the reference number of the F function 457 used to calculate the key chain. 459 o The MAC PRF type is the reference number of the F' function used 460 to derive the MAC key from the key chain. 462 o The HMAC function type is the reference number of the function 463 used to compute the HMAC of the packets. 465 o Signature type is the reference number of the digital signature 466 used to authenticate this bootstrap information. 468 o # of certs is the number of certificates present in the signature 469 extension. 471 o P ("Positive") is a boolean used in the indirect time 472 synchronization. It indicates whether the D time difference is 473 positive (P=1) or negative (P=0). 475 o d is an unsigned integer that defines the number of intervals 476 before key disclosure (e.g. if a key is used in interval i, this 477 key will be disclosed in interval i+d). d MUST be greater or equal 478 to 2. 480 o T_int is an unsigned integer corresponding to the number of 481 milliseconds of one interval. 483 o K_j Key length is the length in bits of key K_j. 485 o Signature length is the number of bytes of the signature included 486 in the signature extension. 488 o N is the number of keys of the key chain. 490 o Id j of K_j is an unsigned integer corresponding to the index of 491 the interval of the key released in this bootstrap information. 492 For performance reasons, the sender SHOULD always send a bootstrap 493 information with the highest Id j possible since this will reduce 494 the number of computation for the receivers that join later. 496 o K_j is the key corresponding to the interval j. If i is the 497 current interval we MUST have: j < i - d. 499 o TI_0 is the time of the beginning of interval 0. It is a NTP 500 timestamp, composed of two 32 bits word: one for the seconds 501 elapsed since 01/01/1900 at 00:00 and the other one for the 502 fraction of seconds. 504 o ds or t_s (NTP timedif) depends on the time synchronization mode. 505 In direct mode, this field contains t_s, which is the sender's 506 local time when he received the request (Section 2.1). In 507 indirect mode, this field contains ds, the offset between the 508 server and an NTP server or an other time reference (Section 2.2). 510 o The format of the signature extension is described below, and 511 depends on the "# of certs" field. 513 o The NTP information is optional and is described below. Its 514 presence can be detected by the total length of the signature. 516 The signature extension format when the "# of certs" field is 517 strictly greater than 0 (2 in this example) is: 519 0 1 2 3 520 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 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 | cert 1 type | cert 1 length | | 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 524 | | 525 ~ Certificate 1 +-+-+-+-+-+-+-+-+ 526 | | Padding | 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 | cert 2 type | cert 2 length | | 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 530 | | 531 ~ Certificate 2 +-+-+-+-+-+-+-+-+ 532 | | Padding | 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 | | 535 ~ Signature +-+-+-+-+-+-+-+-+ 536 | | Padding | 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 Figure 2 541 In Figure 2: 543 o Type of certificate identifies the algorithm used for the 544 certificate (see Appendix A). 546 o The certificate length is the length in bytes of the certificate. 548 o The certificate field contains a certificate signed by an external 549 authority and that certifies the sender's public key. This field 550 is padded (with 0) up to a multiple of 32 bits. 552 o The signature is a digital signature using the type and length 553 specified in the main part of the bootstrap information message. 554 This field is padded (with 0) up to a multiple of 32 bits. 556 The signature extension format when the "# of certs" field is zero 557 (i.e. when no certificate is provided) is: 559 0 1 2 3 560 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 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 | | 563 ~ Signature +-+-+-+-+-+-+-+-+ 564 | | Padding | 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 Figure 3 569 In Figure 3: 571 o The signature is a digital signature using the type and length 572 specified in the main part of the bootstrap information message. 573 This field is padded (with 0) up to a multiple of 32 bits. 575 The optional NTP information format, when two NTP servers are 576 specified, is: 578 0 1 2 3 579 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 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 | total length | # of entries | reserved (0) | cert type | 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 | FQDN 1 length | cert 1 length | | 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 585 | | 586 ~ NTP Server 1 FQDN +-+-+-+-+-+-+-+-+ 587 | | Padding | 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 | | 590 ~ NTP Certificate (optional) +-+-+-+-+-+-+-+-+ 591 | | Padding | 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 | FQDN 2 length | cert 2 length | | 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 595 | | 596 ~ NTP Server 2 FQDN +-+-+-+-+-+-+-+-+ 597 | | Padding | 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 | | 600 ~ NTP Certificate (optional) +-+-+-+-+-+-+-+-+ 601 | | Padding | 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 Figure 4 606 In Figure 4: 608 o The total length is the total length in units of 32 bit words of 609 this NTP information extension; 611 o The # of entries is the number of NTP entries; 613 o Type of certificates identifies the algorithm used for all the 614 certificates that may be provided (see Appendix A). 616 o The FQDN length is the number of bytes of the NTP server fully 617 qualified domain name; 619 o The NTP server FQDN is a string containing the NTP server Fully 620 Qualified Domain Name (e.g. "ntp.foo.bar."). This field is padded 621 (with 0) up to a multiple of 32 bits; 623 o The NTP Certificate is optional. The content delivery server can 624 use it to self-certify the NTP public key. The certificate length 625 indicates whether this field is present or not. This field is 626 padded (with 0) up to a multiple of 32 bits. 628 3.3.2 Standard Authentication Tag Format 630 Here is the format of the authentication tag: 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 | Id i of K_i | 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 | | 638 ~ Disclosed Key K_{i-d} +-+-+-+-+-+-+-+-+ 639 | | Padding | 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 | | 642 ~ MAC(K_i, M) +-+-+-+-+-+-+-+-+ 643 | | Padding | 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 646 Figure 5 648 In Figure 5: 650 o The Id i is the index of the key used for computing the MAC of 651 this packet. 653 o The disclosed key MUST be the key used for interval i-d. 655 o MAC(K_i, M) is the message authentication code of the current 656 packet, including the ALC or NORM header (including the header 657 extensions), plus the payload when applicable. 659 3.3.3 Authentication Tag Format with a New key Chain Commitment 661 During the last N_tx_new_kcc intervals of the current key chain, the 662 sender MUST send a commitment to the next key chain. This is done by 663 replacing the disclosed key of the authentication tag with the new 664 key commitment, F(K_{N+1}) 665 Here is the format of the authentication tag with an new key 666 commitment tag: 668 0 1 2 3 669 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 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 | Id i of K_i | 672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 673 | | 674 ~ New Key Commitment F(K_{N+1}) +-+-+-+-+-+-+-+-+ 675 | | Padding | 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 | | 678 ~ MAC(K_i, M) +-+-+-+-+-+-+-+-+ 679 | | Padding | 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 682 Figure 6 684 3.3.4 Authentication Tag Format with an Old Key Chain Commitment 686 During the first N_tx_old_kcc intervals of the new key chain after 687 the disclosing interval, d, the sender must send a commitment to the 688 old key chain. This is done by replacing the disclosed key of the 689 authentication tag with the old key commitment, K_N 691 Here is the format of the authentication tag with an old key 692 commitment tag: 694 0 1 2 3 695 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 696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 697 | Id i of K_i | 698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 699 | | 700 ~ Old Key Commitment K_N +-+-+-+-+-+-+-+-+ 701 | | Padding | 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 | | 704 ~ MAC(K_i, M) +-+-+-+-+-+-+-+-+ 705 | | Padding | 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 708 Figure 7 710 4. Receiver Operations 712 4.1 Initialization of a Receiver 714 A receiver must be initialized before being able to authenticate the 715 source of incoming packets. Two actions must be performed: 717 o receive and process a bootstrap information message, and 719 o calculate an upper bound of the sender's local time, and to that 720 purpose, he must perform time synchronization. 722 4.1.1 Processing the Bootstrap Information Message 724 A receiver must receive a packet containing the bootstrap 725 information, digitally signed by the sender, and verify its 726 signature. Because the packet is signed, the receiver also needs to 727 know the public key of the sender. The present document does not 728 specify how the public key of the sender is communicated reliably and 729 in a secure way to all possible receivers. Once the bootstrap 730 information has been proved to be safe, the receiver can initialize 731 its TESLA component. Time synchronization is detailed in 732 Section 4.1.2. The receiver stores the parameters related to the 733 time interval schedule and key chain. The receiver can then ignore 734 next bootstrap information messages, except if he is in a new key 735 chain and missed all the commitments for this new key chain. 737 Before TESLA has been initialized, a receiver MUST ignore all packets 738 other than the bootstrap information message. Yet, a receiver MAY 739 buffer incoming packets, recording the reception time of each packet, 740 and proceed with delayed authentication later, once the receiver will 741 be fully initialized. In that case, the buffer must be carefully 742 sized. 744 4.1.2 Time Synchronization 746 First of all, the receiver must know whether the ALC or NORM session 747 relies on direct or indirect synchronization. This information is 748 communicated by an out-of-band mechanism (for instance when 749 describing the various parameters of a FLUTE session in case of ALC). 751 In case of a direct time synchronization, a receiver MUST first 752 synchronize with the sender. To that purpose, the receiver sends 753 direct time synchronization request message. This message includes a 754 nonce, i.e. a random number chosen independently by the receiver, 755 that will be integrated when the sender calculates the digital 756 signature of his reply. 758 The request for a direct time synchronization contains the following 759 information: 761 0 1 2 3 762 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 763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 764 | | 765 ~ ~ 766 | Nr (nonce) | 767 ~ ~ 768 | | 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 771 Figure 8 773 With the indirect time synchronization method, the sender MAY provide 774 in its bootstrap information, the URL of the NTP servers he trusts 775 along with an OPTIONAL certificate for each NTP server. When NTP 776 servers are specified, a receiver SHOULD choose one of the NTP 777 servers provided. This document does not specify how the choice is 778 made, but for the sake of scalability, the clients SHOULD NOT use the 779 same server if several possibilities are offered. The NTP 780 synchronization between the NTP server and the receiver MUST be 781 secured, either using the certificate provided by the content 782 delivery server, or another certificate the client may obtain for 783 this NTP server. 785 Then the receiver computes the time offset between itself and the NTP 786 server chosen. Note that the receiver does not need to update the 787 local time, since this operation would often require some privileges, 788 computing the time offset is sufficient. 790 Since the offset between the server and the time reference is 791 indicated in the bootstrap information message, the receiver can now 792 calculate an upper bound of the sender's local time Section 2.2. 794 4.2 Authentication of Received Packets 796 The receiver can now authenticate incoming packets. To that purpose, 797 he must follows different steps: 799 1. The receiver parses the different packet headers. If the TESLA 800 authentication tag is not present, the receiver MUST reject the 801 packet. 803 2. Then proceed with the TESLA safe test: (1) check that the key 804 used to compute the MAC of this packet has not already been 805 disclosed, and (2) check the disclosed key by computing the 806 necessary number of PRF functions to obtain a previously safe 807 disclosed key. If any of these two tests fail, the receiver MUST 808 reject the packet. 810 3. Then, according to the [RFC3451], when applicable, perform 811 congestion control even if the packet has not yet been 812 authenticated. If this feature leads to a potential DoS attack, 813 it does not compromise the security features offered by TESLA and 814 enables a rapid reaction in front of congestion problems. 816 4. Then buffer the packet for a later authentication, once the 817 corresponding key will be received or deduced from another key. 819 5. If the disclosed key is a new one, then the receiver can 820 authenticate previously stored packets using this key or any key 821 derived from this one. 823 6. If a packet fails to be authenticated, then this packet MUST be 824 rejected. 826 7. If a packet is successfully authenticated, then the receiver 827 continues processing it. 829 ----- Editor's note: [RFC4082] explains that unauthenticated 830 packets SHOULD be destroyed, and if not this is at the own risk of 831 the receiver. We choose the other strategy, requiring that unsafe 832 packets be destroyed when the client decides to use TESLA. But 833 the client can at any time choose to continue an ALC or NORM 834 session in unsafe mode, ignoring TESLA extensions. ----- 836 5. Integration in the ALC and NORM Protocols 838 5.1 Authentication Header Extension Format 840 The integration of TESLA in ALC or NORM is similar and relies on the 841 header extension mechanism defined in both protocols. More precisely 842 we further specify the EXT_AUTH=1 header extension [RFC3451]. 843 Several fields are added in addition to the HET (Header Extension 844 Type) and HEL (Header Extension Length) fields (Figure 9). 846 Here is the format of the LCT or NORM extension header: 848 0 1 2 3 849 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 850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 851 | HET (=1) | HEL | Prot |Version| resvd | Type | 852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 853 | | 854 ~ ~ 855 | Extension content | 856 ~ ~ 857 | | 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 860 Figure 9 862 The following fields are defined: 864 o the Prot (Authentication Protocol) field (4 bits) identifies the 865 source authentication protocol in use. We use 1 for TESLA. 867 o the Version field (4 bits) identifies the version number of the 868 authentication scheme. 870 o the resvd (Reserved) field (4 bits) is not used and must be 871 zero'ed. 873 o the Type field(4 bits) identifies the type of message: 875 * 1: bootstrap information, sent by the sender periodically 876 (Section 3.3.2); 878 * 2: authentication information for the on-going key chain, sent 879 by the sender along with each packet; 881 * 3: authentication information along with a new key chain 882 commitment, sent by the sender when approaching the end of a 883 key chain; 885 * 4: authentication information along with an old key chain 886 commitment, sent by the sender some time after moving to a new 887 key chain; 889 * 5: direct synchronization request, sent by a NORM receiver; 891 Each packet sent by the sender MUST contain exactly one of these 892 header extensions when TESLA is used in an ALC or NORM session. All 893 receivers MUST recognize EXT_AUTH but MAY NOT be able to parse its 894 content, for instance because they do not use the TESLA building 895 block, and in that case they SHOULD ignore the EXT_AUTH extensions. 896 In case of NORM, the packets sent by receivers MAY contain a direct 897 synchronization request but MUST NOT contain any of the other four 898 authentication header extensions. 900 ----- Editor's note: this document defines a "Scheme" field that 901 further identifies the authentication protocol. By doing so, all 902 the documents specifying another authentication protocol and 903 relying on the header extension mechanism MUST reserve the same 4 904 bit "Scheme" field. One advantage is that several authentication 905 protocols can be used in a session (perhaps with a NORM session 906 for the feedback messages). This possibility must be discussed. 907 The other solution is to say that there's a single authentication 908 protocol per session, communicated out of band, and therefore the 909 authentication header extension is fully defined (same approach as 910 that of the CCI ALC/LCT congestion control field). ----- 912 5.2 Use of Authentication Header Extensions 914 The bootstrap information (Type=1) SHOULD be sent in a stand-alone 915 control packet rather than in data packets. The reason is the large 916 size of this bootstrap information which largely increases the 917 maximum ALC/LCT or NORM header size. By having the bootstrap 918 information header extension in stand-alone packets, the maximum 919 payload of data packets is only affected by the unavoidable 920 authentication tag, not by an additional large header extension sent 921 at a low frequency. 923 The three authentication information extension headers (Type=2, 3, or 924 4) are attached to the corresponding packet (data or control packet). 925 There is no authentication information header extension in case of a 926 control packet containing only the bootstrap information. 928 In case of NORM, the direct synchronization request extension header 929 (Type=5) is sent by a receiver in a XXX NORM packet (see editor's 930 note below). There is no authentication information header extension 931 in this case since this draft only considers the authentication/ 932 integrity of the packets generated by the session's sender. 934 ----- Editor's note: what type of NORM packet should be used to 935 that purpose? NORM_REPORT is one possibility. TBD... ----- 937 6. Security Considerations 939 The security of the TESLA protocol is discussed in [RFC4082]. 940 Security considerations specific to its use in ALC and NORM remain 941 TBD... 943 7. References 945 7.1 Normative References 947 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 948 Requirement Levels", RFC 2119, BCP 14, March 1997. 950 [RFC3450] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., and J. 951 Crowcroft, "Asynchronous Layered Coding (ALC) Protocol 952 Instantiation", RFC 3450, December 2002. 954 [RFC3451] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., Handley, 955 M., and J. Crowcroft, "Layered Coding Transport (LCT) 956 Building Block", RFC 3451, December 2002. 958 [RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B. 959 Briscoe, "Timed Efficient Stream Loss-Tolerant 960 Authentication (TESLA): Multicast Source Authentication 961 Transform Introduction", RFC 4082, June 2005. 963 7.2 Informative References 965 [tesla/spec] 966 Perrig, A., Canetti, R., and B. Whillock, "TESLA: 967 Multicast Source Authentication Transform Specification 968 (draft-ietf-msec-tesla-spec-00.txt)", October 2002. 970 Authors' Addresses 972 Sebastien Faurite 973 INRIA 974 655, av. de l'Europe 975 Zirst; Montbonnot 976 ST ISMIER cedex 38334 977 France 979 Phone: 980 Email: sebastien.faurite@inrialpes.fr 981 URI: 983 Aurelien Francillon 984 INRIA 985 655, av. de l'Europe 986 Zirst; Montbonnot 987 ST ISMIER cedex 38334 988 France 990 Phone: 991 Email: aurelien.francillon@inrialpes.fr 992 URI: 994 Vincent Roca 995 INRIA 996 655, av. de l'Europe 997 Zirst; Montbonnot 998 ST ISMIER cedex 38334 999 France 1001 Phone: 1002 Email: vincent.roca@inrialpes.fr 1003 URI: 1005 Appendix A. IANA Considerations 1007 This document requires an IANA registration for the following 1008 attributes: 1010 A.1 Cryptographic pseudo-random function (PRF) 1012 We use : 1014 +---+-----------+ 1015 | | algorithm | 1016 +---+-----------+ 1017 | 1 | MD5 | 1018 +---+-----------+ 1020 A.2 Cryptographic message authentication code (MAC) 1022 We use : 1024 +---+-----------+------------+ 1025 | | algorithm | key length | 1026 +---+-----------+------------+ 1027 | 1 | MD5 | 64 | 1028 | | | | 1029 | 2 | MD5 | 96 | 1030 | | | | 1031 | 3 | MD5 | 128 | 1032 +---+-----------+------------+ 1034 A.3 Signature type 1036 We use : 1038 +---+------------------------------------+ 1039 | | algorithm | 1040 +---+------------------------------------+ 1041 | 1 | PKCS #1: RSA Cryptography Standard | 1042 +---+------------------------------------+ 1044 A.4 Certificate type 1046 We use : 1048 +---+------------------------------------+ 1049 | | algorithm | 1050 +---+------------------------------------+ 1051 | 1 | PKCS #1: RSA Cryptography Standard | 1052 +---+------------------------------------+ 1054 Intellectual Property Statement 1056 The IETF takes no position regarding the validity or scope of any 1057 Intellectual Property Rights or other rights that might be claimed to 1058 pertain to the implementation or use of the technology described in 1059 this document or the extent to which any license under such rights 1060 might or might not be available; nor does it represent that it has 1061 made any independent effort to identify any such rights. Information 1062 on the procedures with respect to rights in RFC documents can be 1063 found in BCP 78 and BCP 79. 1065 Copies of IPR disclosures made to the IETF Secretariat and any 1066 assurances of licenses to be made available, or the result of an 1067 attempt made to obtain a general license or permission for the use of 1068 such proprietary rights by implementers or users of this 1069 specification can be obtained from the IETF on-line IPR repository at 1070 http://www.ietf.org/ipr. 1072 The IETF invites any interested party to bring to its attention any 1073 copyrights, patents or patent applications, or other proprietary 1074 rights that may cover technology that may be required to implement 1075 this standard. Please address the information to the IETF at 1076 ietf-ipr@ietf.org. 1078 Disclaimer of Validity 1080 This document and the information contained herein are provided on an 1081 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1082 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1083 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1084 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1085 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1086 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1088 Copyright Statement 1090 Copyright (C) The Internet Society (2005). This document is subject 1091 to the rights, licenses and restrictions contained in BCP 78, and 1092 except as set forth therein, the authors retain all their rights. 1094 Acknowledgment 1096 Funding for the RFC Editor function is currently provided by the 1097 Internet Society.