API tools faq
paste
N3r0_H4x0r_EvilSec

Internet Engineering Task Force (IETF)

N3r0_H4x0r_EvilSec
Nov 4th, 2013
127
0
Never
Add comment
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 135.58 KB | None | 0 0
raw download clone embed print report
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Internet Engineering Task Force (IETF) V. Roca
  8. Request for Comments: 5776 A. Francillon
  9. Category: Experimental S. Faurite
  10. ISSN: 2070-1721 INRIA
  11. April 2010
  12.  
  13. Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in
  14. the Asynchronous Layered Coding (ALC) and
  15. NACK-Oriented Reliable Multicast (NORM) Protocols
  16.  
  17. Abstract
  18.  
  19. This document details the Timed Efficient Stream Loss-Tolerant
  20. Authentication (TESLA) packet source authentication and packet
  21. integrity verification protocol and its integration within the
  22. Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable
  23. Multicast (NORM) content delivery protocols. This document only
  24. considers the authentication/integrity verification of the packets
  25. generated by the session's sender. The authentication and integrity
  26. verification of the packets sent by receivers, if any, is out of the
  27. scope of this document.
  28.  
  29. Status of This Memo
  30.  
  31. This document is not an Internet Standards Track specification; it is
  32. published for examination, experimental implementation, and
  33. evaluation.
  34.  
  35. This document defines an Experimental Protocol for the Internet
  36. community. This document is a product of the Internet Engineering
  37. Task Force (IETF). It represents the consensus of the IETF
  38. community. It has received public review and has been approved for
  39. publication by the Internet Engineering Steering Group (IESG). Not
  40. all documents approved by the IESG are a candidate for any level of
  41. Internet Standard; see Section 2 of RFC 5741.
  42.  
  43. Information about the current status of this document, any errata,
  44. and how to provide feedback on it may be obtained at
  45. http://www.rfc-editor.org/info/rfc5776.
  46.  
  47. Roca, et al. Experimental [Page 1]
  49. RFC 5776 TESLA in ALC and NORM April 2010
  50.  
  51.  
  52. Copyright Notice
  53.  
  54. Copyright (c) 2010 IETF Trust and the persons identified as the
  55. document authors. All rights reserved.
  56.  
  57. This document is subject to BCP 78 and the IETF Trust's Legal
  58. Provisions Relating to IETF Documents
  59. (http://trustee.ietf.org/license-info) in effect on the date of
  60. publication of this document. Please review these documents
  61. carefully, as they describe your rights and restrictions with respect
  62. to this document. Code Components extracted from this document must
  63. include Simplified BSD License text as described in Section 4.e of
  64. the Trust Legal Provisions and are provided without warranty as
  65. described in the Simplified BSD License.
  66.  
  67. This document may contain material from IETF Documents or IETF
  68. Contributions published or made publicly available before November
  69. 10, 2008. The person(s) controlling the copyright in some of this
  70. material may not have granted the IETF Trust the right to allow
  71. modifications of such material outside the IETF Standards Process.
  72. Without obtaining an adequate license from the person(s) controlling
  73. the copyright in such materials, this document may not be modified
  74. outside the IETF Standards Process, and derivative works of it may
  75. not be created outside the IETF Standards Process, except to format
  76. it for publication as an RFC or to translate it into languages other
  77. than English.
  78.  
  79.  
  80.  
  81.  
  82.  
  83.  
  84.  
  85.  
  86.  
  87.  
  88.  
  89.  
  90.  
  91.  
  92.  
  93.  
  94.  
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103. Roca, et al. Experimental [Page 2]
  105. RFC 5776 TESLA in ALC and NORM April 2010
  106.  
  107.  
  108. Table of Contents
  109.  
  110. 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
  111. 1.1. Scope of This Document . . . . . . . . . . . . . . . . . . 6
  112. 1.2. Conventions Used in This Document . . . . . . . . . . . . 7
  113. 1.3. Terminology and Notations . . . . . . . . . . . . . . . . 7
  114. 1.3.1. Notations and Definitions Related to Cryptographic
  115. Functions . . . . . . . . . . . . . . . . . . . . . . 7
  116. 1.3.2. Notations and Definitions Related to Time . . . . . . 8
  117. 2. Using TESLA with ALC and NORM: General Operations . . . . . . 9
  118. 2.1. ALC and NORM Specificities That Impact TESLA . . . . . . . 9
  119. 2.2. Bootstrapping TESLA . . . . . . . . . . . . . . . . . . . 10
  120. 2.2.1. Bootstrapping TESLA with an Out-Of-Band Mechanism . . 10
  121. 2.2.2. Bootstrapping TESLA with an In-Band Mechanism . . . . 11
  122. 2.3. Setting Up a Secure Time Synchronization . . . . . . . . . 11
  123. 2.3.1. Direct Time Synchronization . . . . . . . . . . . . . 12
  124. 2.3.2. Indirect Time Synchronization . . . . . . . . . . . . 12
  125. 2.4. Determining the Delay Bounds . . . . . . . . . . . . . . . 13
  126. 2.4.1. Delay Bound Calculation in Direct Time
  127. Synchronization Mode . . . . . . . . . . . . . . . . . 14
  128. 2.4.2. Delay Bound Calculation in Indirect Time
  129. Synchronization Mode . . . . . . . . . . . . . . . . . 14
  130. 2.5. Cryptographic Parameter Values . . . . . . . . . . . . . . 15
  131. 3. Sender Operations . . . . . . . . . . . . . . . . . . . . . . 16
  132. 3.1. TESLA Parameters . . . . . . . . . . . . . . . . . . . . . 16
  133. 3.1.1. Time Intervals . . . . . . . . . . . . . . . . . . . . 16
  134. 3.1.2. Key Chains . . . . . . . . . . . . . . . . . . . . . . 16
  135. 3.1.3. Time Interval Schedule . . . . . . . . . . . . . . . . 20
  136. 3.1.4. Timing Parameters . . . . . . . . . . . . . . . . . . 20
  137. 3.2. TESLA Signaling Messages . . . . . . . . . . . . . . . . . 21
  138. 3.2.1. Bootstrap Information . . . . . . . . . . . . . . . . 21
  139. 3.2.2. Direct Time Synchronization Response . . . . . . . . . 22
  140. 3.3. TESLA Authentication Information . . . . . . . . . . . . . 22
  141. 3.3.1. Authentication Tags . . . . . . . . . . . . . . . . . 23
  142. 3.3.2. Digital Signatures . . . . . . . . . . . . . . . . . . 23
  143. 3.3.3. Group MAC Tags . . . . . . . . . . . . . . . . . . . . 24
  144. 3.4. Format of TESLA Messages and Authentication Tags . . . . . 25
  145. 3.4.1. Format of a Bootstrap Information Message . . . . . . 26
  146. 3.4.2. Format of a Direct Time Synchronization Response . . . 31
  147. 3.4.3. Format of a Standard Authentication Tag . . . . . . . 32
  148. 3.4.4. Format of an Authentication Tag without Key
  149. Disclosure . . . . . . . . . . . . . . . . . . . . . . 33
  150. 3.4.5. Format of an Authentication Tag with a "New Key
  151. Chain" Commitment . . . . . . . . . . . . . . . . . . 34
  152. 3.4.6. Format of an Authentication Tag with a "Last Key
  153. of Old Chain" Disclosure . . . . . . . . . . . . . . . 35
  154. 4. Receiver Operations . . . . . . . . . . . . . . . . . . . . . 36
  155. 4.1. Verification of the Authentication Information . . . . . . 36
  156.  
  157.  
  158.  
  159. Roca, et al. Experimental [Page 3]
  161. RFC 5776 TESLA in ALC and NORM April 2010
  162.  
  163.  
  164. 4.1.1. Processing the Group MAC Tag . . . . . . . . . . . . . 36
  165. 4.1.2. Processing the Digital Signature . . . . . . . . . . . 37
  166. 4.1.3. Processing the Authentication Tag . . . . . . . . . . 37
  167. 4.2. Initialization of a Receiver . . . . . . . . . . . . . . . 38
  168. 4.2.1. Processing the Bootstrap Information Message . . . . . 38
  169. 4.2.2. Performing Time Synchronization . . . . . . . . . . . 38
  170. 4.3. Authentication of Received Packets . . . . . . . . . . . . 40
  171. 4.3.1. Discarding Unnecessary Packets Earlier . . . . . . . . 43
  172. 4.4. Flushing the Non-Authenticated Packets of a Previous
  173. Key Chain . . . . . . . . . . . . . . . . . . . . . . . . 43
  174. 5. Integration in the ALC and NORM Protocols . . . . . . . . . . 44
  175. 5.1. Authentication Header Extension Format . . . . . . . . . . 44
  176. 5.2. Use of Authentication Header Extensions . . . . . . . . . 45
  177. 5.2.1. EXT_AUTH Header Extension of Type Bootstrap
  178. Information . . . . . . . . . . . . . . . . . . . . . 45
  179. 5.2.2. EXT_AUTH Header Extension of Type Authentication
  180. Tag . . . . . . . . . . . . . . . . . . . . . . . . . 48
  181. 5.2.3. EXT_AUTH Header Extension of Type Direct Time
  182. Synchronization Request . . . . . . . . . . . . . . . 49
  183. 5.2.4. EXT_AUTH Header Extension of Type Direct Time
  184. Synchronization Response . . . . . . . . . . . . . . . 49
  185. 6. Security Considerations . . . . . . . . . . . . . . . . . . . 50
  186. 6.1. Dealing with DoS Attacks . . . . . . . . . . . . . . . . . 50
  187. 6.2. Dealing With Replay Attacks . . . . . . . . . . . . . . . 51
  188. 6.2.1. Impacts of Replay Attacks on TESLA . . . . . . . . . . 51
  189. 6.2.2. Impacts of Replay Attacks on NORM . . . . . . . . . . 52
  190. 6.2.3. Impacts of Replay Attacks on ALC . . . . . . . . . . . 53
  191. 6.3. Security of the Back Channel . . . . . . . . . . . . . . . 53
  192. 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54
  193. 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 55
  194. 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 55
  195. 9.1. Normative References . . . . . . . . . . . . . . . . . . . 55
  196. 9.2. Informative References . . . . . . . . . . . . . . . . . . 56
  197.  
  198.  
  199.  
  200.  
  201.  
  202.  
  203.  
  204.  
  205.  
  206.  
  207.  
  208.  
  209.  
  210.  
  211.  
  212.  
  213.  
  214.  
  215. Roca, et al. Experimental [Page 4]
  217. RFC 5776 TESLA in ALC and NORM April 2010
  218.  
  219.  
  220. 1. Introduction
  221.  
  222. Many applications using multicast and broadcast communications
  223. require that each receiver be able to authenticate the source of any
  224. packet it receives as well as the integrity of these packets. This
  225. is the case with ALC [RFC5775] and NORM [RFC5740], two Content
  226. Delivery Protocols (CDPs) designed to transfer objects (e.g., files)
  227. reliably between a session's sender and several receivers. The NORM
  228. protocol is based on bidirectional transmissions. Each receiver
  229. acknowledges data received or, in case of packet erasures, asks for
  230. retransmissions. On the opposite, the ALC protocol is based on
  231. purely unidirectional transmissions. Reliability is achieved by
  232. means of the cyclic transmission of the content within a carousel
  233. and/or by the use of proactive Forward Error Correction (FEC) codes.
  234. Both protocols have in common the fact that they operate at the
  235. application level, on top of an erasure channel (e.g., the Internet)
  236. where packets can be lost (erased) during the transmission.
  237.  
  238. The goal of this document is to counter attacks where an attacker
  239. impersonates the ALC or NORM session's sender and injects forged
  240. packets to the receivers, thereby corrupting the objects
  241. reconstructed by the receivers.
  242.  
  243. Preventing this attack is much more complex in the case of group
  244. communications than it is with unicast communications. Indeed, with
  245. unicast communications, a simple solution exists: the sender and the
  246. receiver share a secret key to compute a Message Authentication Code
  247. (MAC) of all messages exchanged. This is no longer feasible in the
  248. case of multicast and broadcast communications since sharing a group
  249. key between the sender and all receivers implies that any group
  250. member can impersonate the sender and send forged messages to other
  251. receivers.
  252.  
  253. The usual solution to provide the source authentication and message
  254. integrity services in the case of multicast and broadcast
  255. communications consists of relying on asymmetric cryptography and
  256. using digital signatures. Yet, this solution is limited by high
  257. computational costs and high transmission overheads. The Timed
  258. Efficient Stream Loss-tolerant Authentication (TESLA) protocol is an
  259. alternative solution that provides the two required services, while
  260. being compatible with high-rate transmissions over lossy channels.
  261.  
  262. This document explains how to integrate the TESLA source
  263. authentication and packet integrity protocol to the ALC and NORM CDP.
  264. Any application built on top of ALC and NORM will directly benefit
  265. from the services offered by TESLA at the transport layer. In
  266. particular, this is the case of File Delivery over Unidirectional
  267. Transport (FLUTE).
  268.  
  269.  
  270.  
  271. Roca, et al. Experimental [Page 5]
  273. RFC 5776 TESLA in ALC and NORM April 2010
  274.  
  275.  
  276. For more information on the TESLA protocol and its principles, please
  277. refer to [RFC4082] and [Perrig04]. For more information on ALC and
  278. NORM, please refer to [RFC5775], [RFC5651], and [RFC5740],
  279. respectively. For more information on FLUTE, please refer to
  280. [RMT-FLUTE].
  281.  
  282. 1.1. Scope of This Document
  283.  
  284. This specification only considers the authentication and integrity
  285. verification of the packets generated by the session's sender. This
  286. specification does not consider the packets that may be sent by
  287. receivers, for instance, NORM's feedback packets. [RMT-SIMPLE-AUTH]
  288. describes several techniques that can be used to that purpose. Since
  289. this is usually a low-rate flow (unlike the downstream flow), using
  290. computing intensive techniques like digital signatures, possibly
  291. combined with a Group MAC scheme, is often acceptable. Finally,
  292. Section 5 explains how to use several authentication schemes in a
  293. given session thanks to the "ASID" (Authentication Scheme IDentifier)
  294. field.
  295.  
  296. This specification relies on several external mechanisms, for
  297. instance:
  298.  
  299. o to communicate securely the public key or a certificate for the
  300. session's sender (Section 2.2.2);
  301.  
  302. o to communicate securely and confidentially the group key, K_g,
  303. used by the Group MAC feature, when applicable (Section 3.3.3).
  304. In some situations, this group key will have to be periodically
  305. refreshed;
  306.  
  307. o to perform secure time synchronization in indirect mode
  308. (Section 2.3.2) or in direct mode (Section 2.3.1) to carry the
  309. request/response messages with ALC, which is purely
  310. unidirectional;
  311.  
  312. These mechanisms are required in order to bootstrap TESLA at a sender
  313. and at a receiver and must be deployed in parallel to TESLA.
  314. Besides, the randomness of the Primary Key of the key chain
  315. (Section 3.1.2) is vital to the security of TESLA. Therefore, the
  316. sender needs an appropriate mechanism to generate this random key.
  317.  
  318. Several technical details of TESLA, like the most appropriate way to
  319. alternate between the transmission of a key disclosure and a
  320. commitment to a new key chain, or the transmission of a key
  321. disclosure and the last key of the previous key chain, or the
  322. disclosure of a key and the compact flavor that does not disclose any
  323. key, are specific to the target use case (Section 3.1.2). For
  324.  
  325.  
  326.  
  327. Roca, et al. Experimental [Page 6]
  329. RFC 5776 TESLA in ALC and NORM April 2010
  330.  
  331.  
  332. instance, it depends on the number of packets sent per time interval,
  333. on the desired robustness and the acceptable transmission overhead,
  334. which can only be optimized after taking into account the use-case
  335. specificities.
  336.  
  337. 1.2. Conventions Used in This Document
  338.  
  339. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  340. "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  341. document are to be interpreted as described in [RFC2119].
  342.  
  343. 1.3. Terminology and Notations
  344.  
  345. The following notations and definitions are used throughout this
  346. document.
  347.  
  348. 1.3.1. Notations and Definitions Related to Cryptographic Functions
  349.  
  350. Notations and definitions related to cryptographic functions
  351. [RFC4082][RFC4383]:
  352.  
  353. o PRF is the Pseudo Random Function;
  354.  
  355. o MAC is the Message Authentication Code;
  356.  
  357. o HMAC is the keyed-Hash Message Authentication Code;
  358.  
  359. o F is the one-way function used to create the key chain
  360. (Section 3.1.2.1);
  361.  
  362. o F' is the one-way function used to derive the HMAC keys
  363. (Section 3.1.2.1);
  364.  
  365. o n_p is the length, in bits, of the F function's output. This is
  366. therefore the length of the keys in the key chain;
  367.  
  368. o n_f is the length, in bits, of the F' function's output. This is
  369. therefore the length of the HMAC keys;
  370.  
  371. o n_m is the length, in bits, of the truncated output of the MAC
  372. [RFC2104]. Only the n_m most significant bits of the MAC output
  373. are kept;
  374.  
  375. o N is the length of a key chain. There are N+1 keys in a key
  376. chain: K_0, K_1, ..., K_N. When several chains are used, all the
  377. chains MUST have the same length and keys are numbered
  378. consecutively, following the time interval numbering;
  379.  
  380.  
  381.  
  382.  
  383. Roca, et al. Experimental [Page 7]
  385. RFC 5776 TESLA in ALC and NORM April 2010
  386.  
  387.  
  388. o n_c is the number of keys in a key chain. Therefore, n_c = N+1;
  389.  
  390. o n_tx_lastkey is the number of additional intervals during which
  391. the last key of the old key chain SHOULD be sent, after switching
  392. to a new key chain and after waiting for the disclosure delay d.
  393. These extra transmissions take place after the interval during
  394. which the last key is normally disclosed. The n_tx_lastkey value
  395. is either 0 (no extra disclosure) or larger. This parameter is
  396. sender specific and is not communicated to the receiver;
  397.  
  398. o n_tx_newkcc is the number of intervals during which the commitment
  399. to a new key chain SHOULD be sent, before switching to the new key
  400. chain. The n_tx_newkcc value is either 0 (no commitment sent
  401. within authentication tags) or larger. This parameter is sender
  402. specific and is not communicated to the receiver;
  403.  
  404. o K_g is a shared group key, communicated to all group members,
  405. confidentially, during the TESLA bootstrapping (Section 2.2);
  406.  
  407. o n_w is the length, in bits, of the truncated output of the MAC of
  408. the optional group authentication scheme: only the n_w most
  409. significant bits of the MAC output are kept. n_w is typically
  410. small, a multiple of 32 bits (e.g., 32 bits).
  411.  
  412. 1.3.2. Notations and Definitions Related to Time
  413.  
  414. Notations and definitions related to time:
  415.  
  416. o i is the time interval index. Interval numbering starts at 0 and
  417. increases consecutively. Since the interval index is stored as a
  418. 32-bit unsigned integer, wrapping to 0 might take place in long
  419. sessions.
  420.  
  421. o t_s is the sender local time value at some absolute time (in NTP
  422. timestamp format);
  423.  
  424. o t_r is the receiver local time value at the same absolute time (in
  425. NTP timestamp format);
  426.  
  427. o T_0 is the start time corresponding to the beginning of the
  428. session, i.e., the beginning of time interval 0 (in NTP timestamp
  429. format);
  430.  
  431. o T_int is the interval duration (in milliseconds);
  432.  
  433. o d is the key disclosure delay (in number of intervals);
  434.  
  435.  
  436.  
  437.  
  438.  
  439. Roca, et al. Experimental [Page 8]
  441. RFC 5776 TESLA in ALC and NORM April 2010
  442.  
  443.  
  444. o D_t is the upper bound of the lag of the receiver's clock with
  445. respect to the clock of the sender;
  446.  
  447. o S_sr is an estimated bound of the clock drift between the sender
  448. and a receiver throughout the duration of the session;
  449.  
  450. o D^O_t is the upper bound of the lag of the sender's clock with
  451. respect to the time reference in indirect time synchronization
  452. mode;
  453.  
  454. o D^R_t is the upper bound of the lag of the receiver's clock with
  455. respect to the time reference in indirect time synchronization
  456. mode;
  457.  
  458. o D_err is an upper bound of the time error between all the time
  459. references, in indirect time synchronization mode;
  460.  
  461. o NTP timestamp format consists in a 64-bit unsigned fixed-point
  462. number, in seconds relative to 0h on 1 January 1900. The integer
  463. part is in the first 32 bits, and the fraction part in the last 32
  464. bits [RFC1305].
  465.  
  466. 2. Using TESLA with ALC and NORM: General Operations
  467.  
  468. 2.1. ALC and NORM Specificities That Impact TESLA
  469.  
  470. The ALC and NORM protocols have features and requirements that
  471. largely impact the way TESLA can be used.
  472.  
  473. In the case of ALC:
  474.  
  475. o ALC is massively scalable: nothing in the protocol specification
  476. limits the number of receivers that join a session. Therefore, an
  477. ALC session potentially includes a huge number (e.g., millions or
  478. more) of receivers;
  479.  
  480. o ALC can work on top of purely unidirectional transport channels:
  481. this is one of the assets of ALC, and examples of unidirectional
  482. channels include satellite (even if a back channel might exist in
  483. some use cases) and broadcasting networks like Digital Video
  484. Broadcasting - Handhelds / Satellite services to Handhelds (DVB-
  485. H/SH);
  486.  
  487. o ALC defines an on-demand content delivery model [RFC5775] where
  488. receivers can arrive at any time, at their own discretion,
  489. download the content and leave the session. Other models (e.g.,
  490. push or streaming) are also defined;
  491.  
  492.  
  493.  
  494.  
  495. Roca, et al. Experimental [Page 9]
  497. RFC 5776 TESLA in ALC and NORM April 2010
  498.  
  499.  
  500. o ALC sessions are potentially very long: a session can last several
  501. days or months during which the content is continuously
  502. transmitted within a carousel. The content can be either static
  503. (e.g., a software update) or dynamic (e.g., a web site).
  504.  
  505. Depending on the use case, some of the above features may not apply.
  506. For instance, ALC can also be used over a bidirectional channel or
  507. with a limited number of receivers.
  508.  
  509. In the case of NORM:
  510.  
  511. o NORM has been designed for medium-size sessions: indeed, NORM
  512. relies on feedback messages and the sender may collapse if the
  513. feedback message rate is too high;
  514.  
  515. o NORM requires a bidirectional transport channel: the back channel
  516. is not necessarily a high-data rate channel since the control
  517. traffic sent over it by a single receiver is an order of magnitude
  518. lower than the downstream traffic. Networks with an asymmetric
  519. connectivity (e.g., a high-rate satellite downlink and a low-rate
  520. return channel) are appropriate.
  521.  
  522. 2.2. Bootstrapping TESLA
  523.  
  524. In order to initialize the TESLA component at a receiver, the sender
  525. MUST communicate some key information in a secure way, so that the
  526. receiver can check the source of the information and its integrity.
  527. Two general methods are possible:
  528.  
  529. o by using an out-of-band mechanism, or
  530.  
  531. o by using an in-band mechanism.
  532.  
  533. The current specification does not recommend any mechanism to
  534. bootstrap TESLA. Choosing between an in-band and out-of-band scheme
  535. is left to the implementer, depending on the target use case.
  536. However, it is RECOMMENDED that TESLA implementations support the use
  537. of the in-band mechanism for interoperability purposes.
  538.  
  539. 2.2.1. Bootstrapping TESLA with an Out-Of-Band Mechanism
  540.  
  541. For instance, [RFC4442] describes the use of the MIKEY (Multimedia
  542. Internet Keying) protocol to bootstrap TESLA. As a side effect,
  543. MIKEY also provides a loose time synchronization feature from which
  544. TESLA can benefit. Other solutions, for instance, based on an
  545. extended session description, are possible, on the condition that
  546. these solutions provide the required security level.
  547.  
  548.  
  549.  
  550.  
  551. Roca, et al. Experimental [Page 10]
  553. RFC 5776 TESLA in ALC and NORM April 2010
  554.  
  555.  
  556. 2.2.2. Bootstrapping TESLA with an In-Band Mechanism
  557.  
  558. This specification describes an in-band mechanism. In some use
  559. cases, it might be desired that bootstrapping take place without
  560. requiring the use of an additional external mechanism. For instance,
  561. each device may feature a clock with a known time-drift that is
  562. negligible in front of the time accuracy required by TESLA, and each
  563. device may embed the public key of the sender. It is also possible
  564. that the use case does not feature a bidirectional channel that
  565. prevents the use of out-of-band protocols like MIKEY. For these two
  566. examples, the exchange of a bootstrap information message (described
  567. in Section 3.4.1) and the knowledge of a few additional parameters
  568. (listed below) are sufficient to bootstrap TESLA at a receiver.
  569.  
  570. Some parameters cannot be communicated in-band. In particular:
  571.  
  572. o the sender or group controller MUST either communicate the public
  573. key of the sender or a certificate (which also means that a PKI
  574. has been set up) to all receivers, so that each receiver be able
  575. to verify the signature of the bootstrap message and direct time
  576. synchronization response messages (when applicable).
  577.  
  578. o when time synchronization is performed with NTP/SNTP (Simple
  579. Network Time Protocol), the sender or group controller MUST
  580. communicate the list of valid NTP/SNTP servers to all the session
  581. members (sender included), so that they are all able to
  582. synchronize themselves on the same NTP/SNTP servers.
  583.  
  584. o when the Group MAC feature is used, the sender or group controller
  585. MUST communicate the K_g group key to all the session members
  586. (sender included). This group key may be periodically refreshed.
  587.  
  588. The way these parameters are communicated is out of the scope of this
  589. document.
  590.  
  591. 2.3. Setting Up a Secure Time Synchronization
  592.  
  593. The security offered by TESLA heavily relies on time. Therefore, the
  594. session's sender and each receiver need to be time synchronized in a
  595. secure way. To that purpose, two general methods exist:
  596.  
  597. o direct time synchronization, and
  598.  
  599. o indirect time synchronization.
  600.  
  601. It is also possible that a given session includes receivers that use
  602. the direct time synchronization mode while others use the indirect
  603. time synchronization mode.
  604.  
  605.  
  606.  
  607. Roca, et al. Experimental [Page 11]
  609. RFC 5776 TESLA in ALC and NORM April 2010
  610.  
  611.  
  612. 2.3.1. Direct Time Synchronization
  613.  
  614. When direct time synchronization is used, each receiver asks the
  615. sender for a time synchronization. To that purpose, a receiver sends
  616. a direct time synchronization request (Section 4.2.2.1). The sender
  617. then directly answers each request with a direct time synchronization
  618. response (Section 3.4.2), signing this reply. Upon receiving this
  619. response, a receiver first verifies the signature, and then
  620. calculates an upper bound of the lag of his clock with respect to the
  621. clock of the sender, D_t. The details on how to calculate D_t are
  622. given in Section 2.4.1.
  623.  
  624. This synchronization method is both simple and secure. Yet, there
  625. are two potential issues:
  626.  
  627. o a bidirectional channel must exist between the sender and each
  628. receiver, and
  629.  
  630. o the sender may collapse if the incoming request rate is too high.
  631.  
  632. Relying on direct time synchronization is not expected to be an issue
  633. with NORM since (1) bidirectional communications already take place,
  634. and (2) NORM scalability is anyway limited. Yet, it can be required
  635. that a mechanism, that is out of the scope of this document, be used
  636. to spread the transmission of direct time synchronization request
  637. messages over time if there is a risk that the sender may collapse.
  638.  
  639. But direct time synchronization is potentially incompatible with ALC
  640. since (1) there might not be a back channel, and (2) there are
  641. potentially a huge number of receivers and therefore a risk that the
  642. sender will collapse.
  643.  
  644. 2.3.2. Indirect Time Synchronization
  645.  
  646. When indirect time synchronization is used, the sender and each
  647. receiver must synchronize securely via an external time reference.
  648. Several possibilities exist:
  649.  
  650. o sender and receivers can synchronize through an NTPv3 (Network
  651. Time Protocol version 3) [RFC1305] hierarchy of servers. The
  652. authentication mechanism of NTPv3 MUST be used in order to
  653. authenticate each NTP message individually. It prevents, for
  654. instance, an attacker from impersonating an NTP server;
  655.  
  656. o they can synchronize through an NTPv4 (Network Time Protocol
  657. version 4) [NTP-NTPv4] hierarchy of servers. The Autokey security
  658. protocol of NTPv4 MUST be used in order to authenticate each NTP
  659. message individually;
  660.  
  661.  
  662.  
  663. Roca, et al. Experimental [Page 12]
  665. RFC 5776 TESLA in ALC and NORM April 2010
  666.  
  667.  
  668. o they can synchronize through an SNTPv4 (Simple Network Time
  669. Protocol version 4) [RFC4330] hierarchy of servers. The
  670. authentication features of SNTPv4 must then be used. Note that
  671. TESLA only needs a loose (but secure) time synchronization, which
  672. is in line with the time synchronization service offered by SNTP;
  673.  
  674. o they can synchronize through a GPS or Galileo (or similar) device
  675. that also provides a high precision time reference. Spoofing
  676. attacks on the GPS system have recently been reported. Depending
  677. on the use case, the security achieved will or will not be
  678. acceptable;
  679.  
  680. o they can synchronize thanks to a dedicated hardware, embedded on
  681. each sender and receiver, that provides a clock with a time-drift
  682. that is negligible in front of the TESLA time accuracy
  683. requirements. This feature enables a device to synchronize its
  684. embedded clock with the official time reference from time to time
  685. (in an extreme case once, at manufacturing time), and then to
  686. remain autonomous for a duration that depends on the known maximum
  687. clock drift.
  688.  
  689. A bidirectional channel is required by the NTP/SNTP schemes. On the
  690. opposite, with the GPS/Galileo and high precision clock schemes, no
  691. such assumption is made. In situations where ALC is used on purely
  692. unidirectional transport channels (Section 2.1), using the NTP/SNTP
  693. schemes is not possible. Another aspect is the scalability
  694. requirement of ALC, and to a lesser extent of NORM. From this point
  695. of view, the above mechanisms usually do not raise any problem,
  696. unlike the direct time synchronization schemes. Therefore, using
  697. indirect time synchronization can be a good choice. It should be
  698. noted that the NTP/SNTP schemes assume that each client trusts the
  699. sender and accepts aligning its NTP/SNTP configuration to that of the
  700. sender. If this assumption does not hold, the sender SHOULD offer an
  701. alternative solution.
  702.  
  703. The details on how to calculate an upper bound of the lag of a
  704. receiver's clock with respect to the clock of the sender, D_t, are
  705. given in Section 2.4.2.
  706.  
  707. 2.4. Determining the Delay Bounds
  708.  
  709. Let us assume that a secure time synchronization has been set up.
  710. This section explains how to define the various timing parameters
  711. that are used during the authentication of received packets.
  712.  
  713.  
  714.  
  715.  
  716.  
  717.  
  718.  
  719. Roca, et al. Experimental [Page 13]
  721. RFC 5776 TESLA in ALC and NORM April 2010
  722.  
  723.  
  724. 2.4.1. Delay Bound Calculation in Direct Time Synchronization Mode
  725.  
  726. In direct time synchronization mode, synchronization between a
  727. receiver and the sender follows the following protocol [RFC4082]:
  728.  
  729. o The receiver sends a direct time synchronization request message
  730. to the sender, that includes t_r, the receiver local time at the
  731. moment of sending (Section 4.2.2.1).
  732.  
  733. o Upon receipt of this message, the sender records its local time,
  734. t_s, and sends to the receiver a direct time synchronization
  735. response that includes t_r (taken from the request) and t_s,
  736. signing this reply (Section 3.4.2).
  737.  
  738. o Upon receiving this response, the receiver first verifies that he
  739. actually sent a request with t_r and then checks the signature.
  740. Then he calculates D_t = t_s - t_r + S_sr, where S_sr is an
  741. estimated bound of the clock drift between the sender and the
  742. receiver throughout the duration of the session. This document
  743. does not specify how S_sr is estimated.
  744.  
  745. After this initial synchronization, at any point throughout the
  746. session, the receiver knows that: T_s < T_r + D_t, where T_s is the
  747. current time at the sender and T_r is the current time at the
  748. receiver.
  749.  
  750. 2.4.2. Delay Bound Calculation in Indirect Time Synchronization Mode
  751.  
  752. In indirect time synchronization, the sender and the receivers must
  753. synchronize indirectly using one or several time references.
  754.  
  755. 2.4.2.1. Single Time Reference
  756.  
  757. Let us assume that there is a single time reference.
  758.  
  759. 1. The sender calculates D^O_t, the upper bound of the lag of the
  760. sender's clock with respect to the time reference. This D^O_t
  761. value is then communicated to the receivers (Section 3.2.1).
  762.  
  763. 2. Similarly, a receiver R calculates D^R_t, the upper bound of the
  764. lag of the receiver's clock with respect to the time reference.
  765.  
  766. 3. Then, for receiver R, the overall upper bound of the lag of the
  767. receiver's clock with respect to the clock of the sender, D_t, is
  768. the sum: D_t = D^O_t + D^R_t.
  769.  
  770.  
  771.  
  772.  
  773.  
  774.  
  775. Roca, et al. Experimental [Page 14]
  777. RFC 5776 TESLA in ALC and NORM April 2010
  778.  
  779.  
  780. The D^O_t and D^R_t calculation depends on the time synchronization
  781. mechanism used (Section 2.3.2). In some cases, the synchronization
  782. scheme specifications provide these values. In other cases, these
  783. parameters can be calculated by means of a scheme similar to the one
  784. specified in Section 2.4.1, for instance, when synchronization is
  785. achieved via a group controller [RFC4082].
  786.  
  787. 2.4.2.2. Multiple Time References
  788.  
  789. Let us now assume that there are several time references (e.g.,
  790. several NTP/SNTP servers). The sender and receivers first
  791. synchronize with the various time references, independently. It
  792. results in D^O_t and D^R_t. Let D_err be an upper bound of the time
  793. error between all of the time references. Then, the overall value of
  794. D_t within receiver R is set to the sum: D_t = D^O_t + D^R_t + D_err.
  795.  
  796. In some cases, the D_t value is part of the time synchronization
  797. scheme specifications. For instance, NTPv3 [RFC1305] defines
  798. algorithms that are "capable of accuracies in the order of a
  799. millisecond, even after extended periods when synchronization to
  800. primary reference sources has been lost". In practice, depending on
  801. the NTP server stratum, the accuracy might be a little bit worse. In
  802. that case, D_t = security_factor * (1ms + 1ms), where the
  803. security_factor is meant to compensate several sources of inaccuracy
  804. in NTP. The choice of the security_factor value is left to the
  805. implementer, depending on the target use case.
  806.  
  807. 2.5. Cryptographic Parameter Values
  808.  
  809. The F (resp. F') function output length is given by the n_p (resp.
  810. n_f) parameter. The n_p and n_f values depend on the PRF function
  811. chosen, as specified below:
  812.  
  813. +------------------------+---------------------+
  814. | PRF name | n_p and n_f |
  815. +------------------------+---------------------+
  816. | HMAC-SHA-1 | 160 bits (20 bytes) |
  817. | HMAC-SHA-224 | 224 bits (28 bytes) |
  818. | HMAC-SHA-256 (default) | 256 bits (32 bytes) |
  819. | HMAC-SHA-384 | 384 bits (48 bytes) |
  820. | HMAC-SHA-512 | 512 bits (64 bytes) |
  821. +------------------------+---------------------+
  822.  
  823. The computing of regular MAC (resp. Group MAC) makes use of the n_m
  824. (resp. n_w) parameter, i.e., the length of the truncated output of
  825. the function. The n_m and n_w values depend on the MAC function
  826. chosen, as specified below:
  827.  
  828.  
  829.  
  830.  
  831. Roca, et al. Experimental [Page 15]
  833. RFC 5776 TESLA in ALC and NORM April 2010
  834.  
  835.  
  836. +------------------------+---------------------+-------------------+
  837. | MAC name | n_m (regular MAC) | n_w (Group MAC) |
  838. +------------------------+---------------------+-------------------+
  839. | HMAC-SHA-1 | 80 bits (10 bytes) | 32 bits (4 bytes) |
  840. | HMAC-SHA-224 | 112 bits (14 bytes) | 32 bits (4 bytes) |
  841. | HMAC-SHA-256 (default) | 128 bits (16 bytes) | 32 bits (4 bytes) |
  842. | HMAC-SHA-384 | 192 bits (24 bytes) | 32 bits (4 bytes) |
  843. | HMAC-SHA-512 | 256 bits (32 bytes) | 32 bits (4 bytes) |
  844. +------------------------+---------------------+-------------------+
  845.  
  846. 3. Sender Operations
  847.  
  848. This section describes the TESLA operations at a sender. For more
  849. information on the TESLA protocol and its principles, please refer to
  850. [RFC4082][Perrig04].
  851.  
  852. 3.1. TESLA Parameters
  853.  
  854. 3.1.1. Time Intervals
  855.  
  856. The sender divides the time into uniform intervals of duration T_int.
  857. Time interval numbering starts at 0 and is incremented consecutively.
  858. The interval index MUST be stored in an unsigned 32-bit integer so
  859. that wrapping to 0 takes place only after 2^^32 intervals. For
  860. instance, if T_int is equal to 0.5 seconds, then wrapping takes place
  861. after approximately 68 years.
  862.  
  863. 3.1.2. Key Chains
  864.  
  865. 3.1.2.1. Principles
  866.  
  867. The sender computes a one-way key chain of n_c = N+1 keys, and
  868. assigns one key from the chain to each interval, consecutively but in
  869. reverse order. Key numbering starts at 0 and is incremented
  870. consecutively, following the time interval numbering: K_0, K_1, ...,
  871. K_N.
  872.  
  873. In order to compute this chain, the sender must first select a
  874. Primary Key, K_N, and a PRF function, f (Section 7, TESLA-PRF). The
  875. randomness of the Primary Key, K_N, is vital to the security and no
  876. one should be able to guess it.
  877.  
  878. The function F is a one-way function that is defined as: F(k) =
  879. f_k(0), where f_k(0) is the result of the application of the PRF f to
  880. k and 0. When f is an HMAC (Section 7), k is used as the key, and 0
  881. as the message, using the algorithm described in [RFC2104].
  882.  
  883.  
  884.  
  885.  
  886.  
  887. Roca, et al. Experimental [Page 16]
  889. RFC 5776 TESLA in ALC and NORM April 2010
  890.  
  891.  
  892. Similarly, the function F' is a one-way function that is defined as:
  893. F'(k) = f_k(1), where f_k(1) is the result of the application of the
  894. same PRF f to k and 1.
  895.  
  896. The sender then computes all the keys of the chain, recursively,
  897. starting with K_N, using: K_{i-1} = F(K_i). Therefore, K_i = F^{N-
  898. i}(K_N), where F^i(x) is the execution of function F with the
  899. argument x, i times. The receiver can then compute any value in the
  900. key chain from K_N, even if it does not have intermediate values
  901. [RFC4082]. The key for MAC calculation can then be derived from the
  902. corresponding K_i key by K'_i = F'(K_i).
  903.  
  904. The key chain has a finite length, N, which corresponds to a maximum
  905. time duration of (N + 1) * T_int. The content delivery session has a
  906. duration T_delivery, which may either be known in advance, or not. A
  907. first solution consists in having a single key chain of an
  908. appropriate length, so that the content delivery session finishes
  909. before the end of the key chain, i.e., T_delivery <= (N + 1) * T_int.
  910. But the longer the key chain, the higher the memory and computation
  911. required to cope with it. Another solution consists in switching to
  912. a new key chain, of the same length, when necessary [Perrig04].
  913.  
  914. 3.1.2.2. Using Multiple Key Chains
  915.  
  916. When several key chains are needed, all of them MUST be of the same
  917. length. Switching from the current key chain to the next one
  918. requires that a commitment to the new key chain be communicated in a
  919. secure way to the receiver. This can be done by using either an out-
  920. of-band mechanism or an in-band mechanism. This document only
  921. specifies the in-band mechanism.
  922.  
  923. < -------- old key chain --------- >||< -------- new key chain --...
  924. +-----+-----+ .. +-----+-----+-----+||+-----+-----+-----+-----+-----+
  925. 0 1 .. N-2 N-1 N || N+1 N+2 N+3 N+4 N+5
  926. ||
  927. Key disclosures: ||
  928. N/A N/A .. K_N-4 K_N-3 K_N-2 || K_N-1 K_N K_N+1 K_N+2 K_N+3
  929. | || | |
  930. |< -------------- >|| |< ------------- >|
  931. Additional key F(K_N+1) || K_N
  932. disclosures (commitment to || (last key of the
  933. (in parallel): the new chain) || old chain)
  934.  
  935. Figure 1: Switching to the Second Key Chain with the In-Band
  936. Mechanism, Assuming That d=2, n_tx_newkcc=3, n_tx_lastkey=3
  937.  
  938.  
  939.  
  940.  
  941.  
  942.  
  943. Roca, et al. Experimental [Page 17]
  945. RFC 5776 TESLA in ALC and NORM April 2010
  946.  
  947.  
  948. Figure 1 illustrates the switch to the new key chain, using the in-
  949. band mechanism. Let us say that the old key chain stops at K_N and
  950. the new key chain starts at K_{N+1} (i.e., F(K_{N+1}) and K_N are two
  951. different keys). Then, the sender includes the commitment F(K_{N+1})
  952. to the new key chain into packets authenticated with the old key
  953. chain (see Section 3.4.5). This commitment SHOULD be sent during
  954. n_tx_newkcc time intervals before the end of the old key chain.
  955. Since several packets are usually sent during an interval, the sender
  956. SHOULD alternate between sending a disclosed key of the old key chain
  957. and the commitment to the new key chain. The details of how to
  958. alternate between the disclosure and commitment are out of the scope
  959. of this document.
  960.  
  961. The receiver will keep the commitment until the key K_{N+1} is
  962. disclosed, at interval N+1+d. Then, the receiver will be able to
  963. test the validity of that key by computing F(K_{N+1}) and comparing
  964. it to the commitment.
  965.  
  966. When the key chain is changed, it becomes impossible to recover a
  967. previous key from the old key chain. This is a problem if the
  968. receiver lost the packets disclosing the last key of the old key
  969. chain. A solution consists in re-sending the last key, K_N, of the
  970. old key chain (see Section 3.4.6). This SHOULD be done during
  971. n_tx_lastkey additional time intervals after the end of the time
  972. interval where K_N is disclosed. Since several packets are usually
  973. sent during an interval, the sender SHOULD alternate between sending
  974. a disclosed key of the new key chain, and the last key of the old key
  975. chain. The details of how to alternate between the two disclosures
  976. are out of the scope of this document.
  977.  
  978. In some cases, a receiver having experienced a very long
  979. disconnection might have lost the commitment of the new chain.
  980. Therefore, this receiver will not be able to authenticate any packet
  981. related to the new chain or any of the following ones. The only
  982. solution for this receiver to catch up consists in receiving an
  983. additional bootstrap information message. This can happen by waiting
  984. for the next periodic transmission (if sent in-band) or through an
  985. external mechanism (Section 3.2.1).
  986.  
  987. 3.1.2.3. Values of the n_tx_lastkey and n_tx_newkcc Parameters
  988.  
  989. When several key chains and the in-band commitment mechanism are
  990. used, a sender MUST initialize the n_tx_lastkey and n_tx_newkcc
  991. parameters in such a way that no overlapping occurs. In other words,
  992. once a sender starts transmitting commitments for a new key chain, he
  993. MUST NOT send a disclosure for the last key of the old key chain any
  994. more. Therefore, the following property MUST be verified:
  995.  
  996.  
  997.  
  998.  
  999. Roca, et al. Experimental [Page 18]
  1001. RFC 5776 TESLA in ALC and NORM April 2010
  1002.  
  1003.  
  1004. d + n_tx_lastkey + n_tx_newkcc <= N + 1
  1005.  
  1006. It is RECOMMENDED, for robustness purposes, that, once n_tx_lastkey
  1007. has been chosen, then:
  1008.  
  1009. n_tx_newkcc = N + 1 - n_tx_lastkey - d
  1010.  
  1011. In other words, the sender starts transmitting a commitment to the
  1012. following key chain immediately after having sent all the disclosures
  1013. of the last key of the previous key chain. Doing so increases the
  1014. probability that a receiver gets a commitment for the following key
  1015. chain.
  1016.  
  1017. In any case, these two parameters are sender specific and need not be
  1018. transmitted to the receivers. Of course, as explained above, the
  1019. sender alternates between the disclosure of a key of the current key
  1020. chain and the commitment to the new key chain (or the last key of the
  1021. old key chain).
  1022.  
  1023. 3.1.2.4. The Particular Case of the Session Start
  1024.  
  1025. Since a key cannot be disclosed before the disclosure delay, d, no
  1026. key will be disclosed during the first d time intervals (intervals 0
  1027. and 1 in Figure 1) of the session. To that purpose, the sender uses
  1028. the Authentication Tag without Key Disclosure, Section 3.4.4. The
  1029. following key chains, if any, are not concerned since they will
  1030. disclose the last d keys of the previous chain.
  1031.  
  1032. 3.1.2.5. Managing Silent Periods
  1033.  
  1034. An ALC or NORM sender may stop transmitting packets for some time.
  1035. For instance, it can be the end of the session and all packets have
  1036. already been sent, or the use case may consist in a succession of
  1037. busy periods (when fresh objects are available) followed by silent
  1038. periods. In any case, this is an issue since the authentication of
  1039. the packets sent during the last d intervals requires that the
  1040. associated keys be disclosed, which will take place during d
  1041. additional time intervals.
  1042.  
  1043. To solve this problem, it is recommended that the sender transmit
  1044. empty packets (i.e., without payload) containing the TESLA EXT_AUTH
  1045. Header Extension along with a Standard Authentication Tag during at
  1046. least d time intervals after the end of the regular ALC or NORM
  1047. packet transmissions. The number of such packets and the duration
  1048. during which they are sent must be sufficient for all receivers to
  1049. receive, with a high probability, at least one packet disclosing the
  1050. last useful key (i.e., the key used for the last non-empty packet
  1051. sent).
  1052.  
  1053.  
  1054.  
  1055. Roca, et al. Experimental [Page 19]
  1057. RFC 5776 TESLA in ALC and NORM April 2010
  1058.  
  1059.  
  1060. 3.1.3. Time Interval Schedule
  1061.  
  1062. The sender must determine the following parameters:
  1063.  
  1064. o T_0, the start time corresponding to the beginning of the session,
  1065. i.e., the beginning of time interval 0 (in NTP timestamp format);
  1066.  
  1067. o T_int, the interval duration (in milliseconds), usually ranging
  1068. from 100 milliseconds to 1 second;
  1069.  
  1070. o d, the key disclosure delay (in number of intervals). It is the
  1071. time to wait before disclosing a key;
  1072.  
  1073. o N, the length of a key chain.
  1074.  
  1075. The correct choice of T_int, d, and N is crucial for the efficiency
  1076. of the scheme. For instance, a T_int * d product that is too long
  1077. will cause excessive delay in the authentication process. A T_int *
  1078. d product that is too short prevents many receivers from verifying
  1079. packets. An N * T_int product that is too small will cause the
  1080. sender to switch too often to new key chains. An N that is too long
  1081. with respect to the expected session duration (if known) will require
  1082. the sender to compute too many useless keys. Sections 3.2 and 3.6 of
  1083. [RFC4082] give general guidelines for initializing these parameters.
  1084.  
  1085. The T_0, T_int, d, and N parameters MUST NOT be changed during the
  1086. lifetime of the session. This restriction is meant to prevent
  1087. introducing vulnerabilities. For instance, if a sender was
  1088. authorized to change the key disclosure schedule, a receiver that did
  1089. not receive the change notification would still believe in the old
  1090. key disclosure schedule, thereby creating vulnerabilities [RFC4082].
  1091.  
  1092. 3.1.4. Timing Parameters
  1093.  
  1094. In indirect time synchronization mode, the sender must determine the
  1095. following parameter:
  1096.  
  1097. o D^O_t, the upper bound of the lag of the sender's clock with
  1098. respect to the time reference.
  1099.  
  1100. The D^O_t parameter MUST NOT be changed during the lifetime of the
  1101. session.
  1102.  
  1103.  
  1104.  
  1105.  
  1106.  
  1107.  
  1108.  
  1109.  
  1110.  
  1111. Roca, et al. Experimental [Page 20]
  1113. RFC 5776 TESLA in ALC and NORM April 2010
  1114.  
  1115.  
  1116. 3.2. TESLA Signaling Messages
  1117.  
  1118. At a sender, TESLA produces two types of signaling information:
  1119.  
  1120. o The bootstrap information: it can be either sent out-of-band or
  1121. in-band. In the latter case, a digitally signed packet contains
  1122. all the information required to bootstrap TESLA at a receiver;
  1123.  
  1124. o The direct time synchronization response, which enables a receiver
  1125. to finish a direct time synchronization.
  1126.  
  1127. 3.2.1. Bootstrap Information
  1128.  
  1129. In order to initialize the TESLA component at a receiver, the sender
  1130. must communicate some key information in a secure way. This
  1131. information can be sent in-band or out-of-band, as discussed in
  1132. Section 2.2. In this section, we only consider the in-band scheme.
  1133.  
  1134. The TESLA bootstrap information message MUST be digitally signed
  1135. (Section 3.3.2). The goal is to enable a receiver to check the
  1136. packet source and packet integrity. Then, the bootstrap information
  1137. can be:
  1138.  
  1139. o unicast to a receiver during a direct time synchronization
  1140. request/response exchange;
  1141.  
  1142. o broadcast to all receivers. This is typically the case in
  1143. indirect time synchronization mode. It can also be used in direct
  1144. time synchronization mode, for instance, when a large number of
  1145. clients arrive at the same time, in which case it is more
  1146. efficient to answer globally.
  1147.  
  1148. Let us consider situations where the bootstrap information is
  1149. broadcast. This message should be broadcast at the beginning of the
  1150. session, before data packets are actually sent. This is particularly
  1151. important with ALC or NORM sessions in "push" mode, when all clients
  1152. join the session in advance. For improved reliability, bootstrap
  1153. information might be sent a certain number of times.
  1154.  
  1155. A periodic broadcast of the bootstrap information message could also
  1156. be useful when:
  1157.  
  1158. o the ALC session uses an "on-demand" mode, clients arriving at
  1159. their own discretion;
  1160.  
  1161.  
  1162.  
  1163.  
  1164.  
  1165.  
  1166.  
  1167. Roca, et al. Experimental [Page 21]
  1169. RFC 5776 TESLA in ALC and NORM April 2010
  1170.  
  1171.  
  1172. o some clients experience an intermittent connectivity. This is
  1173. particularly important when several key chains are used in an ALC
  1174. or NORM session, since there is a risk that a receiver loses all
  1175. the commitments to the new key chain.
  1176.  
  1177. A balance must be found between the signaling overhead and the
  1178. maximum initial waiting time at the receiver before starting the
  1179. delayed authentication process. A period of a few seconds for the
  1180. transmission of this bootstrap information is often a reasonable
  1181. value.
  1182.  
  1183. 3.2.2. Direct Time Synchronization Response
  1184.  
  1185. In direct time synchronization, upon receipt of a synchronization
  1186. request, the sender records its local time, t_s, and sends a response
  1187. message that contains both t_r and t_s (Section 2.4.1). This message
  1188. is unicast to the receiver. This direct time synchronization
  1189. response message MUST be digitally signed in order to enable a
  1190. receiver to check the packet source and packet integrity
  1191. (Section 3.3.2). The receiver MUST also be able to associate this
  1192. response and his request, which is the reason why t_r is included in
  1193. the response message.
  1194.  
  1195. 3.3. TESLA Authentication Information
  1196.  
  1197. At a sender, TESLA produces three types of security tags:
  1198.  
  1199. o an authentication tag, in case of data packets, and which contains
  1200. the MAC of the packet;
  1201.  
  1202. o a digital signature, in case of one of the two TESLA signaling
  1203. packets, namely a bootstrap information message or a direct time
  1204. synchronization response; and
  1205.  
  1206. o an optional group authentication tag, that can be added to all the
  1207. packets to mitigate attacks coming from outside of the group.
  1208.  
  1209. Because of interdependencies, their computation MUST follow a strict
  1210. order:
  1211.  
  1212. o first of all, compute the authentication tag (with data packet) or
  1213. the digital signature (with signaling packet);
  1214.  
  1215. o finally, compute the Group Mac.
  1216.  
  1217.  
  1218.  
  1219.  
  1220.  
  1221.  
  1222.  
  1223. Roca, et al. Experimental [Page 22]
  1225. RFC 5776 TESLA in ALC and NORM April 2010
  1226.  
  1227.  
  1228. 3.3.1. Authentication Tags
  1229.  
  1230. All the data packets sent MUST have an authentication tag containing:
  1231.  
  1232. o the interval index, i, which is also the index of the key used for
  1233. computing the MAC of this packet;
  1234.  
  1235. o the MAC of the message: MAC(K'_i, M), where K'_i=F'(K_i);
  1236.  
  1237. o either a disclosed key (which belongs to the current key chain or
  1238. the previous key chain), or a commitment to a new key chain, or no
  1239. key at all.
  1240.  
  1241. The computation of MAC(K'_i, M) MUST include the ALC or NORM header
  1242. (with the various header extensions) and the payload (when
  1243. applicable). The UDP/IP headers MUST NOT be included. During this
  1244. computation, the "MAC(K'_i, M)" field of the authentication tag MUST
  1245. be set to 0.
  1246.  
  1247. 3.3.2. Digital Signatures
  1248.  
  1249. The bootstrap information message (with the in-band bootstrap scheme)
  1250. and direct time synchronization response message (with the indirect
  1251. time synchronization scheme) both need to be signed by the sender.
  1252. These two messages contain a "Signature" field to hold the digital
  1253. signature. The bootstrap information message also contains the
  1254. "Signature Encoding Algorithm", the "Signature Cryptographic
  1255. Function", and the "Signature Length" fields that enable a receiver
  1256. to process the "Signature" field. Note that there are no such
  1257. "Signature Encoding Algorithm", "Signature Cryptographic Function",
  1258. and "Signature Length" fields in the case of a direct time
  1259. synchronization response message since it is assumed that these
  1260. parameters are already known (i.e., the receiver either received a
  1261. bootstrap information message before or these values have been
  1262. communicated out-of-band).
  1263.  
  1264. Several "Signature Encoding Algorithms" can be used, including
  1265. RSASSA-PKCS1-v1_5, the default, and RSASSA-PSS (Section 7). With
  1266. these encodings, SHA-256 is the default "Signature Cryptographic
  1267. Function".
  1268.  
  1269. The computation of the signature MUST include the ALC or NORM header
  1270. (with the various header extensions) and the payload when applicable.
  1271. The UDP/IP headers MUST NOT be included. During this computation,
  1272. the "Signature" field MUST be set to 0 as well as the optional Group
  1273. MAC, when present, since this Group MAC is calculated later.
  1274.  
  1275.  
  1276.  
  1277.  
  1278.  
  1279. Roca, et al. Experimental [Page 23]
  1281. RFC 5776 TESLA in ALC and NORM April 2010
  1282.  
  1283.  
  1284. More specifically, from [RFC4359]: Digital signature generation is
  1285. performed as described in [RFC3447], Section 8.2.1 for RSASSA-PKCS1-
  1286. v1_5 and Section 8.1.1 for RSASSA-PSS. The authenticated portion of
  1287. the packet is used as the message M, which is passed to the signature
  1288. generation function. The signer's RSA private key is passed as K.
  1289. In summary, (when SHA-256 is used), the signature generation process
  1290. computes a SHA-256 hash of the authenticated packet bytes, signs the
  1291. SHA-256 hash using the private key, and encodes the result with the
  1292. specified RSA encoding type. This process results in a value S,
  1293. which is the digital signature to be included in the packet.
  1294.  
  1295. With RSASSA-PKCS1-v1_5 and RSASSA-PSS signatures, the size of the
  1296. signature is equal to the "RSA modulus", unless the "RSA modulus" is
  1297. not a multiple of 8 bits. In that case, the signature MUST be
  1298. prepended with between 1 and 7 bits set to zero such that the
  1299. signature is a multiple of 8 bits [RFC4359]. The key size, which in
  1300. practice is also equal to the "RSA modulus", has major security
  1301. implications. [RFC4359] explains how to choose this value depending
  1302. on the maximum expected lifetime of the session. This choice is out
  1303. of the scope of this document.
  1304.  
  1305. 3.3.3. Group MAC Tags
  1306.  
  1307. An optional Group MAC can be used to mitigate Denial-of-Service (DoS)
  1308. attacks coming from attackers that are not group members [RFC4082].
  1309. This feature assumes that a group key, K_g, is shared by the sender
  1310. and all receivers. When the attacker is not a group member, the
  1311. benefits of adding a Group MAC to every packet sent are threefold:
  1312.  
  1313. o a receiver can immediately drop faked packets, without having to
  1314. wait for the disclosure delay, d;
  1315.  
  1316. o a sender can immediately drop faked direct time synchronization
  1317. requests, and avoid checking the digital signature, a computation
  1318. intensive task;
  1319.  
  1320. o a receiver can immediately drop faked direct time synchronization
  1321. response and bootstrap messages, without having to verify the
  1322. digital signature, a computation-intensive task.
  1323.  
  1324. The computation of the Group MAC, MAC(K_g, M), MUST include the ALC
  1325. or NORM header (with the various header extensions) and the payload
  1326. when applicable. The UDP/IP headers MUST NOT be included. During
  1327. this computation, the "Group MAC" field MUST be set to 0. However,
  1328. the digital signature (e.g., of a bootstrap message) and the "MAC"
  1329. fields (e.g., of an authentication tag), when present, MUST have been
  1330.  
  1331.  
  1332.  
  1333.  
  1334.  
  1335. Roca, et al. Experimental [Page 24]
  1337. RFC 5776 TESLA in ALC and NORM April 2010
  1338.  
  1339.  
  1340. calculated since they are included in the Group MAC calculation
  1341. itself. Then, the sender truncates the MAC output to keep the n_w
  1342. most significant bits and stores the result in the "Group MAC" field.
  1343.  
  1344. This scheme features a few limits:
  1345.  
  1346. o it is of no help if a group member (who knows K_g) impersonates
  1347. the sender and sends forged messages to other receivers;
  1348.  
  1349. o it requires an additional MAC computing for each packet, both at
  1350. the sender and receiver sides;
  1351.  
  1352. o it increases the size of the TESLA authentication headers. In
  1353. order to limit this problem, the length of the truncated output of
  1354. the MAC, n_w, SHOULD be kept small (e.g., 32 bits) (see [RFC3711],
  1355. Section 9.5). As a side effect, the authentication service is
  1356. significantly weakened: the probability of any forged packet being
  1357. successfully authenticated becomes one in 2^32. Since the Group
  1358. MAC check is only a pre-check that must be followed by the
  1359. standard TESLA authentication check, this is not considered to be
  1360. an issue.
  1361.  
  1362. For a given use case, the benefits brought by the Group MAC must be
  1363. balanced against these limitations.
  1364.  
  1365. Note that the Group MAC function can be different from the TESLA MAC
  1366. function (e.g., it can use a weaker but faster MAC function). Note
  1367. also that the mechanism by which the group key, K_g, is communicated
  1368. to all group members, and perhaps periodically updated, is out of the
  1369. scope of this document.
  1370.  
  1371. 3.4. Format of TESLA Messages and Authentication Tags
  1372.  
  1373. This section specifies the format of the various kinds of TESLA
  1374. messages and authentication tags sent by the session's sender.
  1375. Because these TESLA messages are carried as EXT_AUTH Header
  1376. Extensions of the ALC or NORM packets (Section 5), the following
  1377. formats do not start on 32-bit word boundaries.
  1378.  
  1379.  
  1380.  
  1381.  
  1382.  
  1383.  
  1384.  
  1385.  
  1386.  
  1387.  
  1388.  
  1389.  
  1390.  
  1391. Roca, et al. Experimental [Page 25]
  1393. RFC 5776 TESLA in ALC and NORM April 2010
  1394.  
  1395.  
  1396. 3.4.1. Format of a Bootstrap Information Message
  1397.  
  1398. When bootstrap information is sent in-band, the following message is
  1399. used:
  1400.  
  1401. 0 1 2 3
  1402. 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
  1403. +-+-+-+-+-+-+-+-+ ---
  1404. | V |resvd|S|G|A| ^
  1405. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
  1406. | d | PRF Type | MAC Func Type |Gr MAC Fun Type| | f
  1407. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | i
  1408. | SigEncAlgo | SigCryptoFunc | Signature Length | | x
  1409. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | e
  1410. | Reserved | T_int | | d
  1411. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
  1412. | | | l
  1413. + T_0 (NTP timestamp format) + | e
  1414. | | | n
  1415. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | g
  1416. | N (Key Chain Length) | | t
  1417. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h
  1418. | Current Interval Index i | v
  1419. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
  1420. | |
  1421. ~ Current Key Chain Commitment +-+-+-+-+-+-+-+-+
  1422. | | Padding |
  1423. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1424. | |
  1425. + +
  1426. ~ Signature ~
  1427. + +-+-+-+-+-+-+-+-+
  1428. | | Padding |
  1429. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1430. |P| |
  1431. +-+ D^O_t Extension (optional, present if A==1) +
  1432. | (NTP timestamp diff, positive if P==1, negative if P==0) |
  1433. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1434. ~ Group MAC (optional) ~
  1435. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1436.  
  1437. Figure 2: Bootstrap Information Format
  1438.  
  1439.  
  1440.  
  1441.  
  1442.  
  1443.  
  1444.  
  1445.  
  1446.  
  1447. Roca, et al. Experimental [Page 26]
  1449. RFC 5776 TESLA in ALC and NORM April 2010
  1450.  
  1451.  
  1452. The format of the bootstrap information is depicted in Figure 2. The
  1453. fields are:
  1454.  
  1455. "V" (Version) field (2 bits):
  1456.  
  1457. The "V" field contains the version number of the protocol. For
  1458. this specification, the value of 0 MUST be used.
  1459.  
  1460. "Reserved" field (3 bits):
  1461.  
  1462. This is a reserved field that MUST be set to zero in this
  1463. specification.
  1464.  
  1465. "S" (Single Key Chain) flag (1 bit):
  1466.  
  1467. The "S" flag indicates whether this TESLA session is restricted to
  1468. a single key chain (S==1) or relies on one or multiple key chains
  1469. (S==0).
  1470.  
  1471. "G" (Group MAC Present) flag (1 bit):
  1472.  
  1473. The "G" flag indicates whether the Group MAC feature is used
  1474. (G==1) or not (G==0). When it is used, a "Group MAC" field is
  1475. added to all the packets containing a TESLA EXT_AUTH Header
  1476. Extension (including this bootstrap message).
  1477.  
  1478. "A" flag (1 bit):
  1479.  
  1480. The "A" flag indicates whether the "P" flag and "D^O_t" fields are
  1481. present (A==1) or not (A==0). In indirect time synchronization
  1482. mode, A MUST be equal to 1 since these fields are needed.
  1483.  
  1484. "d" field (8 bits):
  1485.  
  1486. "d" is an unsigned integer that defines the key disclosure delay
  1487. (in number of intervals). d MUST be greater than or equal to 2.
  1488.  
  1489. "PRF Type" field (8 bits):
  1490.  
  1491. The "PRF Type" is the reference number of the f function used to
  1492. derive the F (for key chain) and F' (for MAC keys) functions
  1493. (Section 7).
  1494.  
  1495. "MAC Function Type" field (8 bits):
  1496.  
  1497. The "MAC Function Type" is the reference number of the function
  1498. used to compute the MAC of the packets (Section 7).
  1499.  
  1500.  
  1501.  
  1502.  
  1503. Roca, et al. Experimental [Page 27]
  1505. RFC 5776 TESLA in ALC and NORM April 2010
  1506.  
  1507.  
  1508. "Group MAC Function Type" field (8 bits):
  1509.  
  1510. When G==1, this field contains the reference number of the
  1511. cryptographic MAC function used to compute the Group MAC
  1512. (Section 7). When G==0, this field MUST be set to zero.
  1513.  
  1514. "Signature Encoding Algorithm" field (8 bits):
  1515.  
  1516. The "Signature Encoding Algorithm" is the reference number
  1517. (Section 7) of the digital signature used to authenticate this
  1518. bootstrap information and included in the "Signature" field.
  1519.  
  1520. "Signature Cryptographic Function" field (8 bits):
  1521.  
  1522. The "Signature Cryptographic Function" is the reference number
  1523. (Section 7) of the cryptographic function used within the digital
  1524. signature.
  1525.  
  1526. "Signature Length" field (16 bits):
  1527.  
  1528. The "Signature Length" is an unsigned integer that indicates the
  1529. "Signature" field size in bytes in the "Signature Extension"
  1530. field. This is also the signature key length, since both
  1531. parameters are equal.
  1532.  
  1533. "Reserved" fields (16 bits):
  1534.  
  1535. This is a reserved field that MUST be set to zero in this
  1536. specification.
  1537.  
  1538. "T_int" field (16 bits):
  1539.  
  1540. "T_int" is an unsigned 16-bit integer that defines the interval
  1541. duration (in milliseconds).
  1542.  
  1543. "T_0" field (64 bits):
  1544.  
  1545. "T_0" is a timestamp in NTP timestamp format that indicates the
  1546. beginning of the session, i.e., the beginning of time interval 0.
  1547.  
  1548. "N" field (32 bits):
  1549.  
  1550. "N" is an unsigned integer that indicates the key chain length.
  1551. There are N + 1 keys per chain.
  1552.  
  1553.  
  1554.  
  1555.  
  1556.  
  1557.  
  1558.  
  1559. Roca, et al. Experimental [Page 28]
  1561. RFC 5776 TESLA in ALC and NORM April 2010
  1562.  
  1563.  
  1564. "i" (Interval Index of K_i) field (32 bits):
  1565.  
  1566. "i" is an unsigned integer that indicates the current interval
  1567. index when this bootstrap information message is sent.
  1568.  
  1569. "Current Key Chain Commitment" field (variable size, padded if
  1570. necessary for 32-bit word alignment):
  1571.  
  1572. "Key Chain Commitment" is the commitment to the current key chain,
  1573. i.e., the key chain corresponding to interval i. For instance,
  1574. with the first key chain, this commitment is equal to F(K_0), with
  1575. the second key chain, this commitment is equal to F(K_{N+1}),
  1576. etc.). If need be, this field is padded (with 0) up to a multiple
  1577. of 32 bits.
  1578.  
  1579. "Signature" field (variable size, padded if necessary for 32-bit word
  1580. alignment):
  1581.  
  1582. The "Signature" field is mandatory. It contains a digital
  1583. signature of this message, as specified by the encoding algorithm,
  1584. cryptographic function, and key length parameters. If the
  1585. signature length is not a multiple of 32 bits, this field is
  1586. padded with 0.
  1587.  
  1588. "P" flag (optional, 1 bit if present):
  1589.  
  1590. The "P" flag is optional and only present if the "A" flag is equal
  1591. to 1. It is only used in indirect time synchronization mode.
  1592. This flag indicates whether the D^O_t NTP timestamp difference is
  1593. positive (P==1) or negative (P==0).
  1594.  
  1595. "D^O_t" field (optional, 63 bits if present):
  1596.  
  1597. The "D^O_t" field is optional and only present if the "A" flag is
  1598. equal to 1. It is only used in indirect time synchronization
  1599. mode. It is the upper bound of the lag of the sender's clock with
  1600. respect to the time reference. When several time references are
  1601. specified (e.g., several NTP servers), then D^O_t is the maximum
  1602. upper bound of the lag with each time reference. D^O_t is
  1603. composed of two unsigned integers, as with NTP timestamps: the
  1604. first 31 bits give the time difference in seconds and the
  1605. remaining 32 bits give the sub-second time difference.
  1606.  
  1607.  
  1608.  
  1609.  
  1610.  
  1611.  
  1612.  
  1613.  
  1614.  
  1615. Roca, et al. Experimental [Page 29]
  1617. RFC 5776 TESLA in ALC and NORM April 2010
  1618.  
  1619.  
  1620. "Group MAC" field (optional, variable length, multiple of 32 bits):
  1621.  
  1622. This field contains the Group MAC, calculated with the group key,
  1623. K_g, shared by all group members. The field length, in bits, is
  1624. given by n_w, which is known once the Group MAC function type is
  1625. known (Section 7).
  1626.  
  1627. Note that the first byte and the following seven 32-bit words are
  1628. mandatory fixed-length fields. The "Current Key Chain Commitment"
  1629. and "Signature" fields are mandatory but variable-length fields. The
  1630. remaining "D^O_t" and "Group MAC" fields are optional.
  1631.  
  1632. In order to prevent attacks, some parameters MUST NOT be changed
  1633. during the lifetime of the session (Sections 3.1.3 and 3.1.4). The
  1634. following table summarizes the parameter's status:
  1635.  
  1636. +--------------------------+----------------------------------------+
  1637. | Parameter | Status |
  1638. +--------------------------+----------------------------------------+
  1639. | V | set to 0 in this specification |
  1640. | S | static (during whole session) |
  1641. | G | static (during whole session) |
  1642. | A | static (during whole session) |
  1643. | T_O | static (during whole session) |
  1644. | T_int | static (during whole session) |
  1645. | d | static (during whole session) |
  1646. | N | static (during whole session) |
  1647. | D^O_t (if present) | static (during whole session) |
  1648. | PRF Type | static (during whole session) |
  1649. | MAC Function Type | static (during whole session) |
  1650. | Signature Encoding | static (during whole session) |
  1651. | Algorithm | |
  1652. | Signature Crypto. | static (during whole session) |
  1653. | Function | |
  1654. | Signature Length | static (during whole session) |
  1655. | Group MAC Func. Type | static (during whole session) |
  1656. | i | dynamic (related to current key chain) |
  1657. | K_i | dynamic (related to current key chain) |
  1658. | signature | dynamic, packet dependent |
  1659. | Group MAC (if present) | dynamic, packet dependent |
  1660. +--------------------------+----------------------------------------+
  1661.  
  1662.  
  1663.  
  1664.  
  1665.  
  1666.  
  1667.  
  1668.  
  1669.  
  1670.  
  1671. Roca, et al. Experimental [Page 30]
  1673. RFC 5776 TESLA in ALC and NORM April 2010
  1674.  
  1675.  
  1676. 3.4.2. Format of a Direct Time Synchronization Response
  1677.  
  1678. 0 1 2 3
  1679. 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
  1680. +-+-+-+-+-+-+-+-+
  1681. | Reserved |
  1682. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1683. | |
  1684. + t_s (NTP timestamp) +
  1685. | |
  1686. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1687. | |
  1688. + t_r (NTP timestamp) +
  1689. | |
  1690. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1691. | |
  1692. + +
  1693. ~ Signature ~
  1694. + +-+-+-+-+-+-+-+-+
  1695. | | Padding |
  1696. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1697. ~ Group MAC (optional) ~
  1698. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1699.  
  1700. Figure 3: Format of a Direct Time Synchronization Response
  1701.  
  1702. The response to a direct time synchronization request contains the
  1703. following information:
  1704.  
  1705. "Reserved" field (8 bits):
  1706.  
  1707. This is a reserved field that MUST be set to zero in this
  1708. specification.
  1709.  
  1710. "t_s" (NTP timestamp, 64 bits):
  1711.  
  1712. "t_s" is a timestamp in NTP timestamp format that corresponds to
  1713. the sender local time value when receiving the direct time
  1714. synchronization request message.
  1715.  
  1716. "t_r" (NTP timestamp, 64 bits):
  1717.  
  1718. "t_r" is a timestamp in NTP timestamp format that contains the
  1719. receiver local time value received in the direct time
  1720. synchronization request message.
  1721.  
  1722.  
  1723.  
  1724.  
  1725.  
  1726.  
  1727. Roca, et al. Experimental [Page 31]
  1729. RFC 5776 TESLA in ALC and NORM April 2010
  1730.  
  1731.  
  1732. "Signature" field (variable size, padded if necessary for 32-bit word
  1733. alignment):
  1734.  
  1735. The "Signature" field is mandatory. It contains a digital
  1736. signature of this message, as specified by the encoding algorithm,
  1737. cryptographic function, and key length parameters communicated in
  1738. the bootstrap information message (if applicable) or out-of-band.
  1739. If the signature length is not a multiple of 32 bits, this field
  1740. is padded with 0.
  1741.  
  1742. "Group MAC" field (optional, variable length, multiple of 32 bits):
  1743.  
  1744. This field contains the Group MAC, calculated with the group key,
  1745. K_g, shared by all group members. The field length, in bits, is
  1746. given by n_w, which is known once the Group MAC function type is
  1747. known (Section 7).
  1748.  
  1749. 3.4.3. Format of a Standard Authentication Tag
  1750.  
  1751. 0 1 2 3
  1752. 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
  1753. +-+-+-+-+-+-+-+-+
  1754. | Reserved |
  1755. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1756. | i (Interval Index of K'_i) |
  1757. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1758. | |
  1759. ~ Disclosed Key K_{i-d} ~
  1760. | |
  1761. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1762. | |
  1763. ~ MAC(K'_i, M) +-+-+-+-+-+-+-+-+
  1764. | | Padding |
  1765. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1766. ~ Group MAC (optional) ~
  1767. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1768.  
  1769. Figure 4: Format of the Standard Authentication Tag
  1770.  
  1771. A Standard Authentication Tag is composed of the following fields:
  1772.  
  1773. "Reserved" field (8 bits):
  1774.  
  1775. The "Reserved" field is not used in the current specification and
  1776. MUST be set to zero by the sender.
  1777.  
  1778.  
  1779.  
  1780.  
  1781.  
  1782.  
  1783. Roca, et al. Experimental [Page 32]
  1785. RFC 5776 TESLA in ALC and NORM April 2010
  1786.  
  1787.  
  1788. "i" (Interval Index) field (32 bits):
  1789.  
  1790. "i" is the interval index associated with the key (K'_i) used to
  1791. compute the MAC of this packet.
  1792.  
  1793. "Disclosed Key" (variable size, non padded):
  1794.  
  1795. The "Disclosed Key" is the key used for interval i-d: K_{i-d}.
  1796. There is no padding between the "Disclosed Key" and "MAC(K'_i, M)"
  1797. fields, and the latter MAY not start on a 32-bit boundary,
  1798. depending on the n_p parameter.
  1799.  
  1800. "MAC(K'_i, M)" (variable size, padded if necessary for 32-bit word
  1801. alignment):
  1802.  
  1803. "MAC(K'_i, M)" is the truncated message authentication code of the
  1804. current packet. Only the n_m most significant bits of the MAC
  1805. output are kept [RFC2104].
  1806.  
  1807. "Group MAC" field (optional, variable length, multiple of 32 bits):
  1808.  
  1809. This field contains the Group MAC, calculated with a group key,
  1810. K_g, shared by all group members. The field length is given by
  1811. n_w, in bits.
  1812.  
  1813. Note that because a key cannot be disclosed before the disclosure
  1814. delay, d, the sender MUST NOT use this tag during the first d
  1815. intervals of the session: {0 .. d-1} (inclusive). Instead, the
  1816. sender MUST use an Authentication Tag without Key Disclosure.
  1817.  
  1818. 3.4.4. Format of an Authentication Tag without Key Disclosure
  1819.  
  1820. The Authentication Tag without Key Disclosure is meant to be used in
  1821. situations where a high number of packets are sent in a given time
  1822. interval. In such a case, it can be advantageous to disclose the
  1823. K_{i-d} key only in a subset of the packets sent, using a Standard
  1824. Authentication Tag, and to use the shortened version that does not
  1825. disclose the K_{i-d} key in the remaining packets. It is left to the
  1826. implementer to decide how many packets should disclose the K_{i-d}
  1827. key. This Authentication Tag without Key Disclosure MUST also be
  1828. used during the first d intervals: {0 .. d-1} (inclusive).
  1829.  
  1830.  
  1831.  
  1832.  
  1833.  
  1834.  
  1835.  
  1836.  
  1837.  
  1838.  
  1839. Roca, et al. Experimental [Page 33]
  1841. RFC 5776 TESLA in ALC and NORM April 2010
  1842.  
  1843.  
  1844. 0 1 2 3
  1845. 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
  1846. +-+-+-+-+-+-+-+-+
  1847. | Reserved |
  1848. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1849. | i (Interval Index of K'_i) |
  1850. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1851. | |
  1852. ~ MAC(K'_i, M) +-+-+-+-+-+-+-+-+
  1853. | | Padding |
  1854. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1855. ~ Group MAC (optional) ~
  1856. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1857.  
  1858. Figure 5: Format of the Authentication Tag without Key Disclosure
  1859.  
  1860. 3.4.5. Format of an Authentication Tag with a "New Key Chain"
  1861. Commitment
  1862.  
  1863. During the last n_tx_newkcc intervals of the current key chain, the
  1864. sender SHOULD send commitments to the next key chain. This is done
  1865. by replacing the disclosed key of the Authentication Tag with a New
  1866. Key Chain Commitment, F(K_{N+1}) (or F(K_{2N+2}) in case of a switch
  1867. between the second and third key chains, etc.) Figure 6 shows the
  1868. corresponding format.
  1869.  
  1870. Note that since there is no padding between the "F(K_{N+1})" and
  1871. "MAC(K'_i, M)" fields, the latter MAY not start on a 32-bit boundary,
  1872. depending on the n_p parameter.
  1873.  
  1874.  
  1875.  
  1876.  
  1877.  
  1878.  
  1879.  
  1880.  
  1881.  
  1882.  
  1883.  
  1884.  
  1885.  
  1886.  
  1887.  
  1888.  
  1889.  
  1890.  
  1891.  
  1892.  
  1893.  
  1894.  
  1895. Roca, et al. Experimental [Page 34]
  1897. RFC 5776 TESLA in ALC and NORM April 2010
  1898.  
  1899.  
  1900. 0 1 2 3
  1901. 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
  1902. +-+-+-+-+-+-+-+-+
  1903. | Reserved |
  1904. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1905. | i (Interval Index of K'_i) |
  1906. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1907. | |
  1908. ~ New Key Commitment F(K_{N+1}) ~
  1909. | |
  1910. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1911. | |
  1912. ~ MAC(K'_i, M) +-+-+-+-+-+-+-+-+
  1913. | | Padding |
  1914. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1915. ~ Group MAC (optional) ~
  1916. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1917.  
  1918. Figure 6: Format of the Authentication Tag
  1919. with a New Key Chain Commitment
  1920.  
  1921. 3.4.6. Format of an Authentication Tag with a "Last Key of Old Chain"
  1922. Disclosure
  1923.  
  1924. During the first n_tx_lastkey intervals of the new key chain after
  1925. the disclosing interval, d, the sender SHOULD disclose the last key
  1926. of the old key chain. This is done by replacing the disclosed key of
  1927. the Authentication Tag with the Last Key of the Old Chain, K_N (or
  1928. K_{2N+1} in case of a switch between the second and third key chains,
  1929. etc.). Figure 7 shows the corresponding format.
  1930.  
  1931. Note that since there is no padding between the "K_N" and "MAC(K'_i,
  1932. M)" fields, the latter MAY not start on a 32-bit boundary, depending
  1933. on the n_p parameter.
  1934.  
  1935.  
  1936.  
  1937.  
  1938.  
  1939.  
  1940.  
  1941.  
  1942.  
  1943.  
  1944.  
  1945.  
  1946.  
  1947.  
  1948.  
  1949.  
  1950.  
  1951. Roca, et al. Experimental [Page 35]
  1953. RFC 5776 TESLA in ALC and NORM April 2010
  1954.  
  1955.  
  1956. 0 1 2 3
  1957. 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
  1958. +-+-+-+-+-+-+-+-+
  1959. | Reserved |
  1960. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1961. | i (Interval Index of K'_i) |
  1962. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1963. | |
  1964. ~ Last Key of Old Chain, K_N ~
  1965. | |
  1966. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1967. | |
  1968. ~ MAC(K'_i, M) +-+-+-+-+-+-+-+-+
  1969. | | Padding |
  1970. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1971. ~ Group MAC (optional) ~
  1972. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1973.  
  1974. Figure 7: Format of the Authentication Tag
  1975. with an Old Chain Last Key Disclosure
  1976.  
  1977. 4. Receiver Operations
  1978.  
  1979. This section describes the TESLA operations at a receiver.
  1980.  
  1981. 4.1. Verification of the Authentication Information
  1982.  
  1983. This section details the computation steps required to verify each of
  1984. the three possible authentication information of an incoming packet.
  1985. The verification MUST follow a strict order:
  1986.  
  1987. o first of all, if the Group MAC is present and if the session uses
  1988. this feature (e.g., if the G bit is set in the bootstrap
  1989. information message), then verify the Group MAC. A packet that
  1990. does not contain a Group MAC tag, whereas the session uses this
  1991. feature, MUST be dropped immediately. On the opposite, if a
  1992. packet contains a Group MAC tag whereas the session does not use
  1993. this feature, this tag MUST be ignored;
  1994.  
  1995. o then, verify the digital signature (with TESLA signaling packets)
  1996. or enter the TESLA authentication process (with data packets).
  1997.  
  1998. 4.1.1. Processing the Group MAC Tag
  1999.  
  2000. Upon receiving a packet containing a Group MAC tag, the receiver
  2001. recomputes the Group MAC and compares it to the value carried in the
  2002. packet. If the check fails, the packet MUST be dropped immediately.
  2003.  
  2004.  
  2005.  
  2006.  
  2007. Roca, et al. Experimental [Page 36]
  2009. RFC 5776 TESLA in ALC and NORM April 2010
  2010.  
  2011.  
  2012. More specifically, recomputing the Group MAC requires saving the
  2013. value of the "Group MAC" field, setting this field to 0, and doing
  2014. the same computation as a sender does (see Section 3.3.3).
  2015.  
  2016. 4.1.2. Processing the Digital Signature
  2017.  
  2018. Upon receiving a packet containing a digital signature, the receiver
  2019. verifies the signature as follows.
  2020.  
  2021. The computation of the signature MUST include the ALC or NORM header
  2022. (with the various header extensions) and the payload when applicable.
  2023. The UDP/IP headers MUST NOT be included. During this computation,
  2024. the "Signature" field MUST be set to 0 as well as the optional Group
  2025. MAC, when present.
  2026.  
  2027. From [RFC4359]: Digital signature verification is performed as
  2028. described in [RFC3447], Section 8.2.2 (RSASSA-PKCS1-v1_5) and
  2029. [RFC3447], Section 8.1.2 (RSASSA-PSS). Upon receipt, the digital
  2030. signature is passed to the verification function as S. The
  2031. authenticated portion of the packet is used as the message M, and the
  2032. RSA public key is passed as (n, e). In summary (when SHA-256 is
  2033. used), the verification function computes a SHA-256 hash of the
  2034. authenticated packet bytes, decrypts the SHA-256 hash in the packet,
  2035. and validates that the appropriate encoding was applied. The two
  2036. SHA-256 hashes are compared, and if they are identical the validation
  2037. is successful.
  2038.  
  2039. It is assumed that the receivers have the possibility to retrieve the
  2040. sender's public key required to check this digital signature
  2041. (Section 2.2). This document does not specify how the public key of
  2042. the sender is communicated reliably and in a secure way to all
  2043. possible receivers.
  2044.  
  2045. 4.1.3. Processing the Authentication Tag
  2046.  
  2047. When a receiver wants to authenticate a packet using an
  2048. authentication tag and when he has the key for the associated time
  2049. interval (i.e., after the disclosing delay, d), the receiver
  2050. recomputes the MAC and compares it to the value carried in the
  2051. packet. If the check fails, the packet MUST be immediately dropped.
  2052.  
  2053. More specifically, recomputing the MAC requires saving the value of
  2054. the "MAC" field, setting this field to 0, and doing the same
  2055. computation as a sender does (see Section 3.3.1).
  2056.  
  2057.  
  2058.  
  2059.  
  2060.  
  2061.  
  2062.  
  2063. Roca, et al. Experimental [Page 37]
  2065. RFC 5776 TESLA in ALC and NORM April 2010
  2066.  
  2067.  
  2068. 4.2. Initialization of a Receiver
  2069.  
  2070. A receiver MUST be initialized before being able to authenticate the
  2071. source of incoming packets. This can be done by an out-of-band
  2072. mechanism or an in-band mechanism (Section 2.2). Let us focus on the
  2073. in-band mechanism. Two actions must be performed:
  2074.  
  2075. o receive and process a bootstrap information message, and
  2076.  
  2077. o calculate an upper bound of the sender's local time. To that
  2078. purpose, the receiver must perform time synchronization.
  2079.  
  2080. 4.2.1. Processing the Bootstrap Information Message
  2081.  
  2082. A receiver must first receive a packet containing the bootstrap
  2083. information, digitally signed by the sender. Once the bootstrap
  2084. information has been authenticated (see Section 4.1), the receiver
  2085. can initialize its TESLA component. The receiver MUST then ignore
  2086. the following bootstrap information messages, if any. There is an
  2087. exception though: when a new key chain is used and if a receiver
  2088. missed all the commitments for this new key chain, then this receiver
  2089. MUST process one of the future bootstrap information messages (if
  2090. any) in order to be able to authenticate the incoming packets
  2091. associated to this new key chain.
  2092.  
  2093. Before TESLA has been initialized, a receiver MUST discard incoming
  2094. packets other than the bootstrap information message and direct time
  2095. synchronization response.
  2096.  
  2097. 4.2.2. Performing Time Synchronization
  2098.  
  2099. First of all, the receiver must know whether the ALC or NORM session
  2100. relies on direct or indirect time synchronization. This information
  2101. is communicated by an out-of-band mechanism (for instance, when
  2102. describing the various parameters of an ALC or NORM session). In
  2103. some cases, both mechanisms might be available and the receiver can
  2104. choose the preferred technique.
  2105.  
  2106. 4.2.2.1. Direct Time Synchronization
  2107.  
  2108. In the case of a direct time synchronization, a receiver MUST
  2109. synchronize with the sender. To that purpose, the receiver sends a
  2110. direct time synchronization request message. This message includes
  2111. the local time (in NTP timestamp format) at the receiver when sending
  2112. the message. This timestamp will be copied in the sender's response
  2113. for the receiver to associate the response to the request.
  2114.  
  2115.  
  2116.  
  2117.  
  2118.  
  2119. Roca, et al. Experimental [Page 38]
  2121. RFC 5776 TESLA in ALC and NORM April 2010
  2122.  
  2123.  
  2124. The direct time synchronization request message format is the
  2125. following:
  2126.  
  2127. 0 1 2 3
  2128. 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
  2129. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2130. | |
  2131. + t_r (NTP timestamp) +
  2132. | |
  2133. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2134. ~ Group MAC (optional) ~
  2135. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2136.  
  2137. Figure 8: Format of a Direct Time Synchronization Request
  2138.  
  2139. The direct time synchronization request (Figure 8) contains the
  2140. following information:
  2141.  
  2142. "t_r" (NTP timestamp, 64 bits):
  2143.  
  2144. "t_r" is a timestamp in NTP timestamp format that contains the
  2145. receiver local time value when sending this direct time
  2146. synchronization request message;
  2147.  
  2148. "Group MAC" field (optional, variable length, multiple of 32 bits):
  2149.  
  2150. This field contains the Group MAC, calculated with the group key,
  2151. K_g, shared by all group members. The field length, in bits, is
  2152. given by n_w, which is known once the Group MAC function type is
  2153. known (Section 7).
  2154.  
  2155. The receiver then awaits a response message (Section 3.4.2). Upon
  2156. receiving this message, the receiver:
  2157.  
  2158. checks that this response relates to the request, by comparing the
  2159. "t_r" fields;
  2160.  
  2161. checks the Group MAC if present;
  2162.  
  2163. checks the signature;
  2164.  
  2165. retrieves the t_s value and calculates D_t (Section 2.4.1).
  2166.  
  2167. Note that in an ALC session, the direct time synchronization request
  2168. message is sent to the sender by an out-of-band mechanism that is not
  2169. specified by the current document.
  2170.  
  2171.  
  2172.  
  2173.  
  2174.  
  2175. Roca, et al. Experimental [Page 39]
  2177. RFC 5776 TESLA in ALC and NORM April 2010
  2178.  
  2179.  
  2180. 4.2.2.2. Indirect Time Synchronization
  2181.  
  2182. With the indirect time synchronization method, the sender MAY provide
  2183. out-of-band the URL or IP address of the NTP server(s) he trusts
  2184. along with an OPTIONAL certificate for each NTP server. When several
  2185. NTP servers are specified, a receiver MUST choose one of them. This
  2186. document does not specify how the choice is made, but for the sake of
  2187. scalability, the clients SHOULD NOT use the same server if several
  2188. possibilities are offered. The NTP synchronization between the NTP
  2189. server and the receiver MUST be authenticated, either using the
  2190. certificate provided by the server or another certificate the client
  2191. may obtain for this NTP server.
  2192.  
  2193. Then the receiver computes the time offset between itself and the NTP
  2194. server chosen. Note that the receiver does not need to update the
  2195. local time, (which often requires root privileges), computing the
  2196. time offset is sufficient.
  2197.  
  2198. Since the offset between the server and the time reference, D^O_t, is
  2199. indicated in the bootstrap information message (or communicated out-
  2200. of-band), the receiver can now calculate an upper bound of the
  2201. sender's local time (Section 2.4.2).
  2202.  
  2203. Note that this scenario assumes that each client trusts the sender
  2204. and accepts aligning its NTP configuration to that of the sender,
  2205. using one of the NTP server(s) suggested. If this assumption does
  2206. not hold, the client MUST NOT use the NTP indirect time
  2207. synchronization method (Section 2.3.2).
  2208.  
  2209. 4.3. Authentication of Received Packets
  2210.  
  2211. The receiver can now authenticate incoming packets (other than
  2212. bootstrap information and direct time synchronization response
  2213. packets). To that purpose, he MUST follow different steps (see
  2214. [RFC4082], Section 3.5):
  2215.  
  2216. 1. The receiver parses the different packet headers. If none of the
  2217. four TESLA authentication tags are present, the receiver MUST
  2218. discard the packet. If the session is in "Single Key Chain" mode
  2219. (e.g., when the "S" flag is set in the bootstrap information
  2220. message), then the receiver MUST discard any packet containing an
  2221. Authentication Tag with a New Key Chain Commitment or an
  2222. Authentication Tag with a Last Key of Old Chain Disclosure.
  2223.  
  2224. 2. Safe packet test: When the receiver receives packet P_j, it first
  2225. records the local time T at which the packet arrived. The
  2226. receiver then computes an upper bound t_j on the sender's clock
  2227. at the time when the packet arrived: t_j = T + D_t. The receiver
  2228.  
  2229.  
  2230.  
  2231. Roca, et al. Experimental [Page 40]
  2233. RFC 5776 TESLA in ALC and NORM April 2010
  2234.  
  2235.  
  2236. then computes the highest interval the sender could possibly be
  2237. in: highest_i = floor((t_j - T_0) / T_int). He also retrieves
  2238. the "i" interval index from the authentication tag. The receiver
  2239. can now proceed with the "safe packet" test. If highest_i < i +
  2240. d, then the sender is not yet in the interval during which it
  2241. discloses the key K_i. The packet is safe (but not necessarily
  2242. authentic). If the test fails, the packet is unsafe, and the
  2243. receiver MUST discard the packet.
  2244.  
  2245. 3. Group MAC test: if the optional Group MAC tag is present and if
  2246. the session uses this feature, then verify the Group MAC
  2247. (Section 4.1.1). If the verification fails, the packet MUST be
  2248. immediately dropped. A packet that does not contain a Group MAC
  2249. tag whereas the session uses this feature MUST be immediately
  2250. dropped. On the opposite, if a packet contains a Group MAC tag
  2251. whereas the session does not use this feature, this tag MUST be
  2252. ignored.
  2253.  
  2254. 4. Disclosed Key processing: When the packet discloses a key (i.e.,
  2255. with a Standard Authentication Tag, or with an Authentication Tag
  2256. with a Last Key of Old Chain Disclosure), the following tests are
  2257. performed:
  2258.  
  2259. * New key index test: the receiver checks whether a legitimate
  2260. key already exists with the same index (i.e., i-d). If such a
  2261. legitimate key exists, the receiver compares its value with
  2262. the current disclosed key and if they are identical, skips the
  2263. "Unverifiable key test" and "Key verification test". If such
  2264. a legitimate key exists but the values differ, the receiver
  2265. MUST discard the packet.
  2266.  
  2267. * Unverifiable key test: when the disclosed key index is new, it
  2268. is possible that no earlier disclosed and legitimate key
  2269. exists for this key chain, thereby preventing the verification
  2270. of the disclosed key. This happens when the disclosed key
  2271. belongs to the old key chain and no commitment to this old key
  2272. chain has ever been received (e.g., because the first
  2273. bootstrap packet received by a latecomer is for the current
  2274. key chain, and therefore includes a commitment to the current
  2275. key chain, not the previous one). When this happens, the
  2276. receiver MUST ignore the disclosed key (anyway useless) and
  2277. skip the Key verification test.
  2278.  
  2279. * Key verification test: If the disclosed key index is new and
  2280. the key can be verified, the receiver checks the legitimacy of
  2281. K_{i-d} by verifying, for some earlier disclosed and
  2282. legitimate key K_v (with v < i-d), that K_v and F^{i-d-
  2283. v}(K_{i-d}) are identical. In other words, the receiver
  2284.  
  2285.  
  2286.  
  2287. Roca, et al. Experimental [Page 41]
  2289. RFC 5776 TESLA in ALC and NORM April 2010
  2290.  
  2291.  
  2292. checks the disclosed key by computing the necessary number of
  2293. PRF functions to obtain a previously disclosed and legitimate
  2294. (i.e., verified) key. If the key verification fails, the
  2295. receiver MUST discard the packet. If the key verification
  2296. succeeds, this key is said to be legitimate and is stored by
  2297. the receiver, as well as all the keys between indexes v and
  2298. i-d.
  2299.  
  2300. 5. When applicable, the receiver performs any congestion control
  2301. related action (i.e., the ALC or NORM headers are used by the
  2302. associated congestion control building block, if any), even if
  2303. the packet has not yet been authenticated [RFC5651]. If this
  2304. feature leads to a potential DoS attack (the attacker can send a
  2305. faked packet with a wrong sequence number to simulate packet
  2306. losses), it does not compromise the security features offered by
  2307. TESLA and enables a rapid reaction in front of actual congestion
  2308. problems.
  2309.  
  2310. 6. The receiver then buffers the packet for a later authentication,
  2311. once the corresponding key will be disclosed (after d time
  2312. intervals) or deduced from another key (if all packets disclosing
  2313. this key are lost). In some situations, this packet might also
  2314. be discarded later, if it turns out that the receiver will never
  2315. be able to deduce the associated key.
  2316.  
  2317. 7. Authentication test: Let v be the smallest index of the
  2318. legitimate keys known by the receiver so far. For all the new
  2319. keys K_w, with v < w <= i-d, that have been either disclosed by
  2320. this packet (i.e., K_{i-d}) or derived by K_{i-d} (i.e., keys in
  2321. interval {v+1,.. i-d-1}), the receiver verifies the authenticity
  2322. of the safe packets buffered for the corresponding interval w.
  2323. To authenticate one of the buffered packets P_h containing
  2324. message M_h protected with a MAC that used key index w, the
  2325. receiver will compute K'_w = F'(K_w) from which it can compute
  2326. MAC( K'_w, M_h). If this MAC does not equal the MAC stored in
  2327. the packet, the receiver MUST discard the packet. If the two
  2328. MACs are equal, the packet is successfully authenticated and the
  2329. receiver continues processing it.
  2330.  
  2331. 8. Authenticated new key chain commitment processing: If the
  2332. authenticated packet contains a new key chain commitment and if
  2333. no verified commitment already exists, then the receiver stores
  2334. the commitment to the new key chain. Then, if there are non-
  2335. authenticated packets for a previous chain (i.e., the key chain
  2336. before the current one), all these packets can be discarded
  2337. (Section 4.4).
  2338.  
  2339.  
  2340.  
  2341.  
  2342.  
  2343. Roca, et al. Experimental [Page 42]
  2345. RFC 5776 TESLA in ALC and NORM April 2010
  2346.  
  2347.  
  2348. 9. The receiver continues the ALC or NORM processing of all the
  2349. packets authenticated during the authentication test.
  2350.  
  2351. In this specification, a receiver using TESLA MUST immediately drop
  2352. unsafe packets. But the receiver MAY also decide, at any time, to
  2353. continue an ALC or NORM session in unsafe (insecure) mode, ignoring
  2354. TESLA extensions. There SHOULD be an explicit user action to that
  2355. purpose.
  2356.  
  2357. 4.3.1. Discarding Unnecessary Packets Earlier
  2358.  
  2359. Following strictly the above steps can lead to excessive processing
  2360. overhead in certain situations. This is the case when a receiver
  2361. receives packets for an unwanted object with the ALC or NORM
  2362. protocols, i.e., an object in which the application (or the end user)
  2363. explicitly mentioned it is not interested. This is also the case
  2364. when a receiver receives packets for an already decoded object, or
  2365. when this object has been partitioned in several blocks, for an
  2366. already decoded block. When such a packet is received, which is
  2367. easily identified by looking at the receiver's status for the
  2368. incoming ALC or NORM packet, the receiver MUST also check that the
  2369. packet is a pure data packet that does not contain any signaling
  2370. information of importance for the session.
  2371.  
  2372. With ALC, a packet containing an "A" flag ("Close Session") or a "B"
  2373. flag ("Close Object") MUST NOT be discarded before having been
  2374. authenticated and processed normally. Otherwise, the receiver can
  2375. safely discard the incoming packet for instance just after step 1 of
  2376. Section 4.3. This optimization can dramatically reduce the
  2377. processing overhead by avoiding many useless authentication checks.
  2378.  
  2379. 4.4. Flushing the Non-Authenticated Packets of a Previous Key Chain
  2380.  
  2381. In some cases, a receiver having experienced a very long
  2382. disconnection might have lost all the disclosures of the last key(s)
  2383. of a previous key chain. Let j be the index of this key chain for
  2384. which there remains non-authenticated packets. This receiver can
  2385. flush all the packets of the key chain j if he determines that:
  2386.  
  2387. o he has just switched to a chain of index j+2 (inclusive) or
  2388. higher;
  2389.  
  2390. o the sender has sent a commitment to the new key chain of index j+2
  2391. (Section 3.1.2.3). This situation requires that the receiver has
  2392. received a packet containing such a commitment and that he has
  2393. been able to check its integrity. In some cases, it might require
  2394. receiving a bootstrap information message for the current key
  2395. chain.
  2396.  
  2397.  
  2398.  
  2399. Roca, et al. Experimental [Page 43]
  2401. RFC 5776 TESLA in ALC and NORM April 2010
  2402.  
  2403.  
  2404. If one of the above two tests succeeds, the sender can discard all
  2405. the awaiting packets since there is no way to authenticate them.
  2406.  
  2407. 5. Integration in the ALC and NORM Protocols
  2408.  
  2409. 5.1. Authentication Header Extension Format
  2410.  
  2411. The integration of TESLA in ALC or NORM is similar and relies on the
  2412. header extension mechanism defined in both protocols. More
  2413. precisely, this document details the EXT_AUTH==1 header extension
  2414. defined in [RFC5651].
  2415.  
  2416. Several fields are added in addition to the "HET" (Header Extension
  2417. Type) and "HEL" (Header Extension Length) fields (Figure 9).
  2418.  
  2419. 0 1 2 3
  2420. 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
  2421. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2422. | HET (=1) | HEL | ASID | Type | |
  2423. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
  2424. | |
  2425. ~ ~
  2426. | Content |
  2427. ~ ~
  2428. | |
  2429. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2430.  
  2431. Figure 9: Format of the TESLA EXT_AUTH Header Extension
  2432.  
  2433. The fields of the TESLA EXT_AUTH Header Extension are:
  2434.  
  2435. "ASID" (Authentication Scheme IDentifier) field (4 bits):
  2436.  
  2437. The "ASID" identifies the source authentication scheme or protocol
  2438. in use. The association between the "ASID" value and the actual
  2439. authentication scheme is defined out-of-band, at session startup.
  2440.  
  2441. "Type" field (4 bits):
  2442.  
  2443. The "Type" field identifies the type of TESLA information carried
  2444. in this header extension. This specification defines the
  2445. following types:
  2446.  
  2447. * 0: Bootstrap information, sent by the sender periodically or
  2448. after a direct time synchronization request;
  2449.  
  2450. * 1: Standard Authentication Tag for the ongoing key chain, sent
  2451. by the sender along with a packet;
  2452.  
  2453.  
  2454.  
  2455. Roca, et al. Experimental [Page 44]
  2457. RFC 5776 TESLA in ALC and NORM April 2010
  2458.  
  2459.  
  2460. * 2: Authentication Tag without Key Disclosure, sent by the
  2461. sender along with a packet;
  2462.  
  2463. * 3: Authentication Tag with a New Key Chain Commitment, sent by
  2464. the sender when approaching the end of a key chain;
  2465.  
  2466. * 4: Authentication Tag with a Last Key of Old Chain Disclosure,
  2467. sent by the sender some time after moving to a new key chain;
  2468.  
  2469. * 5: Direct time synchronization request, sent by a NORM
  2470. receiver. This type of message is invalid in the case of an
  2471. ALC session since ALC is restricted to unidirectional
  2472. transmissions. Yet, an external mechanism may provide the
  2473. direct time synchronization functionality;
  2474.  
  2475. * 6: Direct time synchronization response, sent by a NORM sender.
  2476. This type of message is invalid in the case of an ALC session
  2477. since ALC is restricted to unidirectional transmissions. Yet,
  2478. an external mechanism may provide the direct time
  2479. synchronization functionality.
  2480.  
  2481. "Content" field (variable length):
  2482.  
  2483. This is the TESLA information carried in the header extension,
  2484. whose type is given by the "Type" field.
  2485.  
  2486. 5.2. Use of Authentication Header Extensions
  2487.  
  2488. Each packet sent by the session's sender MUST contain exactly one
  2489. TESLA EXT_AUTH Header Extension.
  2490.  
  2491. All receivers MUST recognize EXT_AUTH but MAY not be able to parse
  2492. its content, for instance, because they do not support TESLA. In
  2493. that case, these receivers MUST ignore the TESLA EXT_AUTH extensions.
  2494. In the case of NORM, the packets sent by receivers MAY contain a
  2495. direct synchronization request but MUST NOT contain any of the other
  2496. five TESLA EXT_AUTH Header Extensions.
  2497.  
  2498. 5.2.1. EXT_AUTH Header Extension of Type Bootstrap Information
  2499.  
  2500. The "bootstrap information" TESLA EXT_AUTH (Type==0) MUST be sent in
  2501. a stand-alone control packet, rather than in a packet containing
  2502. application data. The reason for that is the large size of this
  2503. bootstrap information. By using stand-alone packets, the maximum
  2504. payload size of data packets is only affected by the (mandatory)
  2505. authentication information header extension.
  2506.  
  2507.  
  2508.  
  2509.  
  2510.  
  2511. Roca, et al. Experimental [Page 45]
  2513. RFC 5776 TESLA in ALC and NORM April 2010
  2514.  
  2515.  
  2516. With ALC, the "bootstrap information" TESLA EXT_AUTH MUST be sent in
  2517. a control packet, i.e., containing no encoding symbol.
  2518.  
  2519. With NORM, the "bootstrap information" TESLA EXT_AUTH MUST be sent in
  2520. a NORM_CMD(APPLICATION) message.
  2521.  
  2522.  
  2523.  
  2524.  
  2525.  
  2526.  
  2527.  
  2528.  
  2529.  
  2530.  
  2531.  
  2532.  
  2533.  
  2534.  
  2535.  
  2536.  
  2537.  
  2538.  
  2539.  
  2540.  
  2541.  
  2542.  
  2543.  
  2544.  
  2545.  
  2546.  
  2547.  
  2548.  
  2549.  
  2550.  
  2551.  
  2552.  
  2553.  
  2554.  
  2555.  
  2556.  
  2557.  
  2558.  
  2559.  
  2560.  
  2561.  
  2562.  
  2563.  
  2564.  
  2565.  
  2566.  
  2567. Roca, et al. Experimental [Page 46]
  2569. RFC 5776 TESLA in ALC and NORM April 2010
  2570.  
  2571.  
  2572. 0 1 2 3
  2573. 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
  2574. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
  2575. | HET (=1) | HEL (=46) | ASID | 0 | 0 | 0 |0|1|0| ^
  2576. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
  2577. | d | 2 | 2 | 2 | |
  2578. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
  2579. | 1 | 3 | 128 | |
  2580. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
  2581. | 0 (reserved) | T_int | |
  2582. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
  2583. | | |
  2584. + T_0 (NTP timestamp format) + | 5
  2585. | | | 2
  2586. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
  2587. | N (Key Chain Length) | | b
  2588. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | y
  2589. | Current Interval Index i | | t
  2590. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | e
  2591. | | | s
  2592. + + |
  2593. | | |
  2594. + Current Key Chain Commitment + |
  2595. | (20 bytes) | |
  2596. + + |
  2597. | | |
  2598. + + |
  2599. | | v
  2600. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
  2601. | | ^ 1
  2602. + + | 2
  2603. | | | 8
  2604. . . |
  2605. . Signature . | b
  2606. . (128 bytes) . | y
  2607. | | | t
  2608. + + | e
  2609. | | v s
  2610. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
  2611. | Group MAC |
  2612. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2613.  
  2614. Figure 10: Example: Format of the Bootstrap Information Message
  2615. (Type 0) Using SHA-256/1024-Bit Signatures,
  2616. the Default HMAC-SHA-256, and a Group MAC
  2617.  
  2618.  
  2619.  
  2620.  
  2621.  
  2622.  
  2623. Roca, et al. Experimental [Page 47]
  2625. RFC 5776 TESLA in ALC and NORM April 2010
  2626.  
  2627.  
  2628. For instance, Figure 10 shows the bootstrap information message when
  2629. using the HMAC-SHA-256 transform for the PRF, MAC, and Group MAC
  2630. functions, along with SHA-256/128 byte (1024 bit) key digital
  2631. signatures (which also means that the "Signature" field is 128 bytes
  2632. long). The TESLA EXT_AUTH Header Extension is then 184 bytes long
  2633. (i.e., 46 words of 32 bits).
  2634.  
  2635. 5.2.2. EXT_AUTH Header Extension of Type Authentication Tag
  2636.  
  2637. The four "authentication tag" TESLA EXT_AUTH Header Extensions (Type
  2638. 1, 2, 3, and 4) MUST be attached to the ALC or NORM packet (data or
  2639. control packet) that they protect.
  2640.  
  2641. 0 1 2 3
  2642. 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
  2643. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2644. | HET (=1) | HEL (=10) | ASID | 1 | Reserved |
  2645. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2646. | i (Interval Index of K'_i) |
  2647. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2648. | |
  2649. + +
  2650. | |
  2651. + Disclosed Key K_{i-d} +
  2652. | (20 bytes) |
  2653. + +
  2654. | |
  2655. + +
  2656. | |
  2657. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2658. | |
  2659. + +
  2660. | MAC(K'_i, M) |
  2661. + (16 bytes) +
  2662. | |
  2663. + +
  2664. | |
  2665. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2666.  
  2667. Figure 11: Example: Format of the Standard Authentication Tag
  2668. (Type 1) Using the Default HMAC-SHA-256
  2669.  
  2670.  
  2671.  
  2672.  
  2673.  
  2674.  
  2675.  
  2676.  
  2677.  
  2678.  
  2679. Roca, et al. Experimental [Page 48]
  2681. RFC 5776 TESLA in ALC and NORM April 2010
  2682.  
  2683.  
  2684. 0 1 2 3
  2685. 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
  2686. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2687. | HET (=1) | HEL (=5) | ASID | 2 | Reserved |
  2688. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2689. | i (Interval Index of K'_i) |
  2690. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2691. | |
  2692. + +
  2693. | MAC(K'_i, M) |
  2694. + (16 bytes) +
  2695. | |
  2696. + +
  2697. | |
  2698. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2699.  
  2700. Figure 12: Example: Format of the Authentication Tag without
  2701. Key Disclosure (Type 2) Using the Default HMAC-SHA-256
  2702.  
  2703. For instance, Figures 11 and 12 show the format of the authentication
  2704. tags, respectively with and without the K_{i-d} key disclosure, when
  2705. using the (default) HMAC-SHA-256 transform for the PRF and MAC
  2706. functions. In these examples, the Group MAC feature is not used.
  2707.  
  2708. 5.2.3. EXT_AUTH Header Extension of Type Direct Time Synchronization
  2709. Request
  2710.  
  2711. With NORM, the "direct time synchronization request" TESLA EXT_AUTH
  2712. (Type==7) MUST be sent by a receiver in a NORM_CMD(APPLICATION) NORM
  2713. packet.
  2714.  
  2715. With ALC, the "direct time synchronization request" TESLA EXT_AUTH
  2716. cannot be included in an ALC packet, since ALC is restricted to
  2717. unidirectional transmissions, from the session's sender to the
  2718. receivers. An external mechanism must be used with ALC for carrying
  2719. direct time synchronization requests to the session's sender.
  2720.  
  2721. In the case of direct time synchronization, it is RECOMMENDED that
  2722. the receivers spread the transmission of direct time synchronization
  2723. requests over the time (Section 2.3.1).
  2724.  
  2725. 5.2.4. EXT_AUTH Header Extension of Type Direct Time Synchronization
  2726. Response
  2727.  
  2728. With NORM, the "direct time synchronization response" TESLA EXT_AUTH
  2729. (Type==8) MUST be sent by the sender in a NORM_CMD(APPLICATION)
  2730. message.
  2731.  
  2732.  
  2733.  
  2734.  
  2735. Roca, et al. Experimental [Page 49]
  2737. RFC 5776 TESLA in ALC and NORM April 2010
  2738.  
  2739.  
  2740. With ALC, the "direct time synchronization response" TESLA EXT_AUTH
  2741. can be sent in an ALC control packet (i.e., containing no encoding
  2742. symbol) or through the external mechanism used to carry the direct
  2743. time synchronization request.
  2744.  
  2745. 6. Security Considerations
  2746.  
  2747. [RFC4082] discusses the security of TESLA in general. These
  2748. considerations apply to the present specification, namely:
  2749.  
  2750. o great care must be taken in the timing aspects. In particular,
  2751. the D_t parameter is critical and must be correctly initialized;
  2752.  
  2753. o if the sender realizes that the key disclosure schedule is not
  2754. appropriate, then the current session MUST be closed and a new one
  2755. created. Indeed, Section 3.1.3 requires that these parameters be
  2756. fixed during the whole session.
  2757.  
  2758. o when the verifier that authenticates the incoming packets and the
  2759. application that uses the data are two different components, there
  2760. is a risk that an attacker located between these components inject
  2761. faked data. Similarly, when the verifier and the secure timing
  2762. system are two different components, there is a risk that an
  2763. attacker located between these components inject faked timing
  2764. information. For instance, when the verifier reads the local time
  2765. by means of a dedicated system call (e.g., gettimeofday()), if an
  2766. attacker controls the host, he may catch the system call and
  2767. return a faked time information.
  2768.  
  2769. The current specification discusses additional aspects with more
  2770. details.
  2771.  
  2772. 6.1. Dealing with DoS Attacks
  2773.  
  2774. TESLA introduces new opportunities for an attacker to mount DoS
  2775. attacks. For instance, an attacker can try to saturate the
  2776. processing capabilities of the receiver (faked packets are easy to
  2777. create but checking them requires computing a MAC over the packet or
  2778. sometimes checking a digital signature as with the bootstrap and
  2779. direct time synchronization response messages). An attacker can also
  2780. try to saturate the receiver's memory (since authentication is
  2781. delayed and non-authenticated packets will accumulate), or to make
  2782. the receiver believe that a congestion has happened (since congestion
  2783. control MUST be performed before authenticating incoming packets,
  2784. Section 4.3).
  2785.  
  2786.  
  2787.  
  2788.  
  2789.  
  2790.  
  2791. Roca, et al. Experimental [Page 50]
  2793. RFC 5776 TESLA in ALC and NORM April 2010
  2794.  
  2795.  
  2796. In order to mitigate these attacks, it is RECOMMENDED to use the
  2797. Group MAC scheme (Section 3.3.3). No mitigation is possible if a
  2798. group member acts as an attacker with Group MAC.
  2799.  
  2800. Generally, it is RECOMMENDED that the amount of memory used to store
  2801. incoming packets waiting to be authenticated be limited to a
  2802. reasonable value.
  2803.  
  2804. 6.2. Dealing With Replay Attacks
  2805.  
  2806. Replay attacks, whereby an attacker stores a valid message and
  2807. replays it later, can have significant impacts, depending on the
  2808. message type. Two levels of impacts must be distinguished:
  2809.  
  2810. o within the TESLA protocol, and
  2811.  
  2812. o within the ALC or NORM protocol.
  2813.  
  2814. 6.2.1. Impacts of Replay Attacks on TESLA
  2815.  
  2816. Replay attacks can impact the TESLA component itself. We review here
  2817. the potential impacts of such an attack depending on the TESLA
  2818. message type:
  2819.  
  2820. o bootstrap information: Since most parameters contained in a
  2821. bootstrap information message are static, replay attacks have no
  2822. consequences. The fact that the "i" and "K_i" fields can be
  2823. updated in subsequent bootstrap information messages does not
  2824. create a problem either, since all "i" and "K_i" fields sent
  2825. remain valid. Finally, a receiver that successfully initialized
  2826. its TESLA component MUST ignore the following messages (see
  2827. Section 4.2.1 for an exception to this rule), which voids replay
  2828. attacks, unless he missed all the commitments to a new key chain
  2829. (e.g., after a long disconnection) (Section 3.2.1).
  2830.  
  2831. o direct time synchronization request: If the Group MAC scheme is
  2832. used, an attacker that is not a member of the group can replay a
  2833. packet and oblige the sender to respond, which requires digitally
  2834. signing the response, a time-consuming process. If the Group MAC
  2835. scheme is not used, an attacker can easily forge a request anyway.
  2836. In both cases, the attack will not compromise the TESLA component,
  2837. but might create a DoS. If this is a concern, it is RECOMMENDED,
  2838. when the Group MAC scheme is used, that the sender verify the
  2839. "t_r" NTP timestamp contained in the request and respond only if
  2840. this value is strictly larger than the previous one received from
  2841. this receiver. When the Group MAC scheme is not used, this attack
  2842. can be mitigated by limiting the number of requests per second
  2843. that will be processed.
  2844.  
  2845.  
  2846.  
  2847. Roca, et al. Experimental [Page 51]
  2849. RFC 5776 TESLA in ALC and NORM April 2010
  2850.  
  2851.  
  2852. o direct time synchronization response: Upon receiving a response, a
  2853. receiver who has no pending request MUST immediately drop the
  2854. packet. If this receiver has previously issued a request, he
  2855. first checks the Group MAC (if applicable), then the "t_r" field,
  2856. to be sure it is a response to his request, and finally the
  2857. digital signature. A replayed packet will be dropped during these
  2858. verifications, without compromising the TESLA component.
  2859.  
  2860. o other messages, containing an authentication tag: Replaying a
  2861. packet containing a TESLA authentication tag will never compromise
  2862. the TESLA component itself (but perhaps the underlying ALC or NORM
  2863. component, see below).
  2864.  
  2865. To conclude, TESLA itself is robust in front of replay attacks.
  2866.  
  2867. 6.2.2. Impacts of Replay Attacks on NORM
  2868.  
  2869. We review here the potential impacts of a replay attack on the NORM
  2870. component. Note that we do not consider here the protocols that
  2871. could be used along with NORM, for instance, the congestion control
  2872. protocols.
  2873.  
  2874. First, let us consider replay attacks within a given NORM session.
  2875. NORM defines a "sequence" field that can be used to protect against
  2876. replay attacks [RFC5740] within a given NORM session. This
  2877. "sequence" field is a 16-bit value that is set by the message
  2878. originator (sender or receiver) as a monotonically increasing number
  2879. incremented with each NORM message transmitted. It is RECOMMENDED
  2880. that a receiver check this "sequence" field and drop messages
  2881. considered as replayed. Similarly, it is RECOMMENDED that a sender
  2882. check this sequence, for each known receiver, and drop messages
  2883. considered as replayed. In both cases, checking this "sequence"
  2884. field SHOULD be done before TESLA processing of the packet: if the
  2885. "sequence" field has not been corrupted, the replay attack will
  2886. immediately be identified; otherwise, the packet will fail the TESLA
  2887. authentication test. This analysis shows that NORM itself is robust
  2888. in front of replay attacks within the same session.
  2889.  
  2890. Now let us consider replay attacks across several NORM sessions.
  2891. Since the key chain used in each session MUST differ, a packet
  2892. replayed in a subsequent session will be identified as unauthentic.
  2893. Therefore, NORM is robust in front of replay attacks across different
  2894. sessions.
  2895.  
  2896.  
  2897.  
  2898.  
  2899.  
  2900.  
  2901.  
  2902.  
  2903. Roca, et al. Experimental [Page 52]
  2905. RFC 5776 TESLA in ALC and NORM April 2010
  2906.  
  2907.  
  2908. 6.2.3. Impacts of Replay Attacks on ALC
  2909.  
  2910. We review here the potential impacts of a replay attack on the ALC
  2911. component. Note that we do not consider here the protocols that
  2912. could be used along with ALC, for instance, the layered or wave-based
  2913. congestion control protocols.
  2914.  
  2915. First, let us consider replay attacks within a given ALC session:
  2916.  
  2917. o Regular packets containing an authentication tag: a replayed
  2918. message containing an encoding symbol will be detected once
  2919. authenticated, thanks to the object/block/symbol identifiers, and
  2920. will be silently discarded. This kind of replay attack is only
  2921. penalizing in terms of memory and processing load, but does not
  2922. compromise the ALC behavior.
  2923.  
  2924. o Control packets containing an authentication tag: ALC control
  2925. packets, by definition, do not include any encoding symbol and
  2926. therefore do not include any object/block/symbol identifier that
  2927. would enable a receiver to identify duplicates. However, a sender
  2928. has a very limited number of reasons to send control packets.
  2929. More precisely:
  2930.  
  2931. * At the end of the session, a "Close Session" ("A" flag) packet
  2932. is sent. Replaying this packet has no impact since the
  2933. receivers already left.
  2934.  
  2935. * Similarly, replaying a packet containing a "Close Object" ("B"
  2936. flag) has no impact since this object is probably already
  2937. marked as closed by the receiver.
  2938.  
  2939. This analysis shows that ALC itself is robust in front of replay
  2940. attacks within the same session.
  2941.  
  2942. Now let us consider replay attacks across several ALC sessions.
  2943. Since the key chain used in each session MUST differ, a packet
  2944. replayed in a subsequent session will be identified as unauthentic.
  2945. Therefore, ALC is robust in front of replay attacks across different
  2946. sessions.
  2947.  
  2948. 6.3. Security of the Back Channel
  2949.  
  2950. As specified in Section 1.1, this specification does not consider the
  2951. packets that may be sent by receivers, for instance, NORM's feedback
  2952. packets. When a back channel is used, its security is critical to
  2953. the global security, and an appropriate security mechanism MUST be
  2954. used. [RMT-SIMPLE-AUTH] describes several techniques that can be
  2955. used to that purpose. However, the authentication and integrity
  2956.  
  2957.  
  2958.  
  2959. Roca, et al. Experimental [Page 53]
  2961. RFC 5776 TESLA in ALC and NORM April 2010
  2962.  
  2963.  
  2964. verification of the packets sent by receivers on the back channel, if
  2965. any, is out of the scope of this document.
  2966.  
  2967. 7. IANA Considerations
  2968.  
  2969. IANA has registered the following attributes according to this
  2970. document. The registries are provided by [RFC4442] under the "Timed
  2971. Efficient Stream Loss-tolerant Authentication (TESLA) Parameters"
  2972. registry [TESLA-REG]. Following the policies outlined in [RFC4442],
  2973. the values in the range up to 240 (including 240) for the following
  2974. attributes are assigned after expert review by the MSEC working group
  2975. or its designated successor. The values in the range from 241 to 255
  2976. are reserved for private use.
  2977.  
  2978. Cryptographic Pseudo-Random Function, TESLA-PRF: All implementations
  2979. MUST support HMAC-SHA-256 (default).
  2980.  
  2981. +------------------------+-------+
  2982. | PRF name | Value |
  2983. +------------------------+-------+
  2984. | HMAC-SHA1 | 0 |
  2985. | HMAC-SHA-224 | 1 |
  2986. | HMAC-SHA-256 (default) | 2 |
  2987. | HMAC-SHA-384 | 3 |
  2988. | HMAC-SHA-512 | 4 |
  2989. +------------------------+-------+
  2990.  
  2991. Cryptographic Message Authentication Code (MAC) Function, TESLA-MAC:
  2992. All implementations MUST support HMAC-SHA-256 (default). These MAC
  2993. schemes are used both for the computing of regular MAC and the Group
  2994. MAC (if applicable).
  2995.  
  2996. +------------------------+-------+
  2997. | MAC name | Value |
  2998. +------------------------+-------+
  2999. | HMAC-SHA1 | 0 |
  3000. | HMAC-SHA-224 | 1 |
  3001. | HMAC-SHA-256 (default) | 2 |
  3002. | HMAC-SHA-384 | 3 |
  3003. | HMAC-SHA-512 | 4 |
  3004. +------------------------+-------+
  3005.  
  3006. Furthermore, IANA has created two new registries. Here also, the
  3007. values in the range up to 240 (including 240) for the following
  3008. attributes are assigned after expert review by the MSEC working group
  3009. or its designated successor. The values in the range from 241 to 255
  3010. are reserved for private use.
  3011.  
  3012.  
  3013.  
  3014.  
  3015. Roca, et al. Experimental [Page 54]
  3017. RFC 5776 TESLA in ALC and NORM April 2010
  3018.  
  3019.  
  3020. Signature Encoding Algorithm, TESLA-SIG-ALGO: All implementations
  3021. MUST support RSASSA-PKCS1-v1_5 (default).
  3022.  
  3023. +-----------------------------+-------+
  3024. | Signature Algorithm Name | Value |
  3025. +-----------------------------+-------+
  3026. | INVALID | 0 |
  3027. | RSASSA-PKCS1-v1_5 (default) | 1 |
  3028. | RSASSA-PSS | 2 |
  3029. +-----------------------------+-------+
  3030.  
  3031. Signature Cryptographic Function, TESLA-SIG-CRYPTO-FUNC: All
  3032. implementations MUST support SHA-256 (default).
  3033.  
  3034. +-----------------------------+-------+
  3035. | Cryptographic Function Name | Value |
  3036. +-----------------------------+-------+
  3037. | INVALID | 0 |
  3038. | SHA-1 | 1 |
  3039. | SHA-224 | 2 |
  3040. | SHA-256 (default) | 3 |
  3041. | SHA-384 | 4 |
  3042. | SHA-512 | 5 |
  3043. +-----------------------------+-------+
  3044.  
  3045. 8. Acknowledgments
  3046.  
  3047. The authors are grateful to Yaron Sheffer, Brian Weis, Ramu
  3048. Panayappan, Ran Canetti, David L. Mills, Brian Adamson, and Lionel
  3049. Giraud for their valuable comments while preparing this document.
  3050. The authors are also grateful to Brian Weis for the digital signature
  3051. details.
  3052.  
  3053. 9. References
  3054.  
  3055. 9.1. Normative References
  3056.  
  3057. [RFC1305] Mills, D., "Network Time Protocol (Version 3)
  3058. Specification, Implementation", RFC 1305,
  3059. March 1992.
  3060.  
  3061. [RFC2119] Bradner, S., "Key words for use in RFCs to
  3062. Indicate Requirement Levels", BCP 14, RFC 2119,
  3063. March 1997.
  3064.  
  3065.  
  3066.  
  3067.  
  3068.  
  3069.  
  3070.  
  3071. Roca, et al. Experimental [Page 55]
  3073. RFC 5776 TESLA in ALC and NORM April 2010
  3074.  
  3075.  
  3076. [RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and
  3077. B. Briscoe, "Timed Efficient Stream Loss-Tolerant
  3078. Authentication (TESLA): Multicast Source
  3079. Authentication Transform Introduction", RFC 4082,
  3080. June 2005.
  3081.  
  3082. [RFC5651] Luby, M., Watson, M., and L. Vicisano, "Layered
  3083. Coding Transport (LCT) Building Block", RFC 5651,
  3084. October 2009.
  3085.  
  3086. [RFC5740] Adamson, B., Bormann, C., Handley, M., and J.
  3087. Macker, "NACK-Oriented Reliable Multicast (NORM)
  3088. Transport Protocol", RFC 5740, November 2009.
  3089.  
  3090. [RFC5775] Luby, M., Watson, M., and L. Vicisano,
  3091. "Asynchronous Layered Coding (ALC) Protocol
  3092. Instantiation", RFC 5775, April 2010.
  3093.  
  3094. [TESLA-REG] "TESLA Parameters IANA Registry",
  3095. http://www.iana.org.
  3096.  
  3097. 9.2. Informative References
  3098.  
  3099. [NTP-NTPv4] Burbank, J., Kasch, W., Martin, J., Ed., and D.
  3100. Mills, "The Network Time Protocol Version 4
  3101. Protocol And Algorithm Specification", Work
  3102. in Progress, October 2009.
  3103.  
  3104. [Perrig04] Perrig, A. and J. Tygar, "Secure Broadcast
  3105. Communication in Wired and Wireless Networks",
  3106. Kluwer Academic Publishers ISBN 0-7923-7650-1,
  3107. 2004.
  3108.  
  3109. [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:
  3110. Keyed-Hashing for Message Authentication",
  3111. RFC 2104, February 1997.
  3112.  
  3113. [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key
  3114. Cryptography Standards (PKCS) #1: RSA Cryptography
  3115. Specifications Version 2.1", RFC 3447,
  3116. February 2003.
  3117.  
  3118. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E.,
  3119. and K. Norrman, "The Secure Real-time Transport
  3120. Protocol (SRTP)", RFC 3711, March 2004.
  3121.  
  3122.  
  3123.  
  3124.  
  3125.  
  3126.  
  3127. Roca, et al. Experimental [Page 56]
  3129. RFC 5776 TESLA in ALC and NORM April 2010
  3130.  
  3131.  
  3132. [RFC4330] Mills, D., "Simple Network Time Protocol (SNTP)
  3133. Version 4 for IPv4, IPv6 and OSI", RFC 4330,
  3134. January 2006.
  3135.  
  3136. [RFC4359] Weis, B., "The Use of RSA/SHA-1 Signatures within
  3137. Encapsulating Security Payload (ESP) and
  3138. Authentication Header (AH)", RFC 4359,
  3139. January 2006.
  3140.  
  3141. [RFC4383] Baugher, M. and E. Carrara, "The Use of Timed
  3142. Efficient Stream Loss-Tolerant Authentication
  3143. (TESLA) in the Secure Real-time Transport Protocol
  3144. (SRTP)", RFC 4383, February 2006.
  3145.  
  3146. [RFC4442] Fries, S. and H. Tschofenig, "Bootstrapping Timed
  3147. Efficient Stream Loss-Tolerant Authentication
  3148. (TESLA)", RFC 4442, March 2006.
  3149.  
  3150. [RMT-FLUTE] Paila, T., Walsh, R., Luby, M., Lehtonen, R., and
  3151. V. Roca, "FLUTE - File Delivery over
  3152. Unidirectional Transport", Work in Progress,
  3153. August 2009.
  3154.  
  3155. [RMT-SIMPLE-AUTH] Roca, V., "Simple Authentication Schemes for the
  3156. ALC and NORM Protocols", Work in Progress,
  3157. October 2009.
  3158.  
  3159.  
  3160.  
  3161.  
  3162.  
  3163.  
  3164.  
  3165.  
  3166.  
  3167.  
  3168.  
  3169.  
  3170.  
  3171.  
  3172.  
  3173.  
  3174.  
  3175.  
  3176.  
  3177.  
  3178.  
  3179.  
  3180.  
  3181.  
  3182.  
  3183. Roca, et al. Experimental [Page 57]
  3185. RFC 5776 TESLA in ALC and NORM April 2010
  3186.  
  3187.  
  3188. Authors' Addresses
  3189.  
  3190. Vincent Roca
  3191. INRIA
  3192. 655, av. de l'Europe
  3193. Inovallee; Montbonnot
  3194. ST ISMIER cedex 38334
  3195. France
  3196.  
  3197. EMail: [email protected]
  3198. URI: http://planete.inrialpes.fr/~roca/
  3199.  
  3200.  
  3201. Aurelien Francillon
  3202. INRIA
  3203. 655, av. de l'Europe
  3204. Inovallee; Montbonnot
  3205. ST ISMIER cedex 38334
  3206. France
  3207.  
  3208. EMail: [email protected]
  3209. URI: http://planete.inrialpes.fr/~francill/
  3210.  
  3211.  
  3212. Sebastien Faurite
  3213. INRIA
  3214. 655, av. de l'Europe
  3215. Inovallee; Montbonnot
  3216. ST ISMIER cedex 38334
  3217. France
  3218.  
  3219. EMail: [email protected]
  3220.  
  3221.  
  3222.  
  3223.  
  3224.  
  3225.  
  3226.  
  3227.  
  3228.  
  3229.  
  3230.  
  3231.  
  3232.  
  3233.  
  3234.  
  3235.  
  3236.  
  3237.  
  3238.  
  3239. Roca, et al. Experimental [Page 58]
Advertisement
Add Comment
Please, Sign In to add comment
Public Pastes
We use cookies for various purposes including analytics. By continuing to use Pastebin, you agree to our use of cookies as described in the Cookies Policy.  OK, I Understand
Not a member of Pastebin yet?
Sign Up, it unlocks many cool features!