RFC 5776
Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols
(part 1 of 13, more coming bestie 🎀)
Title Block 📜
Internet Engineering Task Force (IETF), Request for Comments: 5776, ISSN: 2070-1721, April 2010 🌸
The authors are V. Roca, A. Francillon and S. Faurite, all from INRIA 💜 This one is an Experimental document, so it's published for trying things out and evaluating, not as a standards-track spec ✨ It doesn't list anything it obsoletes or updates, so it's standing on its own 💅
The title is Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols 🦋
Abstract
okay so this doc walks through TESLA (Timed Efficient Stream Loss-Tolerant Authentication 🔐), which is a way to check that packets really came from the sender and didn't get messed with, and then shows how to plug it into two multicast delivery protocols: ALC (Asynchronous Layered Coding) and NORM (NACK-Oriented Reliable Multicast) 🔥
Here's the lowkey important bit: it only covers authenticating and integrity-checking packets sent by the session's sender. Checking packets from the receivers (if there are any) is out of scope for this doc 🙈 That's a whole other slay for another day.
Status of This Memo ✨
This document is not an Internet Standards Track specification 💖 It's been published for people to look at, try out in experimental implementations, and evaluate.
It defines an Experimental Protocol for the Internet community 🌈 It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG) 👑 Not every IESG-approved document is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you're curious about that 🧚
If you want the latest status, any errata, or a way to send feedback, go to http://www.rfc-editor.org/info/rfc5776 🫶
Copyright Notice 💅
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. 🎀
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Please actually read these, bestie, because they explain your rights and restrictions for this doc 📖 Any Code Components pulled out of this document have to include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License says 🍓
Heads up: this document may include material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The people who hold the copyright on some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. So unless you get a proper license from those copyright holders, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process. The exceptions are formatting it for publication as an RFC or translating it into languages other than English 🙈
Table of Contents 🗂️
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Scope of This Document . . . . . . . . . . . . . . . . . . 6
1.2. Conventions Used in This Document . . . . . . . . . . . . 7
1.3. Terminology and Notations . . . . . . . . . . . . . . . . 7
1.3.1. Notations and Definitions Related to Cryptographic
Functions . . . . . . . . . . . . . . . . . . . . . . 7
1.3.2. Notations and Definitions Related to Time . . . . . . 8
2. Using TESLA with ALC and NORM: General Operations . . . . . . 9
2.1. ALC and NORM Specificities That Impact TESLA . . . . . . . 9
2.2. Bootstrapping TESLA . . . . . . . . . . . . . . . . . . . 10
2.2.1. Bootstrapping TESLA with an Out-Of-Band Mechanism . . 10
2.2.2. Bootstrapping TESLA with an In-Band Mechanism . . . . 11
2.3. Setting Up a Secure Time Synchronization . . . . . . . . . 11
2.3.1. Direct Time Synchronization . . . . . . . . . . . . . 12
2.3.2. Indirect Time Synchronization . . . . . . . . . . . . 12
2.4. Determining the Delay Bounds . . . . . . . . . . . . . . . 13
2.4.1. Delay Bound Calculation in Direct Time
Synchronization Mode . . . . . . . . . . . . . . . . . 14
2.4.2. Delay Bound Calculation in Indirect Time
Synchronization Mode . . . . . . . . . . . . . . . . . 14
2.5. Cryptographic Parameter Values . . . . . . . . . . . . . . 15
3. Sender Operations . . . . . . . . . . . . . . . . . . . . . . 16
3.1. TESLA Parameters . . . . . . . . . . . . . . . . . . . . . 16
3.1.1. Time Intervals . . . . . . . . . . . . . . . . . . . . 16
3.1.2. Key Chains . . . . . . . . . . . . . . . . . . . . . . 16
3.1.3. Time Interval Schedule . . . . . . . . . . . . . . . . 20
3.1.4. Timing Parameters . . . . . . . . . . . . . . . . . . 20
3.2. TESLA Signaling Messages . . . . . . . . . . . . . . . . . 21
3.2.1. Bootstrap Information . . . . . . . . . . . . . . . . 21
3.2.2. Direct Time Synchronization Response . . . . . . . . . 22
3.3. TESLA Authentication Information . . . . . . . . . . . . . 22
3.3.1. Authentication Tags . . . . . . . . . . . . . . . . . 23
3.3.2. Digital Signatures . . . . . . . . . . . . . . . . . . 23
3.3.3. Group MAC Tags . . . . . . . . . . . . . . . . . . . . 24
3.4. Format of TESLA Messages and Authentication Tags . . . . . 25
3.4.1. Format of a Bootstrap Information Message . . . . . . 26
3.4.2. Format of a Direct Time Synchronization Response . . . 31
3.4.3. Format of a Standard Authentication Tag . . . . . . . 32
3.4.4. Format of an Authentication Tag without Key
Disclosure . . . . . . . . . . . . . . . . . . . . . . 33
3.4.5. Format of an Authentication Tag with a "New Key
Chain" Commitment . . . . . . . . . . . . . . . . . . 34
3.4.6. Format of an Authentication Tag with a "Last Key
of Old Chain" Disclosure . . . . . . . . . . . . . . . 35
4. Receiver Operations . . . . . . . . . . . . . . . . . . . . . 36
4.1. Verification of the Authentication Information . . . . . . 36
4.1.1. Processing the Group MAC Tag . . . . . . . . . . . . . 36
4.1.2. Processing the Digital Signature . . . . . . . . . . . 37
4.1.3. Processing the Authentication Tag . . . . . . . . . . 37
4.2. Initialization of a Receiver . . . . . . . . . . . . . . . 38
4.2.1. Processing the Bootstrap Information Message . . . . . 38
4.2.2. Performing Time Synchronization . . . . . . . . . . . 38
4.3. Authentication of Received Packets . . . . . . . . . . . . 40
4.3.1. Discarding Unnecessary Packets Earlier . . . . . . . . 43
4.4. Flushing the Non-Authenticated Packets of a Previous
Key Chain . . . . . . . . . . . . . . . . . . . . . . . . 43
5. Integration in the ALC and NORM Protocols . . . . . . . . . . 44
5.1. Authentication Header Extension Format . . . . . . . . . . 44
5.2. Use of Authentication Header Extensions . . . . . . . . . 45
5.2.1. EXT_AUTH Header Extension of Type Bootstrap
Information . . . . . . . . . . . . . . . . . . . . . 45
5.2.2. EXT_AUTH Header Extension of Type Authentication
Tag . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.2.3. EXT_AUTH Header Extension of Type Direct Time
Synchronization Request . . . . . . . . . . . . . . . 49
5.2.4. EXT_AUTH Header Extension of Type Direct Time
Synchronization Response . . . . . . . . . . . . . . . 49
6. Security Considerations . . . . . . . . . . . . . . . . . . . 50
6.1. Dealing with DoS Attacks . . . . . . . . . . . . . . . . . 50
6.2. Dealing With Replay Attacks . . . . . . . . . . . . . . . 51
6.2.1. Impacts of Replay Attacks on TESLA . . . . . . . . . . 51
6.2.2. Impacts of Replay Attacks on NORM . . . . . . . . . . 52
6.2.3. Impacts of Replay Attacks on ALC . . . . . . . . . . . 53
6.3. Security of the Back Channel . . . . . . . . . . . . . . . 53
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 55
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 55
9.1. Normative References . . . . . . . . . . . . . . . . . . . 55
9.2. Informative References . . . . . . . . . . . . . . . . . . 561. Introduction ✨
okay bestie, so lots of apps using multicast and broadcast need every receiver to verify who sent each packet AND that nobody messed with it 🔒. This is the vibe for ALC [RFC5775] and NORM [RFC5740], two Content Delivery Protocols (CDPs) built to move objects (think files 📁) reliably from a session's sender to a bunch of receivers 💖.
NORM is bidirectional. Each receiver acknowledges what it got or, if packets got erased, asks for retransmissions 🔁. ALC is the total opposite and is purely unidirectional 📡. Its reliability comes from cyclically sending the content within a carousel and/or from proactive Forward Error Correction (FEC) codes 🧩. Both run at the application level, on top of an erasure channel (like the Internet 🌐) where packets can get lost (erased) mid-transmission 💀.
The goal here is to stop attackers who pretend to be the ALC or NORM session's sender and inject forged packets into receivers, which corrupts the objects the receivers rebuild 😤.
Preventing this is way more complex with groups than with unicast 🙈. With unicast there's a simple fix: the sender and receiver share a secret key and compute a Message Authentication Code (MAC) over all messages exchanged. That doesn't work for multicast and broadcast, though, because sharing a group key between the sender and all receivers means any group member can impersonate the sender and send forged messages to other receivers. Ugh 💅.
The usual fix for source authentication and message integrity in multicast and broadcast is asymmetric cryptography with digital signatures. The catch is that this is limited by high computational costs and high transmission overheads 🐢. The Timed Efficient Stream Loss-tolerant Authentication (TESLA) protocol is an alternative that provides both services while staying compatible with high-rate transmissions over lossy channels ✨.
This document explains how to integrate the TESLA source authentication and packet integrity protocol into the ALC and NORM CDPs 🎀. Any application built on top of ALC and NORM will directly benefit from TESLA's services at the transport layer. That includes File Delivery over Unidirectional Transport (FLUTE) 🧚.
For more on TESLA and its principles, check [RFC4082] and [Perrig04]. For ALC and NORM, check [RFC5775], [RFC5651], and [RFC5740], respectively. For FLUTE, check [RMT-FLUTE] 📚.
1.1. Scope of This Document
okay so this spec only looks at authenticating and checking the integrity of packets generated by the session's sender 📤. It does not consider packets that receivers might send, like NORM's feedback packets 🙅. [RMT-SIMPLE-AUTH] describes several techniques for that. Since that's usually a low-rate flow (unlike the downstream one), using heavy techniques like digital signatures, possibly combined with a Group MAC scheme, is often acceptable 👍. Finally, Section 5 explains how to use several authentication schemes in one session thanks to the "ASID" (Authentication Scheme IDentifier) field 🪪.
This spec relies on several external mechanisms, like:
- to communicate securely the public key or a certificate for the session's sender (Section 2.2.2);
- to communicate securely and confidentially the group key,
K_g, used by the Group MAC feature, when applicable (Section 3.3.3). In some situations, this group key will have to be periodically refreshed 🔄; - to perform secure time synchronization in indirect mode (Section 2.3.2) or in direct mode (Section 2.3.1) to carry the request/response messages with ALC, which is purely unidirectional ⏰;
These mechanisms are required in order to bootstrap TESLA at a sender and at a receiver, and they must be deployed in parallel to TESLA. Also, the randomness of the Primary Key of the key chain (Section 3.1.2) is vital to TESLA's security, so the sender needs an appropriate mechanism to generate this random key 🎲.
Several technical details of TESLA are specific to the target use case (Section 3.1.2). That includes the most appropriate way to alternate between transmitting a key disclosure and a commitment to a new key chain, transmitting a key disclosure and the last key of the previous key chain, or disclosing a key with the compact flavor that does not disclose any key 🎯. For instance, it depends on the number of packets sent per time interval, the desired robustness, and the acceptable transmission overhead, which can only be optimized after taking the use-case specifics into account 🧠.
1.2. Conventions Used in This Document
Here's the official BCP 14 vocab, bestie 📖:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
1.3. Terminology and Notations
The following notations and definitions are used throughout this document 🤓.
1.3.1. Notations and Definitions Related to Cryptographic Functions
Notations and definitions related to cryptographic functions [RFC4082][RFC4383]:
PRFis the Pseudo Random Function;MACis the Message Authentication Code;HMACis the keyed-Hash Message Authentication Code;Fis the one-way function used to create the key chain (Section 3.1.2.1);F'is the one-way function used to derive the HMAC keys (Section 3.1.2.1);n_pis the length, in bits, of theFfunction's output. This is therefore the length of the keys in the key chain;n_fis the length, in bits, of theF'function's output. This is therefore the length of the HMAC keys;n_mis the length, in bits, of the truncated output of the MAC [RFC2104]. Only then_mmost significant bits of the MAC output are kept;Nis the length of a key chain. There are N+1 keys in a key chain:K_0,K_1, ...,K_N. When several chains are used, all the chains MUST have the same length and keys are numbered consecutively, following the time interval numbering 🔢;n_cis the number of keys in a key chain. Therefore,n_c = N+1;n_tx_lastkeyis the number of additional intervals during which the last key of the old key chain SHOULD be sent, after switching to a new key chain and after waiting for the disclosure delayd. These extra transmissions take place after the interval during which the last key is normally disclosed. Then_tx_lastkeyvalue is either 0 (no extra disclosure) or larger. This parameter is sender specific and is not communicated to the receiver 🤫;n_tx_newkccis the number of intervals during which the commitment to a new key chain SHOULD be sent, before switching to the new key chain. Then_tx_newkccvalue is either 0 (no commitment sent within authentication tags) or larger. This parameter is sender specific and is not communicated to the receiver 🤫;K_gis a shared group key, communicated to all group members, confidentially, during the TESLA bootstrapping (Section 2.2) 🔐;n_wis the length, in bits, of the truncated output of the MAC of the optional group authentication scheme: only then_wmost significant bits of the MAC output are kept.n_wis typically small, a multiple of 32 bits (e.g., 32 bits) 💜.
1.3.2. Notations and Definitions Related to Time
Notations and definitions related to time:
iis the time interval index. Interval numbering starts at 0 and increases consecutively. Since the interval index is stored as a 32-bit unsigned integer, wrapping to 0 might take place in long sessions 🔄;t_sis the sender local time value at some absolute time (in NTP timestamp format);t_ris the receiver local time value at the same absolute time (in NTP timestamp format);T_0is the start time corresponding to the beginning of the session, i.e., the beginning of time interval 0 (in NTP timestamp format) 🕐;T_intis the interval duration (in milliseconds);dis the key disclosure delay (in number of intervals);D_tis the upper bound of the lag of the receiver's clock with respect to the clock of the sender;S_sris an estimated bound of the clock drift between the sender and a receiver throughout the duration of the session;D^O_tis the upper bound of the lag of the sender's clock with respect to the time reference in indirect time synchronization mode;D^R_tis the upper bound of the lag of the receiver's clock with respect to the time reference in indirect time synchronization mode;D_erris an upper bound of the time error between all the time references, in indirect time synchronization mode;- NTP timestamp format consists of a 64-bit unsigned fixed-point number, in seconds relative to 0h on 1 January 1900. The integer part is in the first 32 bits, and the fraction part is in the last 32 bits [RFC1305] 🗓️.
2. Using TESLA with ALC and NORM: General Operations ✨
2.1. ALC and NORM Specificities That Impact TESLA ✨
okay so ALC and NORM each have some quirks that seriously change how TESLA can be used 💅
In the case of ALC:
- Massively scalable 📈: nothing in the protocol specification limits how many receivers can join a session. So an ALC session can potentially include a huge number (e.g., millions or more) of receivers.
- Works on purely unidirectional channels 🛰️: this is one of ALC's biggest assets! Examples of unidirectional channels include satellite (even if a back channel might exist in some use cases) and broadcasting networks like Digital Video Broadcasting - Handhelds / Satellite services to Handhelds (DVB-H/SH).
- On-demand delivery 🎀: ALC defines an on-demand content delivery model [RFC5775], where receivers can arrive whenever they like, download the content, and leave the session. Other models (e.g., push or streaming) are also defined.
- Very long sessions ⏳: an ALC session can last several days or months, during which the content is continuously transmitted within a carousel. The content can be either static (e.g., a software update) or dynamic (e.g., a web site).
Depending on the use case, some of these features may not apply. For instance, ALC can also be used over a bidirectional channel or with a limited number of receivers.
In the case of NORM:
- Built for medium-size sessions 🦋: NORM relies on feedback messages, and the sender may collapse if the feedback message rate is too high.
- Needs a bidirectional transport channel 🔁: the back channel doesn't have to be high-data-rate, because the control traffic sent over it by a single receiver is an order of magnitude lower than the downstream traffic. Networks with asymmetric connectivity (e.g., a high-rate satellite downlink and a low-rate return channel) are a good fit.
2.2. Bootstrapping TESLA
To set up the TESLA component at a receiver, the sender MUST communicate some key information in a secure way, so the receiver can check where the information came from and whether it's intact 🔐. There are two general methods:
- by using an out-of-band mechanism, or
- by using an in-band mechanism.
The current specification doesn't recommend any particular mechanism for bootstrapping TESLA. Picking between in-band and out-of-band is up to the implementer, depending on the target use case 🌸. Still, it is RECOMMENDED that TESLA implementations support the in-band mechanism for interoperability purposes. Bestie, that's the one to make sure you've got!
2.2.1. Bootstrapping TESLA with an Out-Of-Band Mechanism
For instance, [RFC4442] describes using the MIKEY (Multimedia Internet Keying) protocol to bootstrap TESLA. As a side effect, MIKEY also provides a loose time synchronization feature that TESLA can benefit from ✨. Other solutions, for instance ones based on an extended session description, are possible, on the condition that they provide the required security level.
2.2.2. Bootstrapping TESLA with an In-Band Mechanism
This specification describes an in-band mechanism 🧚. In some use cases, it might be desired to bootstrap without any additional external mechanism. For example, each device may have a clock with a known time-drift that is negligible compared to the time accuracy TESLA needs, and each device may embed the sender's public key. It's also possible that the use case has no bidirectional channel, which rules out out-of-band protocols like MIKEY. For these two examples, the exchange of a bootstrap information message (described in Section 3.4.1) plus knowing a few additional parameters (listed below) is enough to bootstrap TESLA at a receiver.
Some parameters can't be communicated in-band. In particular:
- the sender or group controller MUST either communicate the public key of the sender or a certificate (which also means that a PKI has been set up) to all receivers, so that each receiver can verify the signature of the bootstrap message and direct time synchronization response messages (when applicable).
- when time synchronization is performed with NTP/SNTP (Simple Network Time Protocol), the sender or group controller MUST communicate the list of valid NTP/SNTP servers to all the session members (sender included), so they can all synchronize on the same NTP/SNTP servers 🕰️.
- when the Group MAC feature is used, the sender or group controller MUST communicate the
K_ggroup key to all the session members (sender included). This group key may be periodically refreshed 🔄.
How these parameters get communicated is out of the scope of this document.
2.3. Setting Up a Secure Time Synchronization
TESLA's security leans heavily on time ⏰. So the session's sender and each receiver need to be time synchronized in a secure way. There are two general methods:
- direct time synchronization, and
- indirect time synchronization.
A given session can also include receivers that use direct time synchronization while others use indirect time synchronization. Mixing is allowed, bestie 🫶.
2.3.1. Direct Time Synchronization
With direct time synchronization, each receiver asks the sender for a time synchronization. To do that, a receiver sends a direct time synchronization request (Section 4.2.2.1). The sender then answers each request directly with a direct time synchronization response (Section 3.4.2), signing the reply. When a receiver gets that response, it first verifies the signature, and then calculates an upper bound of the lag of its clock with respect to the clock of the sender, D_t. The details on how to calculate D_t are in Section 2.4.1.
This method is both simple and secure 😌. But there are two potential issues:
- a bidirectional channel must exist between the sender and each receiver, and
- the sender may collapse if the incoming request rate is too high 💀.
Relying on direct time synchronization isn't expected to be an issue with NORM, since (1) bidirectional communications already take place, and (2) NORM scalability is limited anyway. Still, if there's a risk that the sender may collapse, a mechanism (out of the scope of this document) might be needed to spread the transmission of direct time synchronization request messages over time.
But direct time synchronization is potentially incompatible with ALC 🙈, since (1) there might not be a back channel, and (2) there could be a huge number of receivers, which means a real risk that the sender collapses.
2.3.2. Indirect Time Synchronization
With indirect time synchronization, the sender and each receiver must synchronize securely via an external time reference. There are several possibilities:
- sender and receivers can synchronize through an NTPv3 (Network Time Protocol version 3) [RFC1305] hierarchy of servers. The authentication mechanism of NTPv3 MUST be used to authenticate each NTP message individually. This prevents, for instance, an attacker from impersonating an NTP server 🛡️.
- they can synchronize through an NTPv4 (Network Time Protocol version 4) [NTP-NTPv4] hierarchy of servers. The Autokey security protocol of NTPv4 MUST be used to authenticate each NTP message individually.
- they can synchronize through an SNTPv4 (Simple Network Time Protocol version 4) [RFC4330] hierarchy of servers. The authentication features of SNTPv4 must then be used. Note that TESLA only needs a loose (but secure) time synchronization, which is in line with what SNTP offers 👍.
- they can synchronize through a GPS or Galileo (or similar) device that also provides a high precision time reference. Spoofing attacks on the GPS system have recently been reported 🚨. Depending on the use case, the security achieved will or will not be acceptable.
- they can synchronize thanks to dedicated hardware, embedded in each sender and receiver, that provides a clock whose time-drift is negligible compared to TESLA's time accuracy requirements 🔧. This lets a device sync its embedded clock with the official time reference from time to time (in an extreme case, just once at manufacturing time), and then stay autonomous for a duration that depends on the known maximum clock drift.
A bidirectional channel is required by the NTP/SNTP schemes. On the flip side, the GPS/Galileo and high precision clock schemes make no such assumption 🌈. When ALC runs on purely unidirectional transport channels (Section 2.1), the NTP/SNTP schemes aren't possible. Scalability matters too: ALC's requirement, and to a lesser extent NORM's, means the above mechanisms usually don't cause any problem, unlike the direct time synchronization schemes. So indirect time synchronization can be a good choice 👑.
It's worth noting that the NTP/SNTP schemes assume each client trusts the sender and accepts aligning its NTP/SNTP configuration to the sender's. If that assumption doesn't hold, the sender SHOULD offer an alternative solution.
The details on how to calculate an upper bound of the lag of a receiver's clock with respect to the clock of the sender, D_t, are in Section 2.4.2.
2.4. Determining the Delay Bounds
Let's assume a secure time synchronization has been set up 🎀. This section explains how to define the various timing parameters used when authenticating received packets.
2.4.1. Delay Bound Calculation in Direct Time Synchronization Mode
In direct time synchronization mode, synchronization between a receiver and the sender follows this protocol [RFC4082]:
- The receiver sends a direct time synchronization request message to the sender, which includes
t_r, the receiver's local time at the moment of sending (Section 4.2.2.1). - When the sender gets this message, it records its local time,
t_s, and sends the receiver a direct time synchronization response that includest_r(taken from the request) andt_s, signing this reply (Section 3.4.2). - When the receiver gets this response, it first verifies that it actually sent a request with
t_r, and then checks the signature. Then it calculatesD_t = t_s - t_r + S_sr, whereS_sris an estimated bound of the clock drift between the sender and the receiver throughout the duration of the session. This document does not specify howS_sris estimated 🤷♀️.
After this initial synchronization, at any point during the session, the receiver knows that:
T_s < T_r + D_twhere T_s is the current time at the sender and T_r is the current time at the receiver. Periodt! 💖
2.4.2. Delay Bound Calculation in Indirect Time Synchronization Mode
In indirect time synchronization, the sender and the receivers must synchronize indirectly using one or several time references 🧭.
2.4.2.1. Single Time Reference 🕰️
Okay, so let's pretend there's just one time reference, like one clock everyone trusts 🫶 Here's how it goes:
- The sender works out
D^O_t, the upper bound of how much the sender's clock lags behind the time reference. ThisD^O_tvalue then gets communicated to the receivers (see Section 3.2.1) 💌 - A receiver
Rdoes the same thing and works outD^R_t, the upper bound of how much the receiver's clock lags behind the time reference ⏰ - Then, for receiver
R, the overall upper bound on how far the receiver's clock lags behind the sender's clock,D_t, is the sum:D_t = D^O_t + D^R_t✨
How you calculate D^O_t and D^R_t depends on the time synchronization mechanism you're using (see Section 2.3.2). Sometimes the synchronization scheme specs already give you these values 🙌 Other times, you can calculate them with a scheme like the one in Section 2.4.1. For example, that happens when synchronization is done through a group controller [RFC4082] 🦋
2.4.2.2. Multiple Time References 🌈
Now let's say there are several time references, like a bunch of NTP/SNTP servers 🖥️ The sender and receivers each sync with those references on their own, which gives you D^O_t and D^R_t. Then D_err is an upper bound on the time error between all of the time references. The overall D_t within receiver R is set to the sum: D_t = D^O_t + D^R_t + D_err 💜
Sometimes the D_t value is already part of the time synchronization scheme specs. For instance, NTPv3 [RFC1305] defines algorithms that are "capable of accuracies in the order of a millisecond, even after extended periods when synchronization to primary reference sources has been lost". Realistically, depending on the NTP server stratum, the accuracy might be a little bit worse 👀 In that case, D_t = security_factor * (1ms + 1ms), where security_factor is there to make up for several sources of inaccuracy in NTP. Picking the security_factor value is up to the implementer, depending on the target use case 🎀
2.5. Cryptographic Parameter Values 🔐
The output length of F (or F') is given by the n_p (or n_f) parameter. The n_p and n_f values depend on which PRF function you choose, as listed here:
+------------------------+---------------------+
| PRF name | n_p and n_f |
+------------------------+---------------------+
| HMAC-SHA-1 | 160 bits (20 bytes) |
| HMAC-SHA-224 | 224 bits (28 bytes) |
| HMAC-SHA-256 (default) | 256 bits (32 bytes) |
| HMAC-SHA-384 | 384 bits (48 bytes) |
| HMAC-SHA-512 | 512 bits (64 bytes) |
+------------------------+---------------------+Computing a regular MAC (or a Group MAC) uses the n_m (or n_w) parameter, which is the length of the truncated output of the function. The n_m and n_w values depend on which MAC function you choose, as listed here:
+------------------------+---------------------+-------------------+
| MAC name | n_m (regular MAC) | n_w (Group MAC) |
+------------------------+---------------------+-------------------+
| HMAC-SHA-1 | 80 bits (10 bytes) | 32 bits (4 bytes) |
| HMAC-SHA-224 | 112 bits (14 bytes) | 32 bits (4 bytes) |
| HMAC-SHA-256 (default) | 128 bits (16 bytes) | 32 bits (4 bytes) |
| HMAC-SHA-384 | 192 bits (24 bytes) | 32 bits (4 bytes) |
| HMAC-SHA-512 | 256 bits (32 bytes) | 32 bits (4 bytes) |
+------------------------+---------------------+-------------------+3. Sender Operations 🚀
This section is all about the TESLA operations at a sender 💅 If you want the full scoop on TESLA and its principles, go check out [RFC4082][Perrig04] 📚
3.1. TESLA Parameters ⭐
3.1.1. Time Intervals ⏳
The sender chops time up into uniform intervals of duration T_int 🍓 Interval numbering starts at 0 and goes up one at a time. The interval index MUST be stored in an unsigned 32-bit integer, so that wrapping back to 0 only happens after 2^^32 intervals. For instance, if T_int is equal to 0.5 seconds, then wrapping happens after approximately 68 years 🙈
3.1.2. Key Chains 🔗
3.1.2.1. Principles 🧚
The sender computes a one-way key chain of n_c = N+1 keys and assigns one key from the chain to each interval. It goes consecutively, but in reverse order 🔄 Key numbering starts at 0 and goes up one at a time, following the time interval numbering: K_0, K_1, ..., K_N.
To build this chain, the sender has to first pick a Primary Key, K_N, and a PRF function, f (Section 7, TESLA-PRF). The randomness of the Primary Key, K_N, is vital to the security, so nobody should be able to guess it 🔐
The function F is a one-way function defined as: F(k) = f_k(0), where f_k(0) is the result of applying the PRF f to k and 0. When f is an HMAC (Section 7), k is used as the key and 0 as the message, using the algorithm described in [RFC2104] 🧮
Similarly, the function F' is a one-way function defined as: F'(k) = f_k(1), where f_k(1) is the result of applying the same PRF f to k and 1 ✨
The sender then computes all the keys of the chain, recursively, starting from K_N, using: K_{i-1} = F(K_i). So, K_i = F^{N-i}(K_N), where F^i(x) is the execution of function F with argument x, done i times. The receiver can then compute any value in the key chain starting from K_N, even without the intermediate values [RFC4082] 💖 The key for MAC calculation can then be derived from the matching K_i key by K'_i = F'(K_i) 🌸
The key chain has a finite length, N, which corresponds to a maximum time duration of (N + 1) * T_int. The content delivery session has a duration T_delivery, which might be known in advance or might not 🤷♀️ One option is a single key chain of the right length, so the content delivery session finishes before the end of the key chain, i.e., T_delivery <= (N + 1) * T_int. But the longer the key chain, the more memory and computation it takes to handle it 😩 Another option is switching to a new key chain of the same length when needed [Perrig04] 🔁
3.1.2.2. Using Multiple Key Chains 🔀
When you're using several key chains, all of them MUST be the same length 📏 Switching from the current key chain to the next one requires that a commitment to the new key chain gets communicated to the receiver in a secure way. You can do this with either an out-of-band mechanism or an in-band mechanism. This document only specifies the in-band mechanism 🙌
< -------- old key chain --------- >||< -------- new key chain --...
+-----+-----+ .. +-----+-----+-----+||+-----+-----+-----+-----+-----+
0 1 .. N-2 N-1 N || N+1 N+2 N+3 N+4 N+5
||
Key disclosures: ||
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
| || | |
|< -------------- >|| |< ------------- >|
Additional key F(K_N+1) || K_N
disclosures (commitment to || (last key of the
(in parallel): the new chain) || old chain)
Figure 1: Switching to the Second Key Chain with the In-Band
Mechanism, Assuming That d=2, n_tx_newkcc=3, n_tx_lastkey=3Figure 1 shows the switch to the new key chain using the in-band mechanism 🎬 Let's say the old key chain stops at K_N and the new key chain starts at K_{N+1} (so F(K_{N+1}) and K_N are two different keys). The sender then includes the commitment F(K_{N+1}) to the new key chain in packets that were authenticated with the old key chain (see Section 3.4.5). This commitment SHOULD be sent during n_tx_newkcc time intervals before the end of the old key chain. Since several packets usually go out in one interval, the sender SHOULD alternate between sending a disclosed key of the old key chain and the commitment to the new key chain 💕 How exactly to alternate between the disclosure and the commitment is out of the scope of this document.
The receiver keeps the commitment until key K_{N+1} gets disclosed, at interval N+1+d. Then the receiver can check that key's validity by computing F(K_{N+1}) and comparing it to the commitment ✅
Once the key chain changes, it becomes impossible to recover a previous key from the old key chain. That's a problem if the receiver lost the packets that disclosed the last key of the old key chain 😭 A fix is to re-send the last key, K_N, of the old key chain (see Section 3.4.6). This SHOULD be done during n_tx_lastkey additional time intervals after the end of the time interval where K_N is disclosed. Since several packets usually go out in one interval, the sender SHOULD alternate between sending a disclosed key of the new key chain and the last key of the old key chain. How exactly to alternate between those two disclosures is out of the scope of this document 🌷
Sometimes a receiver that had a really long disconnection might have lost the commitment of the new chain. If that happens, this receiver won't be able to authenticate any packet related to the new chain, or any of the ones after it 💀 The only way for this receiver to catch up is to receive an additional bootstrap information message. That can happen by waiting for the next periodic transmission (if it's sent in-band) or through an external mechanism (Section 3.2.1) 🫠
3.1.2.3. Values of the n_tx_lastkey and n_tx_newkcc Parameters 🧮
When you use several key chains together with the in-band commitment mechanism, a sender MUST initialize the n_tx_lastkey and n_tx_newkcc parameters so that no overlapping occurs 🚫 In other words, once a sender starts transmitting commitments for a new key chain, it MUST NOT send a disclosure for the last key of the old key chain anymore 🙅♀️ So the following property MUST be verified:
d + n_tx_lastkey + n_tx_newkcc <= N + 1For robustness, it is RECOMMENDED that, once n_tx_lastkey has been chosen, you then set:
n_tx_newkcc = N + 1 - n_tx_lastkey - dIn other words, the sender starts transmitting a commitment to the following key chain right after sending all the disclosures of the last key of the previous key chain. Doing this increases the chance that a receiver gets a commitment for the following key chain 🎯
Either way, these two parameters are specific to the sender and don't need to be sent to the receivers 💁♀️ And as explained above, the sender alternates between disclosing a key of the current key chain and sending the commitment to the new key chain (or the last key of the old key chain).
3.1.2.4. The Particular Case of the Session Start 🎀
A key can't be disclosed before the disclosure delay, d, so no key gets disclosed during the first d time intervals of the session (intervals 0 and 1 in Figure 1) 🌅 For that, the sender uses the Authentication Tag without Key Disclosure, Section 3.4.4. The following key chains, if there are any, aren't affected by this, since they'll disclose the last d keys of the previous chain 💜
3.1.2.5. Managing Silent Periods ✨
okay so an ALC or NORM sender can totally go quiet for a bit 🫠. maybe the session is over and everything's already been sent, or maybe the vibe is busy bursts (when fresh objects show up) followed by silent periods 😴. either way it's kinda a problem bc the packets sent during the last d intervals need their keys disclosed, and that only happens d more intervals later 💀.
to fix this, it is recommended that the sender transmit empty packets (no payload 🫧) carrying the TESLA EXT_AUTH Header Extension along with a Standard Authentication Tag, for at least d time intervals after the regular ALC or NORM packet transmissions end 🎀. the number of these packets and how long they go out for must be enough that every receiver gets, with high probability, at least one packet that discloses the last useful key (aka the key used for the last non-empty packet sent) 🔑🫶.
3.1.3. Time Interval Schedule 🗓️
the sender must figure out these parameters:
T_0, the start time for the beginning of the session, i.e., the beginning of time interval 0 (in NTP timestamp format) ⏰;T_int, the interval duration (in milliseconds), usually somewhere from 100 milliseconds to 1 second 🎶;d, the key disclosure delay (in number of intervals). basically how long to wait before disclosing a key ⏳;N, the length of a key chain 🔗.
picking T_int, d, and N correctly is crucial for efficiency, no cap 💅. a T_int * d that's too long means the authentication process gets super laggy 🐌, while one that's too short stops a lot of receivers from verifying packets 😭. an N * T_int that's too small makes the sender keep switching to new key chains way too often 🙄. an N that's too long for the expected session duration (if it's known) means the sender computes a bunch of useless keys 🗑️. Sections 3.2 and 3.6 of [RFC4082] give general guidelines for setting these up 📖.
theT_0,T_int,d, andNparameters MUST NOT be changed during the lifetime of the session. this restriction exists to avoid introducing vulnerabilities 🚨. like, if a sender were allowed to change the key disclosure schedule, a receiver that missed the change notification would still believe the old schedule, and boom, vulnerabilities [RFC4082] 💀.
3.1.4. Timing Parameters ⏱️
in indirect time synchronization mode, the sender must determine this parameter:
D^O_t, the upper bound of the lag of the sender's clock with respect to the time reference.
the D^O_t parameter MUST NOT be changed during the lifetime of the session 🙅♀️.
3.2. TESLA Signaling Messages 📣
at a sender, TESLA makes two kinds of signaling info:
- the bootstrap information: it can be sent out-of-band or in-band. in-band means a digitally signed packet carries everything needed to bootstrap TESLA at a receiver;
- the direct time synchronization response, which lets a receiver finish a direct time synchronization.
3.2.1. Bootstrap Information 🥾
to set up the TESLA component at a receiver, the sender must share some key info in a secure way 🔐. this can go in-band or out-of-band, as covered in Section 2.2. here we're only looking at the in-band scheme.
the TESLA bootstrap information message MUST be digitally signed (Section 3.3.2) 🖊️. the goal is letting a receiver check the packet source and integrity ✅. then the bootstrap info can be:
- unicast to a receiver during a direct time synchronization request/response exchange;
- broadcast to all receivers. this is typical in indirect time synchronization mode. it can also work in direct mode, like when a large number of clients arrive at the same time, since answering globally is more efficient 🌍.
let's talk about when the bootstrap info gets broadcast 📡. this message should be broadcast at the beginning of the session, before data packets are actually sent. this is super important with ALC or NORM sessions in "push" mode, when all clients join in advance 🙌. for improved reliability, bootstrap info might be sent a certain number of times 🔁.
a periodic broadcast of the bootstrap info could also be useful when:
- the ALC session uses an "on-demand" mode, with clients arriving at their own discretion 🚪;
- some clients experience intermittent connectivity. this is particularly important when several key chains are used in an ALC or NORM session, since there's a risk that a receiver loses all the commitments to the new key chain 😱.
a balance must be found between signaling overhead and the maximum initial waiting time at the receiver before starting the delayed authentication process ⚖️. a period of a few seconds for transmitting this bootstrap info is often a reasonable value ⏲️.
3.2.2. Direct Time Synchronization Response 🤝
in direct time sync, when a sender gets a synchronization request, it records its local time, t_s, and sends back a response that contains both t_r and t_s (Section 2.4.1). this response is unicast to the receiver. this direct time synchronization response message MUST be digitally signed so the receiver can check the packet source and integrity (Section 3.3.2). the receiver MUST also be able to match this response to its request, which is why t_r is included in the response 💖.
3.3. TESLA Authentication Information 🔏
at a sender, TESLA produces three types of security tags:
- an authentication tag, for data packets, which contains the MAC of the packet;
- a digital signature, for one of the two TESLA signaling packets: a bootstrap information message or a direct time synchronization response; and
- an optional group authentication tag, which can be added to all the packets to mitigate attacks coming from outside the group 🛡️.
because of interdependencies, their computation MUST follow a strict order 🧩:
- first, compute the authentication tag (with data packets) or the digital signature (with signaling packets);
- finally, compute the Group Mac.
3.3.1. Authentication Tags 🏷️
all the data packets sent MUST have an authentication tag containing:
- the interval index, i, which is also the index of the key used for computing the MAC of this packet;
- the MAC of the message:
MAC(K'_i, M), whereK'_i=F'(K_i); - either a disclosed key (which belongs to the current key chain or the previous key chain), or a commitment to a new key chain, or no key at all.
the computation of MAC(K'_i, M) MUST include the ALC or NORM header (with the various header extensions) and the payload (when applicable). the UDP/IP headers MUST NOT be included. during this computation, the "MAC(K'_i, M)" field of the authentication tag MUST be set to 0 💅.
3.3.2. Digital Signatures ✍️
the bootstrap information message (with the in-band bootstrap scheme) and the direct time synchronization response message (with the indirect time synchronization scheme) both need to be signed by the sender. these two messages have a "Signature" field to hold the digital signature. the bootstrap information message also has the "Signature Encoding Algorithm", "Signature Cryptographic Function", and "Signature Length" fields so a receiver can process the "Signature" field. there are no such fields in a direct time synchronization response, since those parameters are assumed to already be known (the receiver either got a bootstrap information message before, or the values were shared out-of-band) 🧠.
several "Signature Encoding Algorithms" can be used, including RSASSA-PKCS1-v1_5 (the default) and RSASSA-PSS (Section 7) 🌈. with these encodings, SHA-256 is the default "Signature Cryptographic Function" ✨.
the computation of the signature MUST include the ALC or NORM header (with the various header extensions) and the payload when applicable. the UDP/IP headers MUST NOT be included. during this computation, the "Signature" field MUST be set to 0 as well as the optional Group MAC, when present, since this Group MAC is calculated later 🙃.
okay so for the RFC4359 details, more specifically 🤓: digital signature generation is done as described in [RFC3447], Section 8.2.1 for RSASSA-PKCS1-v1_5 and Section 8.1.1 for RSASSA-PSS. the authenticated portion of the packet is used as the message M, which gets passed to the signature generation function. the signer's RSA private key is passed as K. in short (when SHA-256 is used), the signature generation process computes a SHA-256 hash of the authenticated packet bytes, signs that hash using the private key, and encodes the result with the specified RSA encoding type. this gives a value S, which is the digital signature that goes in the packet 🔥.
with RSASSA-PKCS1-v1_5 and RSASSA-PSS signatures, the size of the signature equals the "RSA modulus", unless the "RSA modulus" isn't a multiple of 8 bits. in that case, the signature MUST be prepended with between 1 and 7 bits set to zero so the signature is a multiple of 8 bits [RFC4359]. the key size, which in practice is also equal to the "RSA modulus", has major security implications 🚨. [RFC4359] explains how to choose this value depending on the maximum expected lifetime of the session. that choice is out of scope for this document 🙏.
3.3.3. Group MAC Tags ✨
okay so an optional Group MAC can help stop DoS attacks coming from attackers who aren't group members 🛡️ [RFC4082]. This feature assumes a group key, K_g, is shared by the sender and all receivers 🔑. When the attacker is not a group member, adding a Group MAC to every packet sent gives you three big wins 💅:
- a receiver can immediately drop faked packets, without having to wait for the disclosure delay,
d🙅♀️; - a sender can immediately drop faked direct time synchronization requests, and avoid checking the digital signature, a computation-intensive task 🧠;
- a receiver can immediately drop faked direct time synchronization response and bootstrap messages, without having to verify the digital signature, a computation-intensive task 💀.
The computation of the Group MAC, MAC(K_g, M), MUST include the ALC or NORM header (with the various header extensions) and the payload when applicable. The UDP/IP headers MUST NOT be included. During this computation, the "Group MAC" field MUST be set to 0. However, the digital signature (e.g., of a bootstrap message) and the "MAC" fields (e.g., of an authentication tag), when present, MUST have been calculated since they are included in the Group MAC calculation itself. Then, the sender truncates the MAC output to keep the n_w most significant bits and stores the result in the "Group MAC" field 🎀.
This scheme comes with a few limits 🙈:
- it is of no help if a group member (who knows
K_g) impersonates the sender and sends forged messages to other receivers; - it requires an additional MAC computing for each packet, both at the sender and receiver sides;
- it increases the size of the TESLA authentication headers. In order to limit this problem, the length of the truncated output of the MAC,
n_w, SHOULD be kept small (e.g., 32 bits) (see [RFC3711], Section 9.5). As a side effect, the authentication service is significantly weakened: the probability of any forged packet being successfully authenticated becomes one in2^32. Since the Group MAC check is only a pre-check that must be followed by the standard TESLA authentication check, this is not considered to be an issue 🥹.
For a given use case, the benefits brought by the Group MAC must be balanced against these limitations ⚖️.
Note that the Group MAC function can be different from the TESLA MAC function (e.g., it can use a weaker but faster MAC function) 🏃♀️. Note also that the mechanism by which the group key, K_g, is communicated to all group members, and perhaps periodically updated, is out of the scope of this document 🌸.
3.4. Format of TESLA Messages and Authentication Tags 🦋
This section specifies the format of the various kinds of TESLA messages and authentication tags sent by the session's sender. Because these TESLA messages are carried as EXT_AUTH Header Extensions of the ALC or NORM packets (Section 5), the following formats do not start on 32-bit word boundaries 🧚.
3.4.1. Format of a Bootstrap Information Message ✨
okay so bestie, this is the bit where we look at what bootstrap info looks like when it rides in-band 🎀 Whenever it's sent that way, this message is the one we use 💅
0 1 2 3
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
+-+-+-+-+-+-+-+-+ ---
| V |resvd|S|G|A| ^
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| d | PRF Type | MAC Func Type |Gr MAC Fun Type| | f
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | i
| SigEncAlgo | SigCryptoFunc | Signature Length | | x
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | e
| Reserved | T_int | | d
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | l
+ T_0 (NTP timestamp format) + | e
| | | n
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | g
| N (Key Chain Length) | | t
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h
| Current Interval Index i | v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
| |
~ Current Key Chain Commitment +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
~ Signature ~
+ +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P| |
+-+ D^O_t Extension (optional, present if A==1) +
| (NTP timestamp diff, positive if P==1, negative if P==0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Group MAC (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Bootstrap Information FormatThe format of the bootstrap information is shown in Figure 2. Let's go field by field, bestie 🦋
"V" (Version) field (2 bits):
The "V" field holds the protocol version number. For this specification, the value of 0 MUST be used. 🌸
"Reserved" field (3 bits):
This is a reserved field and it MUST be set to zero in this specification. 🙈
"S" (Single Key Chain) flag (1 bit):
The "S" flag tells you whether this TESLA session is limited to a single key chain (S==1) or uses one or more key chains (S==0). 🧚
"G" (Group MAC Present) flag (1 bit):
The "G" flag tells you whether the Group MAC feature is in use (G==1) or not (G==0). When it is, a "Group MAC" field gets added to every packet that carries a TESLA EXT_AUTH Header Extension, including this bootstrap message. obsessed with this one 💜
"A" flag (1 bit):
The "A" flag tells you whether the "P" flag and "D^O_t" fields are there (A==1) or not (A==0). In indirect time synchronization mode, A MUST be equal to 1, because those fields are needed. 👑
"d" field (8 bits):
"d" is an unsigned integer that sets the key disclosure delay, counted in intervals. d MUST be greater than or equal to 2. 🍓
"PRF Type" field (8 bits):
The "PRF Type" is the reference number of the f function that's used to derive the F (for key chain) and F' (for MAC keys) functions (Section 7). ✨
"MAC Function Type" field (8 bits):
The "MAC Function Type" is the reference number of the function used to compute the MAC of the packets (Section 7). 🔥
"Group MAC Function Type" field (8 bits):
When G==1, this field holds the reference number of the cryptographic MAC function used to compute the Group MAC (Section 7). When G==0, this field MUST be set to zero. 🫶
"Signature Encoding Algorithm" field (8 bits):
The "Signature Encoding Algorithm" is the reference number (Section 7) of the digital signature used to authenticate this bootstrap information. It's included in the "Signature" field. 💅
"Signature Cryptographic Function" field (8 bits):
The "Signature Cryptographic Function" is the reference number (Section 7) of the cryptographic function used inside that digital signature. 🌈
"Signature Length" field (16 bits):
The "Signature Length" is an unsigned integer giving the size of the "Signature" field in bytes, as it appears in the "Signature Extension" field. It's also the signature key length, since both values are equal. 🦋
"Reserved" fields (16 bits):
This is a reserved field and it MUST be set to zero in this specification. 🙈
"T_int" field (16 bits):
"T_int" is an unsigned 16-bit integer that sets the interval duration in milliseconds. ⭐
"T_0" field (64 bits):
"T_0" is a timestamp in NTP timestamp format. It marks the beginning of the session, which is the beginning of time interval 0. 🧚
"N" field (32 bits):
"N" is an unsigned integer that gives the key chain length. There are N + 1 keys per chain. 💜
"i" (Interval Index of K_i) field (32 bits):
"i" is an unsigned integer that gives the current interval index at the moment this bootstrap information message is sent. 🌸
"Current Key Chain Commitment" field (variable size, padded if necessary for 32-bit word alignment):
The "Key Chain Commitment" is the commitment to the current key chain, meaning the key chain that matches interval i. For example, for the first key chain the commitment is F(K_0), and for the second key chain it's F(K_{N+1}), and so on. If needed, this field gets padded with 0 up to a multiple of 32 bits. 🎀
"Signature" field (variable size, padded if necessary for 32-bit word alignment):
The "Signature" field is mandatory. It holds a digital signature of this message, built according to the encoding algorithm, cryptographic function, and key length parameters. If the signature length isn't a multiple of 32 bits, this field is padded with 0. 🔥
"P" flag (optional, 1 bit if present):
The "P" flag is optional, and it only shows up if the "A" flag is equal to 1. It's only used in indirect time synchronization mode. It tells you whether the D^O_t NTP timestamp difference is positive (P==1) or negative (P==0). 🧚
"D^O_t" field (optional, 63 bits if present):
The "D^O_t" field is optional, and it only shows up if the "A" flag is equal to 1. It's only used in indirect time synchronization mode. It's the upper bound of how far behind the sender's clock can lag the time reference. When there are several time references (like several NTP servers), D^O_t is the maximum upper bound of the lag across all of them. D^O_t is made of two unsigned integers, just like NTP timestamps: the first 31 bits give the time difference in seconds, and the remaining 32 bits give the sub-second difference. 😭
"Group MAC" field (optional, variable length, multiple of 32 bits):
This field holds the Group MAC, calculated with the group key K_g that all group members share. The field length in bits is given by n_w, which you know once the Group MAC function type is known (Section 7). 💖
Quick note, bestie: the first byte and the following seven 32-bit words are mandatory fixed-length fields. The "Current Key Chain Commitment" and "Signature" fields are mandatory too, but they're variable-length. The "D^O_t" and "Group MAC" fields are the optional ones. 🌈
In order to prevent attacks, some parameters MUST NOT be changed during the lifetime of the session (Sections 3.1.3 and 3.1.4). Don't skip this part, it's giving security-critical energy 🚨
Here's the table that sums up each parameter's status 💅
+--------------------------+----------------------------------------+
| Parameter | Status |
+--------------------------+----------------------------------------+
| V | set to 0 in this specification |
| S | static (during whole session) |
| G | static (during whole session) |
| A | static (during whole session) |
| T_O | static (during whole session) |
| T_int | static (during whole session) |
| d | static (during whole session) |
| N | static (during whole session) |
| D^O_t (if present) | static (during whole session) |
| PRF Type | static (during whole session) |
| MAC Function Type | static (during whole session) |
| Signature Encoding | static (during whole session) |
| Algorithm | |
| Signature Crypto. | static (during whole session) |
| Function | |
| Signature Length | static (during whole session) |
| Group MAC Func. Type | static (during whole session) |
| i | dynamic (related to current key chain) |
| K_i | dynamic (related to current key chain) |
| signature | dynamic, packet dependent |
| Group MAC (if present) | dynamic, packet dependent |
+--------------------------+----------------------------------------+So that's the whole in-band bootstrap format, slay 🎀✨
3.4.2. Format of a Direct Time Synchronization Response 🎀
okay bestie, this is the reply to a direct time sync request, and the layout is giving pure organization 💅 Everything lines up in 32-bit rows, so here's Figure 3:
0 1 2 3
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
+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ t_s (NTP timestamp) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ t_r (NTP timestamp) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
~ Signature ~
+ +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Group MAC (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 3: Format of a Direct Time Synchronization Response
The response to a direct time sync request holds these fields:
Reserved(8 bits): this is a reserved field that MUST be set to zero in this specification. 🙅♀️t_s(NTP timestamp, 64 bits): this is a timestamp in NTP format that matches the sender's local time when it received the direct time sync request message. ⏰t_r(NTP timestamp, 64 bits): this is a timestamp in NTP format carrying the receiver's local time value that came in the direct time sync request message. 🕰️Signature(variable size, padded if necessary for 32-bit word alignment): theSignaturefield is mandatory. It holds a digital signature of this message, made using the encoding algorithm, cryptographic function, and key length parameters shared in the bootstrap information message (if applicable) or out-of-band. If the signature length isn't a multiple of 32 bits, this field gets padded with 0. ✍️Group MAC(optional, variable length, multiple of 32 bits): this field holds the Group MAC, calculated with the group key, K_g, that every group member shares. The field length in bits is given by n_w, which you know once the Group MAC function type is known (Section 7). 👯♀️
3.4.3. Format of a Standard Authentication Tag 🦋
the standard tag is the main character of the authentication world, and it carries the key disclosure too 👑 Here's Figure 4:
0 1 2 3
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
+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| i (Interval Index of K'_i) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Disclosed Key K_{i-d} ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ MAC(K'_i, M) +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Group MAC (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 4: Format of the Standard Authentication Tag
A Standard Authentication Tag is built from these fields:
Reserved(8 bits): theReservedfield isn't used in the current specification and MUST be set to zero by the sender. 🧊i(Interval Index) (32 bits):iis the interval index linked to the key (K'_i) used to compute the MAC of this packet. 🔢Disclosed Key(variable size, non padded): theDisclosed Keyis the key for interval i-d: K_{i-d}. There's no padding between theDisclosed KeyandMAC(K'_i, M)fields, and the latter MAY not start on a 32-bit boundary, depending on the n_p parameter. 🔓MAC(K'_i, M)(variable size, padded if necessary for 32-bit word alignment): this is the truncated message authentication code of the current packet. Only the n_m most significant bits of the MAC output are kept [RFC2104]. 🔐Group MAC(optional, variable length, multiple of 32 bits): this field holds the Group MAC, calculated with a group key, K_g, shared by all group members. The field length is given by n_w, in bits. 👯
Note that because a key can't be disclosed before the disclosure delay, d, the sender MUST NOT use this tag during the first d intervals of the session: {0 .. d-1} (inclusive). Instead, the sender MUST use an Authentication Tag without Key Disclosure.
⚠️ Heads up bestie: during the first d intervals, the standard tag is a no-go. Use the no-disclosure version instead, no exceptions 😭
3.4.4. Format of an Authentication Tag without Key Disclosure 🌸
this one is the shortcut tag, and it's giving efficiency 🏃♀️ It's meant for when a LOT of packets go out in one time interval. In that case, you can disclose the K_{i-d} key in only some of the packets using the Standard Authentication Tag, then use this shortened version for the rest that don't disclose it. It's left to the implementer to decide how many packets should disclose the K_{i-d} key. This tag MUST also be used during the first d intervals: {0 .. d-1} (inclusive). 🧚
Here's Figure 5:
0 1 2 3
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
+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| i (Interval Index of K'_i) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ MAC(K'_i, M) +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Group MAC (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 5: Format of the Authentication Tag without Key Disclosure
3.4.5. Format of an Authentication Tag with a "New Key Chain" Commitment 💜
during the last n_tx_newkcc intervals of the current key chain, the sender SHOULD send commitments to the next key chain 🔮 It does this by swapping the disclosed key in the tag for a New Key Chain Commitment, F(K_{N+1}) (or F(K_{2N+2}) if it's a switch between the second and third key chains, etc.). Here's Figure 6:
0 1 2 3
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
+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| i (Interval Index of K'_i) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ New Key Commitment F(K_{N+1}) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ MAC(K'_i, M) +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Group MAC (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 6: Format of the Authentication Tag with a New Key Chain Commitment
Note that since there's no padding between the F(K_{N+1}) and MAC(K'_i, M) fields, the latter MAY not start on a 32-bit boundary, depending on the n_p parameter. 🙈
3.4.6. Format of an Authentication Tag with a "Last Key of Old Chain" Disclosure 🍓
during the first n_tx_lastkey intervals of the new key chain after the disclosing interval, d, the sender SHOULD disclose the last key of the old key chain 🗝️ It does this by replacing the disclosed key in the tag with the Last Key of the Old Chain, K_N (or K_{2N+1} if it's a switch between the second and third key chains, etc.). Here's Figure 7:
0 1 2 3
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
+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| i (Interval Index of K'_i) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Last Key of Old Chain, K_N ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ MAC(K'_i, M) +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Group MAC (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 7: Format of the Authentication Tag with an Old Chain Last Key Disclosure
Note that since there's no padding between the K_N and MAC(K'_i, M) fields, the latter MAY not start on a 32-bit boundary, depending on the n_p parameter. 🫶
4. Receiver Operations ✨
This section describes the TESLA operations at a receiver. 🦻
4.1. Verification of the Authentication Information ✨
okay so this section walks through the math steps for checking each of the three possible kinds of authentication info on an incoming packet. the order is strict bestie, so the verification MUST follow it:
- first, if the Group MAC is there and the session actually uses this feature (like when the G bit is set in the bootstrap information message), verify the Group MAC. a packet that has no Group MAC tag when the session DOES use this feature MUST be dropped immediately 🙅♀️. but if a packet has a Group MAC tag and the session doesn't use the feature, that tag MUST be ignored 🫶
- then, verify the digital signature (for TESLA signaling packets) or enter the TESLA authentication process (for data packets) 💅
4.1.1. Processing the Group MAC Tag 🔐
so when a packet with a Group MAC tag shows up, the receiver recomputes the Group MAC and compares it with the value in the packet. if the check fails, the packet MUST be dropped immediately 💀
the recompute part is kinda fun ngl: you save the value of the "Group MAC" field, set that field to 0, and then do the same computation a sender would do (see Section 3.3.3).
4.1.2. Processing the Digital Signature 🖋️
when a packet has a digital signature, the receiver checks it like this:
the signature computation MUST include the ALC or NORM header (with all the header extensions) and the payload when it applies. the UDP/IP headers MUST NOT be included. while doing this computation, the "Signature" field MUST be set to 0, and so does the optional Group MAC, when one is present 🌸
from [RFC4359]: digital signature verification is done as described in [RFC3447], Section 8.2.2 (RSASSA-PKCS1-v1_5) and [RFC3447], Section 8.1.2 (RSASSA-PSS). when the signature comes in, it gets passed to the verification function as S. the authenticated part of the packet is used as the message M, and the RSA public key is passed as (n, e). the short version (when SHA-256 is used) is: the verification function computes a SHA-256 hash of the authenticated packet bytes, decrypts the SHA-256 hash in the packet, and checks that the right encoding was applied. then the two SHA-256 hashes get compared, and if they match, the validation is successful ✨
it's assumed that receivers can get the sender's public key so they can check this signature (Section 2.2). this document doesn't say how that public key gets communicated reliably and securely to every possible receiver 🥺
4.1.3. Processing the Authentication Tag 🦋
when a receiver wants to authenticate a packet with an authentication tag, AND it has the key for that time interval (so, after the disclosing delay, d), the receiver recomputes the MAC and compares it with the value in the packet. if the check fails, the packet MUST be immediately dropped 😭
the recompute goes like this: save the value of the "MAC" field, set that field to 0, and do the same computation a sender does (see Section 3.3.1).
4.2. Initialization of a Receiver 🌈
a receiver MUST be initialized before it can authenticate the source of incoming packets. this can happen through an out-of-band mechanism or an in-band mechanism (Section 2.2). we're focusing on the in-band one here. two things have to happen:
- receive and process a bootstrap information message, and
- calculate an upper bound of the sender's local time. for that, the receiver has to do time synchronization.
4.2.1. Processing the Bootstrap Information Message 📜
a receiver has to get a packet containing the bootstrap information first, and the sender digitally signs it. once the bootstrap information is authenticated (see Section 4.1), the receiver can set up its TESLA component. after that, the receiver MUST ignore the following bootstrap information messages, if there are any. there's one exception, though: when a new key chain is in use and a receiver missed all the commitments for this new key chain, then this receiver MUST process one of the future bootstrap information messages (if there are any) so it can authenticate the incoming packets tied to this new key chain 🔑
before TESLA is initialized, a receiver MUST discard incoming packets other than the bootstrap information message and the direct time synchronization response 🚫
4.2.2. Performing Time Synchronization ⏰
first things first: the receiver has to know whether the ALC or NORM session relies on direct or indirect time synchronization. that info comes through an out-of-band mechanism (for example, when the various parameters of an ALC or NORM session are described). in some cases both mechanisms might be available, and then the receiver can pick the preferred technique 💖
4.2.2.1. Direct Time Synchronization 🏓
with direct time synchronization, a receiver MUST synchronize with the sender. to do that, the receiver sends a direct time synchronization request message. this message includes the local time (in NTP timestamp format) at the receiver when it sends the message. the sender copies this timestamp into its response, so the receiver can match the response to the request 🎀
the direct time synchronization request message format looks like this:
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ t_r (NTP timestamp) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Group MAC (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Format of a Direct Time Synchronization Requestthe direct time synchronization request (Figure 8) carries these bits of info:
- "t_r" (NTP timestamp, 64 bits):
t_ris a timestamp in NTP timestamp format that holds the receiver's local time when it sends this direct time synchronization request message 🕰️ - "Group MAC" field (optional, variable length, multiple of 32 bits): this field holds the Group MAC, calculated with the group key, K_g, that all group members share. the field length, in bits, is given by n_w, which is known once the Group MAC function type is known (Section 7) 🧩
after sending that, the receiver waits for a response message (Section 3.4.2). when the response comes in, the receiver:
- checks that the response relates to the request, by comparing the "t_r" fields
- checks the Group MAC if one is present
- checks the signature
- retrieves the t_s value and calculates D_t (Section 2.4.1)
one more thing: in an ALC session, the direct time synchronization request message gets sent to the sender through an out-of-band mechanism that this document doesn't specify 🙈
4.2.2.2. Indirect Time Synchronization 🌐
with indirect time synchronization, the sender MAY provide, out-of-band, the URL or IP address of the NTP server(s) it trusts, along with an OPTIONAL certificate for each NTP server. when several NTP servers are specified, a receiver MUST choose one of them. this document doesn't say how that choice gets made, but for the sake of scalability, clients SHOULD NOT use the same server if several options are offered 🍓 the NTP synchronization between the NTP server and the receiver MUST be authenticated, either with the certificate provided by the server or another certificate the client may get for this NTP server 🔒
then the receiver works out the time offset between itself and the chosen NTP server. the receiver doesn't need to actually update its local time (which often needs root privileges). computing the time offset is enough 🙌
since the offset between the server and the time reference, D^O_t, is indicated in the bootstrap information message (or communicated out-of-band), the receiver can now calculate an upper bound of the sender's local time (Section 2.4.2) 🧚
one thing to flag: this scenario assumes each client trusts the sender and is okay with aligning its NTP configuration to the sender's, using one of the suggested NTP servers. if that assumption does not hold, the client MUST NOT use the NTP indirect time synchronization method (Section 2.3.2) 🚨
4.3. Authentication of Received Packets ✨
okay bestie, now the receiver can finally check incoming packets (except for bootstrap info and direct time sync response packets) 💅 The receiver MUST follow different steps for this (see [RFC4082], Section 3.5) 🫶
- Parse the headers 🎀 The receiver parses the different packet headers. If none of the four TESLA authentication tags are there, the receiver MUST discard the packet 💀 If the session is in "Single Key Chain" mode (for example, when the "S" flag is set in the bootstrap information message), then the receiver MUST discard any packet with an Authentication Tag that has a New Key Chain Commitment or an Authentication Tag with a Last Key of Old Chain Disclosure 🙅♀️
- Safe packet test 🦋 When the receiver gets packet
P_j, it first records the local timeTwhen the packet arrived. Then it computes an upper boundt_jon the sender's clock at that moment:t_j = T + D_t. Next it works out the highest interval the sender could possibly be in:highest_i = floor((t_j - T_0) / T_int). It also grabs the "i" interval index from the authentication tag, and now it's time for the "safe packet" test ✨ Ifhighest_i < i + d, then the sender isn't in the interval where it discloses the keyK_iyet, so the packet is safe (but not necessarily authentic 👀). If the test fails, the packet is unsafe, and the receiver MUST discard the packet 🚫 - Group MAC test 🔐 If the optional Group MAC tag is there AND the session uses this feature, verify the Group MAC (Section 4.1.1). If the verification fails, the packet MUST be immediately dropped. A packet that doesn't have a Group MAC tag when the session uses this feature MUST be immediately dropped too. The opposite case is different: if a packet has a Group MAC tag but the session doesn't use the feature, that tag MUST be ignored 🌸
- Disclosed Key processing 🗝️ When the packet discloses a key (that is, with a Standard Authentication Tag, or with an Authentication Tag with a Last Key of Old Chain Disclosure), these tests happen:
- New key index test: the receiver checks whether a legitimate key already exists with the same index (
i-d). If one does, it compares that value with the current disclosed key. If they're identical, it skips the "Unverifiable key test" and "Key verification test" ⏭️ If a legitimate key exists but the values differ, the receiver MUST discard the packet 😭 - Unverifiable key test 🤷♀️ When the disclosed key index is new, there might be no earlier disclosed and legitimate key for this key chain, so the key can't be verified yet. This happens when the disclosed key belongs to the old key chain and no commitment to that old chain has ever been received (for example, because the first bootstrap packet a latecomer gets is for the current key chain, so it includes a commitment to the current chain and not the previous one). When this happens, the receiver MUST ignore the disclosed key (it's useless anyway) and skip the Key verification test 🙈
- Key verification test 🧮 If the disclosed key index is new and the key can be verified, the receiver checks that
K_{i-d}is legit. It does this by checking, for some earlier disclosed and legitimate keyK_v(withv < i-d), thatK_vandF^{i-d-v}(K_{i-d})are identical. Basically, it runs the necessary number of PRF functions to reach a previously disclosed, legitimate (aka verified) key ✨ If the key verification fails, the receiver MUST discard the packet 💔 If it succeeds, the key counts as legitimate, and it gets stored by the receiver along with all the keys between indexesvandi-d🎉
- New key index test: the receiver checks whether a legitimate key already exists with the same index (
- Congestion control 🚦 When it applies, the receiver does any congestion control related action (that is, the ALC or NORM headers get used by the associated congestion control building block, if there is one), even if the packet hasn't been authenticated yet [RFC5651]. If this feature leads to a potential DoS attack (an attacker can send a faked packet with a wrong sequence number to simulate packet losses), it doesn't compromise the security features TESLA offers, and it lets the receiver react quickly to real congestion problems 🏎️
- Buffer it 📦 The receiver then buffers the packet for later authentication, once the matching key gets disclosed (after
dtime intervals) or deduced from another key (if all the packets disclosing this key got lost). In some situations, this packet might also get discarded later, if it turns out the receiver will never be able to deduce the associated key 😢 - Authentication test 🥇 Let
vbe the smallest index of the legitimate keys the receiver knows about so far. For all the new keysK_w, withv < w <= i-d, that were either disclosed by this packet (that'sK_{i-d}) or derived fromK_{i-d}(the keys in the interval{v+1,.. i-d-1}), the receiver verifies the authenticity of the safe packets buffered for the matching intervalw. To authenticate one of the buffered packetsP_hcontaining messageM_hprotected with a MAC that used key indexw, the receiver computesK'_w = F'(K_w), which lets it computeMAC( K'_w, M_h). If this MAC doesn't equal the MAC stored in the packet, the receiver MUST discard the packet 🙅♀️ If the two MACs match, the packet is successfully authenticated and the receiver keeps processing it ✅ - New key chain commitment processing 📜 If the authenticated packet contains a new key chain commitment, and no verified commitment already exists, the receiver stores the commitment to the new key chain. Then, if there are non-authenticated packets for a previous chain (the key chain before the current one), all of those packets can be discarded (Section 4.4) 🗑️
- Keep going 🏃♀️ The receiver continues the ALC or NORM processing of all the packets authenticated during the authentication test 💖
In this spec, a receiver using TESLA MUST immediately drop unsafe packets 🚨 But the receiver MAY also decide, at any time, to keep running an ALC or NORM session in unsafe (insecure) mode, ignoring the TESLA extensions. There SHOULD be an explicit user action for that 🙋♀️
bestie, the unsafe mode thing is a big deal. Turning off TESLA is never something the session should just do on its own. There SHOULD be an explicit user action first 💅
4.3.1. Discarding Unnecessary Packets Earlier
Following the steps above strictly can lead to excessive processing overhead in certain situations 🥵 One example is when a receiver gets packets for an unwanted object with the ALC or NORM protocols, meaning an object the application (or the end user) explicitly said it isn't interested in. Another is when a receiver gets packets for an object that's already decoded, or, when the object has been split into several blocks, for a block that's already decoded. When a packet like this shows up (easy to spot by checking the receiver's status for the incoming ALC or NORM packet), the receiver MUST also check that the packet is a pure data packet with no signaling info that matters for the session 🔍
With ALC, a packet with an "A" flag ("Close Session") or a "B" flag ("Close Object") MUST NOT be discarded before it's been authenticated and processed normally 🛑 Otherwise, the receiver can safely discard the incoming packet, for instance right after step 1 of Section 4.3. This optimization can seriously cut down the processing overhead by skipping lots of useless authentication checks 🧹✨
4.4. Flushing the Non-Authenticated Packets of a Previous Key Chain
Sometimes a receiver that's been disconnected for a really long time might have lost all the disclosures of the last key(s) of a previous key chain 😩 Let j be the index of that key chain, the one that still has non-authenticated packets. This receiver can flush all the packets of key chain j if it determines that:
- it has just switched to a chain of index
j+2(inclusive) or higher; - the sender has sent a commitment to the new key chain of index
j+2(Section 3.1.2.3). This requires that the receiver has received a packet containing such a commitment AND that it has been able to check its integrity 🔐 In some cases, it might also require receiving a bootstrap information message for the current key chain.
If either of the two tests above succeeds, the sender can discard all the awaiting packets, since there's no way to authenticate them anymore 🧺💅
5. Integration in the ALC and NORM Protocols 🧚
5.1. Authentication Header Extension Format
Okay so, TESLA plugs into ALC or NORM in basically the same way, and both protocols use the header extension mechanism to make it happen 🦋 This document specifically details the EXT_AUTH==1 header extension from [RFC5651] ✨
A few fields get added on top of the "HET" (Header Extension Type) and "HEL" (Header Extension Length) fields, as shown in Figure 9 💖
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET (=1) | HEL | ASID | Type | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
~ ~
| Content |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 9: Format of the TESLA EXT_AUTH Header Extension
Here's what each field does 🌸
"ASID" (Authentication Scheme IDentifier) field (4 bits): The "ASID" tells you which source authentication scheme or protocol is in use. The mapping between the "ASID" value and the actual scheme is set up out-of-band, at session startup 🧚
"Type" field (4 bits): The "Type" field says what kind of TESLA info is riding along in this header extension. This spec defines these types:
- 0: Bootstrap information, sent by the sender periodically or after a direct time synchronization request;
- 1: Standard Authentication Tag for the ongoing key chain, sent by the sender along with a packet;
- 2: Authentication Tag without Key Disclosure, sent by the sender along with a packet;
- 3: Authentication Tag with a New Key Chain Commitment, sent by the sender when approaching the end of a key chain;
- 4: Authentication Tag with a Last Key of Old Chain Disclosure, sent by the sender some time after moving to a new key chain;
- 5: Direct time synchronization request, sent by a NORM receiver. This type of message is invalid in the case of an ALC session since ALC is restricted to unidirectional transmissions. Yet, an external mechanism may provide the direct time synchronization functionality;
- 6: Direct time synchronization response, sent by a NORM sender. This type of message is invalid in the case of an ALC session since ALC is restricted to unidirectional transmissions. Yet, an external mechanism may provide the direct time synchronization functionality.
"Content" field (variable length): This is the TESLA information carried in the header extension, and its type is whatever the "Type" field says 🎀
5.2. Use of Authentication Header Extensions
Okay this part is SO important 💅 Every packet the session's sender sends MUST contain exactly one TESLA EXT_AUTH Header Extension. No exceptions, bestie 🫶
All receivers MUST recognize EXT_AUTH, but they MAY not be able to parse its content, for instance because they don't support TESLA 😭 If that happens, these receivers MUST ignore the TESLA EXT_AUTH extensions. Just let it go. In the case of NORM, the packets sent by receivers MAY contain a direct synchronization request, but they MUST NOT contain any of the other five TESLA EXT_AUTH Header Extensions 🙈
5.2.1. EXT_AUTH Header Extension of Type Bootstrap Information
The "bootstrap information" TESLA EXT_AUTH (Type==0) MUST be sent in a stand-alone control packet, rather than in a packet containing application data. Why? Because bootstrap info is HUGE 🐘 By keeping it in stand-alone packets, the maximum payload size of data packets is only affected by the (mandatory) authentication information header extension. Smart, right? 🧠✨
With ALC, the "bootstrap information" TESLA EXT_AUTH MUST be sent in a control packet, i.e., one containing no encoding symbol.
With NORM, the "bootstrap information" TESLA EXT_AUTH MUST be sent in a NORM_CMD(APPLICATION) message.
Here's the layout, as shown in Figure 10 🍓
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
| HET (=1) | HEL (=46) | ASID | 0 | 0 | 0 |0|1|0| ^
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| d | 2 | 2 | 2 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| 1 | 3 | 128 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| 0 (reserved) | T_int | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | |
+ T_0 (NTP timestamp format) + | 5
| | | 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| N (Key Chain Length) | | b
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | y
| Current Interval Index i | | t
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | e
| | | s
+ + |
| | |
+ Current Key Chain Commitment + |
| (20 bytes) | |
+ + |
| | |
+ + |
| | v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
| | ^ 1
+ + | 2
| | | 8
. . |
. Signature . | b
. (128 bytes) . | y
| | | t
+ + | e
| | v s
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
| Group MAC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 10: Example: Format of the Bootstrap Information Message (Type 0) Using SHA-256/1024-Bit Signatures, the Default HMAC-SHA-256, and a Group MAC
So, Figure 10 is an example of the bootstrap message when you use the HMAC-SHA-256 transform for the PRF, MAC, and Group MAC functions, plus SHA-256/128 byte (1024 bit) key digital signatures. That also means the "Signature" field is 128 bytes long 🔐 The whole TESLA EXT_AUTH Header Extension ends up being 184 bytes long (i.e., 46 words of 32 bits). Main character length 💀✨
5.2.2. EXT_AUTH Header Extension of Type Authentication Tag
The four "authentication tag" TESLA EXT_AUTH Header Extensions (Type 1, 2, 3, and 4) MUST be attached to the ALC or NORM packet (data or control packet) that they protect 🦋 Protecting the packet they're attached to is their whole thing.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET (=1) | HEL (=10) | ASID | 1 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| i (Interval Index of K'_i) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Disclosed Key K_{i-d} +
| (20 bytes) |
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| MAC(K'_i, M) |
+ (16 bytes) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Example: Format of the Standard Authentication Tag
(Type 1) Using the Default HMAC-SHA-256
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET (=1) | HEL (=5) | ASID | 2 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| i (Interval Index of K'_i) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| MAC(K'_i, M) |
+ (16 bytes) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: Example: Format of the Authentication Tag without
Key Disclosure (Type 2) Using the Default HMAC-SHA-256For instance, Figures 11 and 12 show the format of the authentication tags, with and without the K_{i-d} key disclosure, when using the (default) HMAC-SHA-256 transform for the PRF and MAC functions. In these examples, the Group MAC feature is not used 🌈
5.2.3. EXT_AUTH Header Extension of Type Direct Time Synchronization Request
okay bestie 💖 so with NORM, the "direct time synchronization request" TESLA EXT_AUTH (Type==7) MUST be sent by a receiver in a NORM_CMD(APPLICATION) NORM packet 🎀
with ALC it's a whole different vibe ngl 🥺 the "direct time synchronization request" TESLA EXT_AUTH cannot be included in an ALC packet, because ALC only goes one way, from the session's sender to the receivers. so if you're using ALC, you need an external mechanism to carry direct time synchronization requests to the sender 🦋
and for direct time synchronization, it is RECOMMENDED that receivers spread out their requests over time (Section 2.3.1) 🕰️✨ no clumping, bestie!!
5.2.4. EXT_AUTH Header Extension of Type Direct Time Synchronization Response
with NORM, the "direct time synchronization response" TESLA EXT_AUTH (Type==8) MUST be sent by the sender in a NORM_CMD(APPLICATION) message 💜
with ALC, the response can go in an ALC control packet (so one with no encoding symbol in it) 🌸 or through that same external mechanism you used for the request. flexible, iconic 💅
6. Security Considerations 🔐
okay this section is serious but make it cute 🎀 [RFC4082] talks about the security of TESLA in general. these considerations apply to this spec too, namely:
- great care must be taken in the timing aspects. the D_t parameter is critical and must be correctly initialized 😭⏰
- if the sender realizes that the key disclosure schedule is not appropriate, then the current session MUST be closed and a new one created. no cap, this is a hard rule. Section 3.1.3 requires that these parameters be fixed during the whole session 🔒
- when the verifier that authenticates the incoming packets and the application that uses the data are two different components, there is a risk that an attacker sitting between them injects faked data 👀 same goes for when the verifier and the secure timing system are two different components: an attacker in the middle could inject faked timing info. for example, when the verifier reads the local time with a dedicated system call (like gettimeofday()), if an attacker controls the host, he may catch that system call and return faked time info 💀
the current specification goes into these aspects with more detail 🧚
6.1. Dealing with DoS Attacks 🚨
TESLA opens up new doors for attackers to mount DoS attacks, bestie 🙈 for instance, an attacker can try to saturate the receiver's processing capabilities. faked packets are super easy to make, but checking them means computing a MAC over the packet, or sometimes checking a digital signature (like with the bootstrap and direct time synchronization response messages). an attacker can also try to saturate the receiver's memory, since authentication is delayed and non-authenticated packets will pile up. or they can try to make the receiver think congestion has happened, since congestion control MUST be performed before authenticating incoming packets (Section 4.3) 📉
to mitigate these attacks, it is RECOMMENDED to use the Group MAC scheme (Section 3.3.3) ✨ but no mitigation is possible if a group member acts as an attacker with Group MAC, so careful with who's in the group 🫣
generally, it is RECOMMENDED that the amount of memory used to store incoming packets waiting to be authenticated be limited to a reasonable value 🍓
6.2. Dealing With Replay Attacks 🔁
replay attacks are when an attacker stores a valid message and replays it later. these can have big impacts depending on the message type 😤 two levels of impact need to be distinguished:
- within the TESLA protocol, and
- within the ALC or NORM protocol.
6.2.1. Impacts of Replay Attacks on TESLA 💫
replay attacks can impact the TESLA component itself. here's how the potential impact breaks down by TESLA message type:
- bootstrap information: most parameters in a bootstrap information message are static, so replay attacks have no consequences 🙌 the fact that the "i" and "K_i" fields can be updated in later bootstrap information messages doesn't cause a problem either, since all "i" and "K_i" fields sent remain valid. finally, a receiver that successfully initialized its TESLA component MUST ignore the following messages (see Section 4.2.1 for an exception to this rule), which voids replay attacks, unless he missed all the commitments to a new key chain (e.g., after a long disconnection) (Section 3.2.1) 🔥
- direct time synchronization request: if the Group MAC scheme is used, an attacker who is not a member of the group can replay a packet and force the sender to respond, which means digitally signing the response, and that's a time-consuming process 😩 if the Group MAC scheme is not used, an attacker can easily forge a request anyway. either way, the attack won't compromise the TESLA component, but it might create a DoS. if this is a concern, it is RECOMMENDED, when the Group MAC scheme is used, that the sender verify the
t_rNTP timestamp in the request and respond only if this value is strictly larger than the previous one received from this receiver 🧠 when the Group MAC scheme is not used, this attack can be mitigated by limiting the number of requests per second that get processed. - direct time synchronization response: when a receiver gets a response but has no pending request, that receiver MUST immediately drop the packet 🗑️ if this receiver has previously issued a request, they first check the Group MAC (if applicable), then the
t_rfield, to make sure it's a response to their request, and finally the digital signature. a replayed packet gets dropped during these checks, without compromising the TESLA component 💅 - other messages, containing an authentication tag: replaying a packet containing a TESLA authentication tag will never compromise the TESLA component itself (though it might affect the underlying ALC or NORM component, see below) 🌈
to wrap up, TESLA itself is robust against replay attacks 👑
6.2.2. Impacts of Replay Attacks on NORM 🌊
we're looking at the potential impact of a replay attack on the NORM component here. we're not considering the protocols that could be used alongside NORM, like the congestion control protocols 🙈
first, let's look at replay attacks within a single NORM session. NORM defines a sequence field that can protect against replay attacks [RFC5740] within a given NORM session. this sequence field is a 16-bit value, set by the message originator (sender or receiver), that is a monotonically increasing number incremented with each NORM message transmitted 🔢 it is RECOMMENDED that a receiver check this sequence field and drop messages considered replayed. similarly, it is RECOMMENDED that a sender check this sequence for each known receiver and drop messages considered replayed. in both cases, checking this sequence field SHOULD be done before TESLA processing of the packet. if the sequence field hasn't been corrupted, the replay attack gets caught immediately; otherwise, the packet fails the TESLA authentication test anyway 🫶 so NORM itself is robust against replay attacks within the same session.
now let's look at replay attacks across several NORM sessions. since the key chain used in each session MUST differ, a packet replayed in a later session will be identified as unauthentic 🙅♀️ therefore, NORM is robust against replay attacks across different sessions ✨
6.2.3. Impacts of Replay Attacks on ALC 🌸
here we review the potential impact of a replay attack on the ALC component. again, we're not considering the protocols that could be used alongside ALC, like the layered or wave-based congestion control protocols 🦋
first, let's look at replay attacks within a given ALC session:
- regular packets containing an authentication tag: a replayed message containing an encoding symbol will be detected once authenticated, thanks to the object/block/symbol identifiers, and it'll be silently discarded. this kind of replay attack is only annoying in terms of memory and processing load, but it doesn't compromise ALC behavior 🤷♀️
- control packets containing an authentication tag: ALC control packets, by definition, don't include any encoding symbol, so they don't carry any object/block/symbol identifier that would let a receiver spot duplicates 😬 but a sender has very few reasons to send control packets. more precisely:
- at the end of the session, a "Close Session" ("A" flag) packet is sent. replaying it has no impact, since the receivers already left 👋
- similarly, replaying a packet containing a "Close Object" ("B" flag) has no impact, since the receiver has probably already marked this object as closed 🙃
this analysis shows that ALC itself is robust against replay attacks within the same session 💖
now let's look at replay attacks across several ALC sessions. since the key chain used in each session MUST differ, a packet replayed in a later session will be identified as unauthentic 🔐 therefore, ALC is robust against replay attacks across different sessions 👑
6.3. Security of the Back Channel 📡
as specified in Section 1.1, this specification doesn't consider the packets that receivers may send, like NORM's feedback packets 🙃 when a back channel is used, its security is critical to overall security, and an appropriate security mechanism MUST be used. [RMT-SIMPLE-AUTH] describes several techniques that can be used for that purpose 🛡️ however, authentication and integrity verification of packets sent by receivers on the back channel (if there are any) is out of scope for this document 🫶
7. IANA Considerations 📋
okay so IANA already registered the attributes from this document 🦋 The registries live under [RFC4442] in the "Timed Efficient Stream Loss-tolerant Authentication (TESLA) Parameters" registry [TESLA-REG]. Following the policies from [RFC4442], values up to 240 (including 240) get assigned after expert review by the MSEC working group or its designated successor. Values from 241 to 255 are reserved for private use 🔒
Cryptographic Pseudo-Random Function, TESLA-PRF: All implementations MUST support HMAC-SHA-256 (default). ✨
+------------------------+-------+
| PRF name | Value |
+------------------------+-------+
| HMAC-SHA1 | 0 |
| HMAC-SHA-224 | 1 |
| HMAC-SHA-256 (default) | 2 |
| HMAC-SHA-384 | 3 |
| HMAC-SHA-512 | 4 |
+------------------------+-------+Cryptographic Message Authentication Code (MAC) Function, TESLA-MAC: All implementations MUST support HMAC-SHA-256 (default). These MAC schemes are used both for computing the regular MAC and the Group MAC (if applicable) 💅
+------------------------+-------+
| MAC name | Value |
+------------------------+-------+
| HMAC-SHA1 | 0 |
| HMAC-SHA-224 | 1 |
| HMAC-SHA-256 (default) | 2 |
| HMAC-SHA-384 | 3 |
| HMAC-SHA-512 | 4 |
+------------------------+-------+Then IANA made two brand new registries, and the same rules apply 🎀 Values up to 240 (including 240) are assigned after expert review by the MSEC working group or its designated successor, and values from 241 to 255 are reserved for private use. Iconic consistency 👑
Signature Encoding Algorithm, TESLA-SIG-ALGO: All implementations MUST support RSASSA-PKCS1-v1_5 (default). 🔥
+-----------------------------+-------+
| Signature Algorithm Name | Value |
+-----------------------------+-------+
| INVALID | 0 |
| RSASSA-PKCS1-v1_5 (default) | 1 |
| RSASSA-PSS | 2 |
+-----------------------------+-------+Signature Cryptographic Function, TESLA-SIG-CRYPTO-FUNC: All implementations MUST support SHA-256 (default). 🌈
+-----------------------------+-------+
| Cryptographic Function Name | Value |
+-----------------------------+-------+
| INVALID | 0 |
| SHA-1 | 1 |
| SHA-224 | 2 |
| SHA-256 (default) | 3 |
| SHA-384 | 4 |
| SHA-512 | 5 |
+-----------------------------+-------+8. Acknowledgments 🫶
The authors are so grateful to Yaron Sheffer, Brian Weis, Ramu Panayappan, Ran Canetti, David L. Mills, Brian Adamson, and Lionel Giraud for their valuable comments while they were preparing this document 💖 They also owe a special thank you to Brian Weis for the digital signature details 🍓
9. References 📚
9.1. Normative References
[RFC1305] Mills, D., "Network Time Protocol (Version 3)
Specification, Implementation", RFC 1305,
March 1992.
[RFC2119] Bradner, S., "Key words for use in RFCs to
Indicate Requirement Levels", BCP 14, RFC 2119,
March 1997.
[RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and
B. Briscoe, "Timed Efficient Stream Loss-Tolerant
Authentication (TESLA): Multicast Source
Authentication Transform Introduction", RFC 4082,
June 2005.
[RFC5651] Luby, M., Watson, M., and L. Vicisano, "Layered
Coding Transport (LCT) Building Block", RFC 5651,
October 2009.
[RFC5740] Adamson, B., Bormann, C., Handley, M., and J.
Macker, "NACK-Oriented Reliable Multicast (NORM)
Transport Protocol", RFC 5740, November 2009.
[RFC5775] Luby, M., Watson, M., and L. Vicisano,
"Asynchronous Layered Coding (ALC) Protocol
Instantiation", RFC 5775, April 2010.
[TESLA-REG] "TESLA Parameters IANA Registry",
http://www.iana.org.9.2. Informative References
[NTP-NTPv4] Burbank, J., Kasch, W., Martin, J., Ed., and D.
Mills, "The Network Time Protocol Version 4
Protocol And Algorithm Specification", Work
in Progress, October 2009.
[Perrig04] Perrig, A. and J. Tygar, "Secure Broadcast
Communication in Wired and Wireless Networks",
Kluwer Academic Publishers ISBN 0-7923-7650-1,
2004.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:
Keyed-Hashing for Message Authentication",
RFC 2104, February 1997.
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key
Cryptography Standards (PKCS) #1: RSA Cryptography
Specifications Version 2.1", RFC 3447,
February 2003.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E.,
and K. Norrman, "The Secure Real-time Transport
Protocol (SRTP)", RFC 3711, March 2004.
[RFC4330] Mills, D., "Simple Network Time Protocol (SNTP)
Version 4 for IPv4, IPv6 and OSI", RFC 4330,
January 2006.
[RFC4359] Weis, B., "The Use of RSA/SHA-1 Signatures within
Encapsulating Security Payload (ESP) and
Authentication Header (AH)", RFC 4359,
January 2006.
[RFC4383] Baugher, M. and E. Carrara, "The Use of Timed
Efficient Stream Loss-Tolerant Authentication
(TESLA) in the Secure Real-time Transport Protocol
(SRTP)", RFC 4383, February 2006.
[RFC4442] Fries, S. and H. Tschofenig, "Bootstrapping Timed
Efficient Stream Loss-Tolerant Authentication
(TESLA)", RFC 4442, March 2006.
[RMT-FLUTE] Paila, T., Walsh, R., Luby, M., Lehtonen, R., and
V. Roca, "FLUTE - File Delivery over
Unidirectional Transport", Work in Progress,
August 2009.
[RMT-SIMPLE-AUTH] Roca, V., "Simple Authentication Schemes for the
ALC and NORM Protocols", Work in Progress,
October 2009.Authors' Addresses 💌
Vincent Roca
INRIA
655, av. de l'Europe
Inovallee; Montbonnot
ST ISMIER cedex 38334
France
EMail: vincent.roca@inria.fr
URI: http://planete.inrialpes.fr/~roca/
Aurelien Francillon
INRIA
655, av. de l'Europe
Inovallee; Montbonnot
ST ISMIER cedex 38334
France
EMail: aurelien.francillon@inria.fr
URI: http://planete.inrialpes.fr/~francill/
Sebastien Faurite
INRIA
655, av. de l'Europe
Inovallee; Montbonnot
ST ISMIER cedex 38334
France
EMail: faurite@lcpc.fr📦 where this page comes from
- ietf: rfc5776 2010-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms