TOC 
MSECV. Roca
Internet-DraftA. Francillon
Intended status: ExperimentalS. Faurite
Expires: May 22, 2008INRIA
 November 19, 2007


Use of TESLA in the ALC and NORM Protocols
draft-ietf-msec-tesla-for-alc-norm-03.txt

Status of this Memo

By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on May 22, 2008.

Abstract

This document explains how to integrate the TESLA source authentication and packet integrity protocol to the ALC and NORM content delivery protocols. This document only considers the authentication/integrity of the packets generated by the session's sender.



Table of Contents

1.  Introduction
    1.1.  Conventions Used in this Document
    1.2.  Terminology and Notations
2.  Using TESLA with ALC and NORM
    2.1.  ALC and NORM Specificities that Impact TESLA
    2.2.  The Need for Secure Time Synchronization
        2.2.1.  Direct Time Synchronization
        2.2.2.  Indirect Time Synchronization
    2.3.  Bootstrapping TESLA
        2.3.1.  Bootstrapping TESLA with an Out-Of-Band Mechanism
        2.3.2.  Bootstrapping TESLA with an In-Band Mechanism
3.  Time Synchronization and Delay Bound Calculations
    3.1.  Delay Bound Calculation in Direct Time Synchronization Mode
    3.2.  Delay Bound Calculation in Indirect time Synchronization Mode
        3.2.1.  Single time reference
        3.2.2.  Multiple time references
4.  Sender Operations
    4.1.  TESLA Parameters
        4.1.1.  Time Intervals
        4.1.2.  Key Chains
        4.1.3.  Time Interval Schedule
        4.1.4.  Timing Parameters
    4.2.  TESLA Messages and Authentication Tags
        4.2.1.  Bootstrap Information
        4.2.2.  Direct Time Synchronization Response
        4.2.3.  Authentication Tag
        4.2.4.  Weak Group MAC Tag
        4.2.5.  Use of Digital Signatures
    4.3.  TESLA Messages and Authentication Tag Format
        4.3.1.  Bootstrap Information Format
        4.3.2.  Format of a Direct Time Synchronization Response
        4.3.3.  Format of a Standard Authentication Tag
        4.3.4.  Format of a Standard Authentication Tag Without Key Disclosure
        4.3.5.  Format of an Authentication Tag with a New Key Chain Commitment
        4.3.6.  Format of an Authentication Tag with an Old Chain Last Key Disclosure
        4.3.7.  Format of the Compact Authentication Tags
5.  Receiver Operations
    5.1.  Initialization of a Receiver
        5.1.1.  Processing the Bootstrap Information Message
        5.1.2.  Time Synchronization
    5.2.  Authentication of Received Packets
6.  Integration in the ALC and NORM Protocols
    6.1.  Authentication Header Extension Format
    6.2.  Use of Authentication Header Extensions
        6.2.1.  EXT_AUTH Header Extension of Type Bootstrap Information
        6.2.2.  EXT_AUTH Header Extension of Type Authentication Tag
        6.2.3.  EXT_AUTH Header Extension of Type Direct Time Synchronization Request
        6.2.4.  EXT_AUTH Header Extension of Type Direct Time Synchronization Response
    6.3.  Managing Silent Periods
7.  IANA Considerations
8.  Security Considerations
    8.1.  Dealing With DoS Attacks
    8.2.  Dealing With Replay Attacks
        8.2.1.  Impacts of Replay Attacks on TESLA
        8.2.2.  Impacts of Replay Attacks on NORM
        8.2.3.  Impacts of Replay Attacks on ALC
9.  Acknowledgments
10.  References
    10.1.  Normative References
    10.2.  Informative References
§  Authors' Addresses
§  Intellectual Property and Copyright Statements




 TOC 

1.  Introduction

Many applications using multicast and broadcast communications require that each receiver be able to authenticate the source of any packet it receives as well as its integrity. For instance, ALC [draft‑ietf‑rmt‑pi‑alc‑revised] (Luby, M., Watson, M., and L. Vicisano, “Asynchronous Layered Coding (ALC) Protocol Instantiation,” November 2007.) and NORM [draft‑ietf‑rmt‑pi‑norm‑revised] (Adamson, B., Bormann, C., Handley, M., and J. Macker, “Negative-acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Protocol,” March 2007.) are two Content Delivery Protocols (CDP) designed to transfer reliably objects (e.g. files) between a session's sender and several receivers.

The NORM protocol is based on bidirectional transmissions. Each receiver acknowledges data received or, in case of packet erasures, asks for retransmissions. The ALC protocol defines unidirectional transmissions. Reliability can be achieved by means of cyclic transmissions of the content within a carousel, or by the use of proactive Forward Error Correction codes (FEC), or by the joint use of these mechanisms. Being purely unidirectional, ALC is massively scalable, while NORM is intrinsically limited in terms of the number of receivers that can be handled in a session. Both protocols have in common the fact that they operate at application level, on top of an erasure channel (e.g. the Internet) where packets can be lost (erased) during the transmission. With some use case, an attacker might impersonate the ALC or NORM session's sender and inject forged packets to the receivers, thereby corrupting the objects reconstructed by the receivers.

The situation is much more complex in case of group communications than it is with unicast communications. Indeed, in the latter case a simple solution exist: the sender and receiver can share a secret key to compute a Message Authentication Code (MAC) of all messages exchanged. This is no longer feasible in case of a multicast and broadcast communications since sharing a group key between the sender and all receivers and using the same MAC scheme means that any group member can impersonate the sender and send forged messages to other receivers.

The usual solution to provide the source authentication and message integrity services in case of multicast and broadcast communications consists in relying on asymmetric cryptography and using digital signatures. Yet this solution is limited by high computational costs and high transmission overheads. The Timed Efficient Stream Loss-tolerant Authentication protocol (TESLA) is an alternative solution that provides the two required services, while being compatible with high rate transmissions over lossy channels.

This document explains how to integrate the TESLA source authentication and packet integrity protocol to the ALC and NORM content delivery protocols. Since the FLUTE application [RFC3926] (Paila, T., Luby, M., Lehtonen, R., Roca, V., and R. Walsh, “FLUTE - File Delivery over Unidirectional Transport,” October 2004.) is built on top of ALC, it will directly benefit from the services offered by TESLA at the transport layer.

This specification only considers the authentication/integrity of the packets generated by the session's sender. This specification does not consider the packets that will be generated by receivers, for instance the feedback packets of NORM. Adding authentication/integrity to the packets sent by receivers is outside the scope of this document. Of course, this remark does not apply to ALC where transmissions are purely unidirectional.

For more information on the TESLA protocol and its principles, please refer to [RFC4082] (Perrig, A., Song, D., Canetti, R., Tygar, J., and B. Briscoe, “Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction,” June 2005.)[Perrig04] (Perrig, A. and J. Tygar, “Secure Broadcast Communication in Wired and Wireless Networks,” 2004.). For more information on ALC, NORM and FLUTE, please refer to [draft‑ietf‑rmt‑pi‑alc‑revised] (Luby, M., Watson, M., and L. Vicisano, “Asynchronous Layered Coding (ALC) Protocol Instantiation,” November 2007.), [draft‑ietf‑rmt‑bb‑lct‑revised] (Luby, M., Watson, M., and L. Vicisano, “Layered Coding Transport (LCT) Building Block,” November 2007.), [draft‑ietf‑rmt‑pi‑norm‑revised] (Adamson, B., Bormann, C., Handley, M., and J. Macker, “Negative-acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Protocol,” March 2007.) and [RFC3926] (Paila, T., Luby, M., Lehtonen, R., Roca, V., and R. Walsh, “FLUTE - File Delivery over Unidirectional Transport,” October 2004.).



 TOC 

1.1.  Conventions Used in this Document

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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).



 TOC 

1.2.  Terminology and Notations

The following notations and definitions are used throughout this document. Cryptographic functions related notations and definitions [RFC4082] (Perrig, A., Song, D., Canetti, R., Tygar, J., and B. Briscoe, “Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction,” June 2005.)[RFC4383] (Baugher, M. and E. Carrara, “The Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Secure Real-time Transport Protocol (SRTP),” February 2006.):

Time related notations and definitions:



 TOC 

2.  Using TESLA with ALC and NORM



 TOC 

2.1.  ALC and NORM Specificities that Impact TESLA

The ALC and NORM protocols have features and requirements that largely impact the way TESLA can be used.

In case of ALC:

Depending on the use case, some of the above features may not apply. For instance ALC can also be used over a bidirectional channel, or ALC can be used for small groups.

In case of NORM:



 TOC 

2.2.  The Need for Secure Time Synchronization

The security offered by TESLA relies heavily on time. Therefore the session's sender and each receiver need to be time synchronized in a secure way. To that purpose, two general methods exist:



 TOC 

2.2.1.  Direct Time Synchronization

When direct time synchronization is used, each receiver asks the sender for a time synchronization. To that purpose, a receiver sends a "Direct Time Synchronization Request" (Section 5.1.2.1 (Direct Time Synchronization)). The sender then directly answers to each request with a "Direct Time Synchronization Response" (Section 4.3.2 (Format of a Direct Time Synchronization Response)), signing this reply. Upon receiving this response, a receiver first verifies the signature, and then calculates an upper bound of the lag of his clock with respect to the clock of the sender, D_t. The details on how to calculate D_t are given in Section 3.1 (Delay Bound Calculation in Direct Time Synchronization Mode).

This synchronization method is both simple and secure. Yet there are two potential issues:

Relying on direct time synchronization is not expected to be an issue with NORM since (1) bidirectional communications already take place, and (2) NORM scalability is anyway limited. Yet it can be required that a mechanism, that is out of the scope of this document, be used to spread the transmission of "Direct time synchronization request" messages over the time if there is a risk that the sender may collapse.

But direct time synchronization is potentially incompatible with ALC since (1) there might not be a back channel to the session's sender, and (2) there are potentially a huge number of receivers and therefore a risk that the sender collapses.



 TOC 

2.2.2.  Indirect Time Synchronization

When indirect time synchronization is used, the sender and each receiver must synchronize securely via an external time reference. Several possibilities exist:

A bidirectional channel is required by the NTP/SNTP schemes. On the opposite, with the GPS/Galileo and high precision clock schemes, no such assumption is made. In situations where ALC is used on purely unidirectional transport channels (Section 2.1 (ALC and NORM Specificities that Impact TESLA)), using the NTP/SNTP schemes is not possible. Another aspect is the scalability requirement of ALC, and to a lesser extent of NORM. From this point of view, the above mechanisms usually do not raise any problem, unlike the direct time synchronization schemes. Therefore, using indirect time synchronization is a good candidate, in particular with ALC.

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 given in Section 3.2 (Delay Bound Calculation in Indirect time Synchronization Mode).



 TOC 

2.3.  Bootstrapping TESLA

In order to initialize the TESLA component at a receiver, the sender must communicate some key information. This information MUST be communicated in a secure way so that a receiver can check the source of the information and its integrity. Two general methods are possible:

The current specification does not recommend any mechanism to bootstrap TESLA. Choosing between an in-band and out-of-band scheme is left to the implementer, depending on the target use-case.



 TOC 

2.3.1.  Bootstrapping TESLA with an Out-Of-Band Mechanism

For instance [RFC4442] (Fries, S. and H. Tschofenig, “Bootstrapping Timed Efficient Stream Loss-Tolerant Authentication (TESLA),” March 2006.) describes the use of 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. Other solutions, for instance based on an extended session description, are possible, on condition these solutions are secure.



 TOC 

2.3.2.  Bootstrapping TESLA with an In-Band Mechanism

This specification describes an in-band mechanism. In some use-cases, it might be desired that bootstrap take place without requiring the use of an additional external mechanism. For instance each device may feature a clock with a known time-drift that is negligible in front of the time accuracy required by TESLA, and each device may embed the public key of the sender. It is also possible that the use-case does not feature a bidirectional channel which prevents the use of out-of-band protocols like MIKEY. For these two examples, the bootstrap information described in Section 4.3.1 (Bootstrap Information Format) and the knowledge of a few additional parameters, listed below, are sufficient to bootstrap TESLA at a receiver.

Some parameters cannot be communicated in-band. In particular, the sender or a group controller:

These parameters are communicated to all receivers before they can bootstrap their TESLA component. For instance it can be communicated as part of the session description, or initialized in a static way on the receivers.



 TOC 

3.  Time Synchronization and Delay Bound Calculations



 TOC 

3.1.  Delay Bound Calculation in Direct Time Synchronization Mode

In direct time synchronization mode, synchronization between a receiver and the sender follows the following protocol [RFC4082] (Perrig, A., Song, D., Canetti, R., Tygar, J., and B. Briscoe, “Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction,” June 2005.):

After this initial synchronization, at any point throughout the session, the receiver knows that: T_s < T_r + D_t, where T_s is the current time at the sender and T_r is the current time at the receiver.



 TOC 

3.2.  Delay Bound Calculation in Indirect time Synchronization Mode

In indirect time synchronization, the sender and the receivers must synchronize indirectly with one or several time references.



 TOC 

3.2.1.  Single time reference

Let's assume that there is a single time reference.

  1. The sender calculates D^O_t, the upper bound of the lag of the sender's clock with respect to the time reference. This D^O_t value is then be communicated to the receivers (Section 4.2.1 (Bootstrap Information)).
  2. Similarly, a receiver R calculates D^R_t, the upper bound of the lag of the receiver's clock with respect to the time reference.
  3. Then, for receiver R, the overall upper bound of the lag of the receiver's clock with respect to the clock of the sender, D_t, is the sum: D_t = D^O_t + D^R_t.

The D^O_t and D^R_t calculation depends on the time synchronization mechanism used (Section 2.2.2 (Indirect Time Synchronization)). In some cases, the synchronization scheme specifications provide these values. In other cases, these parameters can be calculated by means of a scheme similar to the one specified in Section 3.1 (Delay Bound Calculation in Direct Time Synchronization Mode), for instance when synchronization is achieved via a group controller [RFC4082] (Perrig, A., Song, D., Canetti, R., Tygar, J., and B. Briscoe, “Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction,” June 2005.).



 TOC 

3.2.2.  Multiple time references

Let's now assume that there are several time references (e.g. several (S)NTP servers). The sender and receivers use the direct time synchronization scheme to synchronize with the various time references. It results in D^O_t and D^R_t. Let D_err be an upper bound of the time error between all the time references. Then, the overall value of D_t within receiver R is set to the sum: D_t = D^O_t + D^R_t + D_err.

In some cases, the D_t value is part of the time synchronization scheme specifications. For instance NTPv3 [RFC1305] (Mills, D., “Network Time Protocol (Version 3) Specification, Implementation,” March 1992.) 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". In practice, depending on the NTP server stratum, the accuracy might be a little bit worse. In that case, D_t = security_factor * (1ms + 1ms), where the security_factor is meant to compensate several sources of inaccuracy in NTP.

----- Editor's note: is this D_t = security_factor * (1ms + 1ms) rule of thumb acceptable? -----



 TOC 

4.  Sender Operations



 TOC 

4.1.  TESLA Parameters



 TOC 

4.1.1.  Time Intervals

The sender divides the time into uniform intervals of duration T_int. Time interval numbering starts at 0 and is incremented consecutively. The interval index MUST be stored in an unsigned 32 bit integer so that wrapping to 0 takes place only after 2^^32 intervals. For instance, if T_int is equal to 0.5 seconds, then wrapping takes place after approximately 68 years.



 TOC 

4.1.2.  Key Chains

The sender computes a one-way key chain of n_c = K+1 keys, and assigns one key from the chain to each interval in sequence. Key numbering starts at 0 and is incremented consecutively, following the time interval numbering: K_0, K_1 .. K_N.

In order to compute this chain, the sender must first select a Primary Key, K_N, and a PRF function, f. The functions F and F' are two one-way functions that are defined as: F(k)=f_k(0) and F'(k)=f_k(1). The sender computes all the keys of key chain, starting with K_N, using: K_{i-1} = F(K_i). The key for MAC calculation can then be derived from the corresponding K_i key by K'_i=F'(K_i). The randomness of the Primary Key, K_N, is vital to the security since no one should be able to guess it.

The key chain has a finite length, N, so the TESLA session must finish before the end of the key chain. But the longer the key chain, the higher the memory and computation required to cope with it. Another solution consists in switching to a new key chain, of the same length, when necessary (see Figure 1 (Switching to a new key chain (d=2, n_tx_newkcc=3, n_tx_lastkey=3, switching between the first and second key chains).)) [Perrig04] (Perrig, A. and J. Tygar, “Secure Broadcast Communication in Wired and Wireless Networks,” 2004.).



< -------- 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
(in parallel):      the new chain)  ||               the old chain)
 Figure 1: Switching to a new key chain (d=2, n_tx_newkcc=3, n_tx_lastkey=3, switching between the first and second key chains). 

To do so, the sender commits the new key chain with the old key chain. Let's say that the old key chain stops at K_N and the new key chain starts at K_{N+1} (i.e., F(K_{N+1}) and K_N are two different keys). Then the sender includes the commitment F(K_{N+1}) to the new key chain to packets authenticated with the old key chain (see Section 4.3.5 (Format of an Authentication Tag with a New Key Chain Commitment)). This commitment SHOULD be sent during n_tx_newkcc intervals before the end of the old key chain. Since several packets are usually sent during an interval, the sender SHOULD alternate between sending a disclosed key of the old key chain and the commitment to the new key chain. The details of how to alternate between the disclosure and commitment are out of the scope of this document.

The receiver will keep the commitment until the key K_{N+1} is disclosed, at interval N+1+d. Then the receiver will be able to test the validity of that key by computing F(K_{N+1}) and comparing it to the commitment.

When the key chain is changed, it becomes impossible to recover a previous key from the old key chain. This is a problem if the receiver lost the packets disclosing the last key of the old key chain. A solution consists in re-sending the last key, K_N, of the old key chain (see Section 4.3.6 (Format of an Authentication Tag with an Old Chain Last Key Disclosure)). This SHOULD be done during n_tx_lastkey additional intervals after the end of the time interval where K_N is disclosed. Since several packets are usually sent during a interval, the sender SHOULD alternate between sending a disclosed key of the new key chain, and the last key of the old key chain. The details of how to alternate between the two disclosures are out of the scope of this document.

In some cases a receiver having experienced a very long disconnection might have lost the commitment of the new chain. Therefore this receiver will not be able to authenticate any packet related to the new chain and all the following ones. The solution for this receiver to catch up consists in receiving the bootstrap information. This can happen by waiting for the next periodic transmission (in indirect time synchronization mode), by requesting it (in direct time synchronization mode), or through an external mechanism (Section 4.2.1 (Bootstrap Information)).

Since a key cannot be disclosed before the disclose delay, d, no key will be disclosed during the first d time intervals (intervals 0 and 1 in Figure 1 (Switching to a new key chain (d=2, n_tx_newkcc=3, n_tx_lastkey=3, switching between the first and second key chains).)) of the session. The following key chains, if any, are not concerned.



 TOC 

4.1.3.  Time Interval Schedule

The sender must determine the following parameters:

The correct choice of T_int, d, and N is crucial for the efficiency of the scheme. For instance, a T_int * d product that is too long will cause excessive delay in the authentication process. A T_int * d product that is too short will cause too many packets to be unverifiable by some receivers. A N * T_int product that is too small will cause the sender to switch too often to new key chains. A N that is too long with respect to the expected session duration, if this latter is known, will require the sender to compute too many keys without using them all. [RFC4082] (Perrig, A., Song, D., Canetti, R., Tygar, J., and B. Briscoe, “Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction,” June 2005.) sections 3.2 and 3.6 give general guidelines for initializing these parameters.

The T_0, T_int, d and N parameters MUST NOT be changed during the lifetime of the session. This restriction is meant to prevent introducing vulnerabilities: for instance, if a sender is authorized to change the key disclosure schedule, a receiver that did not receive the notification of change would still believe in the old key disclosure schedule [RFC4082] (Perrig, A., Song, D., Canetti, R., Tygar, J., and B. Briscoe, “Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction,” June 2005.).



 TOC 

4.1.4.  Timing Parameters

In indirect time synchronization mode, the sender must determine the following parameter:

The D^O_t parameter MUST NOT be changed during the lifetime of the session.



 TOC 

4.2.  TESLA Messages and Authentication Tags

At a sender, TESLA produces four types of signaling information:



 TOC 

4.2.1.  Bootstrap Information

In order to initialize the TESLA component at a receiver, the sender must communicate some key information in a secure way. This information can be sent in-band or out-of-band, as discussed in Section 2.3 (Bootstrapping TESLA). Choosing between an in-band and out-of-band scheme is left to the implementer, depending on the target use-case. In this section we only consider the in-band scheme.

The TESLA bootstrap information message MUST be digitally signed (Section 4.2.5 (Use of Digital Signatures)). The goal is to enable a receiver to check the packet source and packet integrity. Then, the bootstrap information can be:

Let's consider situations where the bootstrap information is broadcast. This message should be broadcast at the beginning of the session, before data packets are actually sent. This is particularly important with ALC or NORM sessions in ``push'' mode, when all clients join the session in advance. For improved reliability, bootstrap information might be sent a certain number of times.

Afterward, a periodic broadcast of the bootstrap information message could be useful when:

A balance must be found between the signaling overhead and the maximum initial waiting time at the receiver before starting the delayed authentication process. A frequency of a few seconds for the transmission of this bootstrap information is often a reasonable value.



 TOC 

4.2.2.  Direct Time Synchronization Response

In Direct Time Synchronization, upon receipt of a synchronization request, the sender records its local time, t_s, and sends a response message that contains both t_r and t_s (Section 3.1 (Delay Bound Calculation in Direct Time Synchronization Mode)). This message is unicast to the receiver. This Direct Time Synchronization Response message MUST be digitally signed in order to enable a receiver to check the packet source and packet integrity (Section 4.2.5 (Use of Digital Signatures)). The receiver MUST also be able the associate this response and his request, which is the reason why t_r is included in the message.

The Direct Time Synchronization Response messages are distinct from the Bootstrap Information message (assuming in-band bootstrap is used). Therefore, if a large number of receivers try to initialize their TESLA component at the same time (a reasonable assumption in "push" mode), a single Bootstrap Information message can be broadcast to all of them. In some situations, when there is a limited number of receivers, a sender can also choose to unicast a Bootstrap Information message to each client individually before sending the direct time synchronization response message. The choice is outside the scope of this document.

Note that a single session might include receivers that use the direct time synchronization mode while others use the indirect time synchronization mode.



 TOC 

4.2.3.  Authentication Tag

Every packet MUST have an authentication tag containing:

The computation of MAC(K'_i, M), includes the ALC or NORM header (with the various header extensions) and the payload when applicable. The UDP/IP/MAC headers are not included. During this computation, the MAC(K'_i, M) field of the authentication tag MUST be set to 0.



 TOC 

4.2.4.  Weak Group MAC Tag

An optional Weak Group MAC can be used to mitigate DoS attacks coming from attackers that are not group member [RFC4082] (Perrig, A., Song, D., Canetti, R., Tygar, J., and B. Briscoe, “Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction,” June 2005.). This feature assumes that a group key, K_g, is shared by the sender and all receivers. When the attacker is not a group member, the benefits of adding a group MAC to every packet sent are threefold:

More specifically, before sending a message, the sender computes the group MAC MAC(K_g, M), which includes the ALC or NORM header (with the various header extensions), plus the payload when applicable. During this computation, the Weak Group MAC field MUST be set to 0. However the digital signature and MAC fields, when present, MUST have been calculated and are included in the Weak 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 TESLA Authentication header. Upon receiving this packet, the receiver recomputes the group MAC and compares it to the value carried in the packet. If the check fails, the packet MUST be immediately dropped.

This scheme features a few limits:

For a given use-case, the benefits brought by the group MAC must be balanced against these limitations.

Note that the Weak 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.



 TOC 

4.2.5.  Use of Digital Signatures

The Bootstrap Information message (with the in-band bootstrap scheme) and Direct Time Synchronization Response message (with the indirect time synchronization scheme, either with in-band or out-of-band bootstrap) both need to be signed by the sender. Within these two messages, a "Signature" field is reserved to hold the result of the digital signature. The bootstrap information message also contains the "Signature Type" and "Signature Length" fields that enable a receiver to process the "Signature" field. There is no such "Signature Type" and "Signature Length" fields in case of a Direct Time Synchronization Response message since it is assumed that these parameters are already known (i.e. the receiver either received a bootstrap information message before, or these values have been communicated out-of-band).

The computation of the signature includes the ALC or NORM header (with the various header extensions) and the payload when applicable. The UDP/IP/MAC headers are not included. During this computation, the "Signature" field MUST be set to 0.

It is assumed in this document that the receivers have the possibility to retrieve the sender's public key required to check this digital signature and the sender's certificate if needed (Section 2.3 (Bootstrapping TESLA)). The details of how to do that are out of the scope of this document.

With RSASSA-PKCS1-v1_5 (default) and RSASSA-PSS signatures (Section 7 (IANA Considerations)), the size of the signature is equal to the "RSA modulus", unless the "RSA modulus" is not a multiple of 8 bits. In that case, the signature MUST be prepended with between 1 and 7 bits set to zero such that the signature is a multiple of 8 bits [RFC4359] (Weis, B., “The Use of RSA/SHA-1 Signatures within Encapsulating Security Payload (ESP) and Authentication Header (AH),” January 2006.). The key size, which in practice is also equal to the "RSA modulus", has major security implications. [RFC4359] (Weis, B., “The Use of RSA/SHA-1 Signatures within Encapsulating Security Payload (ESP) and Authentication Header (AH),” January 2006.) explains how to choose this value depending on the maximum expected lifetime of the session. This choice is out of the scope of this document.



 TOC 

4.3.  TESLA Messages and Authentication Tag Format

This section specifies the format of the various kinds of TESLA messages and authentication tags sent by the session's sender. Because of the ALC and NORM integration of these TESLA messages in an EXT_AUTH header extension (Section 6 (Integration in the ALC and NORM Protocols)), the following formats are not aligned on 32 bit word boundaries.



 TOC 

4.3.1.  Bootstrap Information Format

When bootstrap information is sent in-band, the following message is used:


  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 |W|A|  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  | f
 |    PRF Type   | MAC Func Type |SigType|    Signature Length   |  | i
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  | x
 |WG MAC Fun Type|      d        |             T_int             |  | e
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  | d
 |                                                               |  |
 +                      T_0 (NTP timestamp)                      +  | l
 |                                                               |  | e
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  | n
 |                  N (Number of Keys in chain)                  |  | g
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  | t
 |                   i (Interval Index of K_i)                   |  | h
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  v
 |                                                               |
 ~                              K_i              +-+-+-+-+-+-+-+-+
 |                                               |   Padding     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 +                                                               +
 ~                           Signature                           ~
 +                                               +-+-+-+-+-+-+-+-+
 |                                               |    Padding    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |P|                                                             |
 +-+       D^O_t Extension (optional, present if A==1)           +
 |    (NTP timestamp diff, positive if P==1, negative if P==0)   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 ~                   Weak Group MAC (optional)                   ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Figure 2: Bootstrap information format. 

The format of the bootstrap information is depicted in Figure 2 (Bootstrap information format.). The fields are:

"Reserved" fields (6 bits):

This is a reserved field that MUST be set to zero in this specification.

"W" (Weak Group MAC Present) flag (1 bits):

The "W" flag indicates whether the Weak Group MAC feature is used (W==1) or not (W==0). When it is used, a "Weak Group MAC" field is added to all the packets containing a TESLA EXT_AUTH Header Extension (including this bootstrap message).

"A" flag (1 bit):

A==0 indicates that the P flag and D^O_t field are not present. A==1 indicates that the P flag and D^O_t field are present (which is required in. indirect time synchronization mode).

"PRF Type" field (8 bits):

"PRF Type" is the reference number of the f function used to derive the F (for key chain) and F' (for MAC keys) functions (Section 7 (IANA Considerations)).

"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 (IANA Considerations)).

"Signature Type" field (4 bits):

The "Signature Type" is the reference number (Section 7 (IANA Considerations)) of the digital signature used to authenticate this bootstrap information and included in the "Signature" field.

"Signature Key Length" field (12 bits):

The "Signature Length" is an unsigned integer that indicates the signature field size in bytes in the "Signature Extension" field.

"Weak Group MAC Function Type" field (8 bits):

When W==1, the "Weak Group MAC Function Type" fields contains the reference number of the function used to compute the group MAC (Section 7 (IANA Considerations)) of the packets, including this bootstrap message. When W==0, this field MUST be set to zero (i.e. denote an INVALID MAC function Section 7 (IANA Considerations)).

"d" field (8 bits):

d is an unsigned integer that defines the key disclosure delay (in number of intervals). d MUST be greater or equal to 2.

"T_int" field (16 bits):

T_int is an unsigned 16 bit integer that defines the interval duration (in milliseconds).

"T_0" field (64 bits):

"T_0" is an NTP timestamp that indicates the time when this session began.

"N" field (32 bits):

"N" is an unsigned integer that indicates the number of keys in the current key chain.

"i" (Interval Index of K_i) field (32 bits):

"i" is an unsigned integer that indicates the interval index associated to the key disclosed in this bootstrap information, K_i. For performance reasons, the sender SHOULD always send a bootstrap information with the highest possible index i since this will reduce the required computation needed to validate key K_j with j > i. But using the first interval index of the current key chain (e.g. O and K_0 in case of the first key chain, N+1 and K_N+1 in case of the second key chain, etc.) is valid. In any case, if j is the current interval index, then it is REQUIRED that i ≤ j - d.

"K_i" field (variable size):

"K_i" is the key corresponding to interval i. If j is the current interval index, then it is REQUIRED that i ≤ j - d. If need be, this field is padded (with 0) up to a multiple of 32 bits.

"Signature" field (variable size):

The "Signature" field is mandatory. The signature field contains a digital signature using the type specified in the "Signature Type" field. If need be, this field is padded (with 0) up to a multiple of 32 bits.

"P" flag (optional, 1 bit if present):

The "P" flag is optional. It is only used in indirect time synchronization mode when the A flag is 1. This flag indicates 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 (controlled by the A flag). It is only used in indirect time synchronization mode. It is the upper bound of the lag of the sender's clock with respect to the time reference. When several time references are specified (e.g. several NTP servers), then D^O_t is the maximum upper bound of the lag with each time reference. D^O_t is composed of two unsigned integers, as with NTP timestamps: the first 31 bits give the time difference in seconds and the remaining 32 bits give the sub-second time difference.

"Weak Group MAC" field (optional, variable length, multiple of 32 bits):

This field contains the weak 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 the first byte and the following six 32-bit words are mandatory fixed length fields. The K_i and Signature fields are mandatory but variable length fields. The remaining D^O_t and Weak Group MAC fields are optional.

In order to prevent attacks, some parameters MUST NOT be changed during the lifetime of the session (Section 4.1.3 (Time Interval Schedule), Section 4.1.4 (Timing Parameters)). The following table summarizes the parameters status:

ParameterStatus
W 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 Type static (during whole session)
Weak 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
Weak Group MAC (if present) dynamic, packet dependent

Note that because a key cannot be disclosed before the disclose delay, d, the sender MUST NOT send any bootstrap information message during the first d intervals: {0 .. d-1} (inclusive).



 TOC 

4.3.2.  Format of a Direct Time Synchronization Response



  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    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 ~                   Weak Group MAC (optional)                   ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Figure 3: Format of a Direct Time Synchronization Response 

The response to a direct time synchronization request contains the following information:

"Reserved" fields (8 bits):

This is a reserved field that MUST be set to zero in this specification.

"t_s" (NTP timestamp, 64 bits):

t_s is an NTP timestamp that corresponds to the sender local time value when receiving the direct time synchronization request message.

"t_r" (NTP timestamp, 64 bits):

t_r is an NTP timestamp that contains the receiver local time value received in the direct time synchronization request message.

"Signature" field (variable size):

The "Signature" field is MANDATORY. The "Signature" field contains a digital signature using the type specified either in the "Signature Type" field of the bootstrap information message (if applicable) or out-of-band. Similarly the "Signature" field length is either indicated in the "Signature Length" field of the the bootstrap information message (if applicable) or out-of-band. If need be, this field is padded (with 0) up to a multiple of 32 bits.

"Weak Group MAC" field (optional, variable length, multiple of 32 bits):

This field contains the weak MAC, calculated with a group key, K_g, shared by all group members. The field length is given by n_w, in bits.



 TOC 

4.3.3.  Format of a Standard Authentication Tag



  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     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 ~                   Weak Group MAC (optional)                   ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Figure 4: Format of the authentication tag 

Figure 4 (Format of the authentication tag) shows the format of the authentication tag:

"Reserved" field (8 bits):

The "Reserved" field is not used in the current specification and MUST be set to zero by the sender.

"i" (Interval Index) field (32 bits):

i is the interval index associated to the key (K'_i) used to compute the MAC of this packet.

"Disclosed Key" (variable size):

The "Disclosed Key" is the key used for interval i-d: K_{i-d}; Note that during the first d time intervals of a session, this field must be initialized to "0" since no key can be disclosed yet.

"MAC(K'_i, M)" (variable size):

MAC(K'_i, M) is the message authentication code of the current packet. There is no padding between the "Disclosed Key" and "MAC(K'_i, M)" fields, and this latter MAY not be aligned on 32 bit boundaries, depending on the n_p parameter.

"Weak Group MAC" field (optional, variable length, multiple of 32 bits):

This field contains the weak 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 cannot be disclosed before the disclose delay, d, the sender MUST either set the Disclosed Key field to 0 during the first d intervals: {0 .. d-1} (inclusive), or use a Standard Authentication Tag Without Key Disclosure.



 TOC 

4.3.4.  Format of a Standard Authentication Tag Without Key Disclosure

The authentication tag without key disclosure is meant to be used in situations where a high number of packets are sent in a given time interval. In such a case, it can be advantageous to disclose the K_{i-d} key only in a subset of the packets sent, using a standard authentication tag, and use the shortened version that does not disclose the K_{i-d} key in the remaining packets. It is left to the implementer to decide how many packets should disclose the K_{i-d} key or not.



  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     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 ~                   Weak Group MAC (optional)                   ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Figure 5: Format of the authentication tag without key disclosure 



 TOC 

4.3.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 a commitment to the next key chain. This is done by replacing the disclosed key of the authentication tag with the new key chain commitment, F(K_{N+1}) (or F(K_{2N+2}) in case of a switch between the second and third key chains, etc.). Figure 6 (Format of the authentication tag with a new key chain commitment) shows the corresponding format.



  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     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 ~                   Weak Group MAC (optional)                   ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Figure 6: Format of the authentication tag with a new key chain commitment 



 TOC 

4.3.6.  Format of an Authentication Tag with an Old Chain Last Key Disclosure

During the first n_tx_lastkey intervals of the new key chain after the disclosing interval, d, the sender MUST send a commitment to the old key chain. This is done by replacing the disclosed key of the authentication tag with the last key of the old chain, K_N (or K_{2N+1} in case of a switch between the second and third key chains, etc.). Figure 7 (Format of the authentication tag with an old chain last key disclosure) shows the corresponding format. There is no padding between the "K_N" and "MAC(K'_i, M)" fields, and this latter MAY not be aligned on 32 bit boundaries, depending on the n_p parameter.



  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     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 ~                   Weak Group MAC (optional)                   ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Figure 7: Format of the authentication tag with an old chain last key disclosure 



 TOC 

4.3.7.  Format of the Compact Authentication Tags

The four compact flavors of the Authentication tags follow.



  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
                                                 +-+-+-+-+-+-+-+-+
                                                 |     i_LSB     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 ~                    Disclosed Key K_{i-d}                      +
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 ~                       MAC(K'_i, M)            +-+-+-+-+-+-+-+-+
 |                                               |  i_NSB (opt)  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 ~                   Weak Group MAC (optional)                   ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Figure 8: Format of the compact authentication tag 



  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
                                                 +-+-+-+-+-+-+-+-+
                                                 |     i_LSB     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 ~                       MAC(K'_i, M)            +-+-+-+-+-+-+-+-+
 |                                               |  i_NSB (opt)  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 ~                   Weak Group MAC (optional)                   ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Figure 9: Format of the compact authentication tag without key disclosure 



  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
                                                 +-+-+-+-+-+-+-+-+
                                                 |     i_LSB     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 ~              New Key Commitment F(K_{N+1})                    +
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 ~                       MAC(K'_i, M)            +-+-+-+-+-+-+-+-+
 |                                               |  i_NSB (opt)  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 ~                   Weak Group MAC (optional)                   ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Figure 10: Format of the compact authentication tag with a new key chain commitment 



  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
                                                 +-+-+-+-+-+-+-+-+
                                                 |     i_LSB     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 ~                  Last Key of Old Chain, K_N                   +
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 ~                       MAC(K'_i, M)            +-+-+-+-+-+-+-+-+
 |                                               |  i_NSB (opt)  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 ~                   Weak Group MAC (optional)                   ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Figure 11: Format of the compact authentication tag with an old chain last key disclosure 

where:

"i_LSB" (Interval Index Least Significant Byte) field (8 bits):

the i_LSB field contains the least significant byte of the interval index associated to the key (K'_i) used to compute the MAC of this packet.

"i_NSB" (Interval Index Next Significant Bytes) field (variable length, depending on the MAC type):

the i_NSB field contains the next significant bytes of the interval index associated to the key (K'_i) used to compute the MAC of this packet. This field is present instead of the "Padding" field when the MAC(K'_i, M) field length is not a multiple of 32 bits.

The compact version does not include the "i" interval index but the "i_LSB" field and sometimes, depending on the MAC type, the "i_NSB" field. Upon receiving such an authentication tag, a receiver infers the associated "i" value, by estimating the current interval where the sender is supposed to be, assuming that this packet has not been significantly delayed by the network. The remaining of the processing does not change.

For instance, with HMAC-SHA-1, the MAC(K'_i, M) field is 8 byte long. In that case the i_NSB field contains the bytes 2 and 3 of the "i" counter. Together with the i_LSB byte, the three least significant bytes of "i" are carried in the compact tag authentication header extensions. If T_int is 0.5s, then the {i_NSB; i_LSB} counter is sufficient (i.e. contains as much information as the 32 bit "i" field) for sessions that last at most 2330 hours.



 TOC 

5.  Receiver Operations



 TOC 

5.1.  Initialization of a Receiver

A receiver must be initialized before being able to authenticate the source of incoming packets. This can be done by an out-of-band mechanism, out of the scope of the present document, or an in-band mechanism (Section 2.3 (Bootstrapping TESLA)). Let's focus on the in-band mechanism. Two actions must be performed:



 TOC 

5.1.1.  Processing the Bootstrap Information Message

A receiver must first receive a packet containing the bootstrap information, digitally signed by the sender, and verify its signature. Because the packet is signed, the receiver also needs to know the public key of the sender. This document does not specify how the public key of the sender is communicated reliably and in a secure way to all possible receivers. Once the bootstrap information has been verified, the receiver can initialize its TESLA component. The receiver MUST then ignore the following bootstrap information messages, if any. There is an exception though: when a new key chain is used and if a receiver missed all the commitments for this new key chain, then this receiver MUST process one of the future Bootstrap information messages (if any) in order to be able to authenticate the incoming packets associated to this new key chain.

Before TESLA has been initialized, a receiver MUST ignore all packets other than the bootstrap information message. Yet, a receiver MAY chose to buffer incoming packets, recording the reception time of each packet, and proceed with delayed authentication later, once the receiver will be fully initialized. In that case, the buffer must be carefully sized in order to prevent memory starvation (e.g. an attacker who sends faked packets before the session actually starts can exhaust the memory of receivers who do not limit the maximum incoming buffer size).



 TOC 

5.1.2.  Time Synchronization

First of all, the receiver must know whether the ALC or NORM session relies on direct or indirect time synchronization. This information is communicated by an out-of-band mechanism (for instance when describing the various parameters of a FLUTE session in case of ALC). In some cases, both mechanisms might be available.



 TOC 

5.1.2.1.  Direct Time Synchronization

In case of a direct time synchronization, a receiver MUST synchronize with the sender. To that purpose, the receiver sends a direct time synchronization request message. This message includes the local time (NTP timestamp) at the receiver when sending the message. This timestamp will be copied in the sender's response.

The direct time synchronization request message format is the following:



  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)                       +
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 ~                   Weak Group MAC (optional)                   ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Figure 12: Format of a Direct Time Synchronization Request 

The direct time synchronization request (Figure 12 (Format of a Direct Time Synchronization Request)) contains the following information:

"t_r" (NTP timestamp, 64 bits):

t_r is an NTP timestamp that contains the receiver local time value when sending this direct time synchronization request message;

"Weak Group MAC" field (optional, variable length, multiple of 32 bits):

This field contains the weak MAC, calculated with a group key, K_g, shared by all group members. The field length is given by n_w, in bits.

Section 4.3.2 (Format of a Direct Time Synchronization Response) specifies the direct time synchronization response message format.

Note that in an ALC session, the direct time synchronization request message is sent to the sender by an out-of-band mechanism that is not specified by the current document.



 TOC 

5.1.2.2.  Indirect Time Synchronization

With the indirect time synchronization method, the sender MAY provide out-of-band the URL or IP address of the NTP server(s) he 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 does not specify how the choice is made, but for the sake of scalability, the clients SHOULD NOT use the same server if several possibilities are offered. The NTP synchronization between the NTP server and the receiver MUST be authenticated, either using the certificate provided by the content delivery server, or another certificate the client may obtain for this NTP server.

Then the receiver computes the time offset between itself and the NTP server chosen. Note that the receiver does not need to update the local time, since this operation often requires root privileges. Computing the time offset is sufficient.

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 3.2 (Delay Bound Calculation in Indirect time Synchronization Mode)).



 TOC 

5.2.  Authentication of Received Packets

The receiver can now authenticate incoming packets. To that purpose, he MUST follow different steps (see [RFC4082] (Perrig, A., Song, D., Canetti, R., Tygar, J., and B. Briscoe, “Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction,” June 2005.) section 3.5):

  1. The receiver parses the different packet headers. If none of the eight TESLA authentication tags is present, the receiver MUST discard the packet.
  2. Safe packet test: When the receiver receives packet P_j, it first records the local time T at which the packet arrived. The receiver then computes an upper bound t_j on the sender's clock at the time when the packet arrived: t_j = T + D_t. The receiver then computes the highest interval the sender could possibly be in: highest_i = floor((t_j - T_0) / T_int). Two possibilities arise then: The receiver can now proceed with the "safe packet" test. If highest_i < i + d, then the sender is not yet in the interval during which it discloses the key K_i. The packet is safe (but not necessarily authentic). If the test fails, the packet is unsafe, and the receiver MUST discard the packet.
  3. Weak Group MAC test: The receiver checks the optional Weak Group Tag, if present. To that purpose, the receiver recomputes the group MAC and compares it to the value stored in the "Weak Group MAC" field. If the check fails, the packet is immediately dropped.
  4. Disclosed Key processing: When the packet discloses a key (i.e., with a standard or compact authentication tag, or with a standard or compact authentication tag with an old chain last key disclosure), the following tests are performed:
  5. New Key Chain Commitment processing: When the packet includes a new key chain commitment (i.e., with a standard or compact authentication tag with a new key chain commitment), the receiver first checks whether a commitment has already been received or not for this new key chain. If this is a new commitment, the receiver stores it. If a commitment is already available, it is recommended that the receiver stores the new commitment. Indeed, the previously stored commitment(s) may fail the authentication test and therefore turn out to be useless. When the commitment is stored, it is marked as non-verified. This commitment will be validated later on, when the associated packet is authenticated.
  6. When applicable, the receiver performs congestion control, even if the packet has not yet been authenticated [draft‑ietf‑rmt‑bb‑lct‑revised] (Luby, M., Watson, M., and L. Vicisano, “Layered Coding Transport (LCT) Building Block,” November 2007.). If this feature leads to a potential DoS attack (the attacker can send a high data rate stream of faked packets), it does not compromise the security features offered by TESLA and enables a rapid reaction in front of actual congestion problems.
  7. The receiver then buffers the packet for a later authentication, once the corresponding key will be disclosed (after d time intervals) or deduced from another key (if all packets disclosing this key are lost).
  8. Authentication test: Let v be the smallest index of the legitimate keys known by the receiver so far. For all the new keys K_w, with v < w < = i-d, that have been either disclosed by this packet (i.e. K_{i-d}) or derived by K_{i-d} (i.e. keys in interval {v+1,.. i-d-1}), the receiver verifies the authenticity of the safe packets buffered for the corresponding interval w. To authenticate one of the buffered packets P_h containing message M_h protected with a MAC that used key index w, the receiver will compute K'_w = F'(K_w) from which it can compute MAC( K'_w, M_h). If this MAC equals the MAC stored in the packet, the packet is successfully authenticated and the receiver continues processing it. If the MACs do not agree, the receiver MUST discard the packet.
  9. The receiver continues processing all the packets authenticated during the authentication test.

In this specification, a receiver using TESLA MUST immediately drop unsafe packets. But the receiver MAY also decide, at any time, to continue an ALC or NORM session in unsafe mode, ignoring TESLA extensions.



 TOC 

6.  Integration in the ALC and NORM Protocols



 TOC 

6.1.  Authentication Header Extension Format

The integration of TESLA in ALC or NORM is similar and relies on the header extension mechanism defined in both protocols. More precisely this document details the EXT_AUTH==1 header extension defined in [draft‑ietf‑rmt‑bb‑lct‑revised] (Luby, M., Watson, M., and L. Vicisano, “Layered Coding Transport (LCT) Building Block,” November 2007.).

----- Editor's note: All authentication schemes using the EXT_AUTH header extension MUST reserve the same 4 bit "ASID" field after the HET/HEL fields. This way, several authentication schemes can be used in the same ALC or NORM session, even on the same communication path. -----

Several fields are added in addition to the HET (Header Extension Type) and HEL (Header Extension Length) fields (Figure 13 (Format of the TESLA EXT_AUTH header extension.)).



  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 13: Format of the TESLA EXT_AUTH header extension. 

The fields of the TESLA EXT_AUTH header extension are:

"ASID" (Authentication Scheme Identifier) field (4 bits):

The "ASID" identifies the source authentication scheme or protocol in use. The association between the "ASID" value and the actual authentication scheme is defined out-of-band, at session startup.

"Type" field (4 bits):

The "Type" field identifies the type of TESLA information carried in this header extension. This specification defines the following types:

"Content" field (variable length):

This is the TESLA information carried in the header extension, whose type is given by the "Type" field.



 TOC 

6.2.  Use of Authentication Header Extensions

Each packet sent by the session's sender MUST contain exactly one TESLA EXT_AUTH header extension.

All receivers MUST recognize EXT_AUTH but MAY not be able to parse its content, for instance because they do not support TESLA. In that case these receivers MUST ignore the TESLA EXT_AUTH extensions. In case of NORM, the packets sent by receivers MAY contain a direct synchronization request but MUST NOT contain any of the other five TESLA EXT_AUTH header extensions.



 TOC 

6.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. The reason for that is the large size of this bootstrap information. By using stand-alone packets, the maximum payload size of data packets is only affected by the (mandatory) authentication information header extension.

With ALC, the "bootstrap information" TESLA EXT_AUTH MUST be sent in a control packet, i.e. containing no encoding symbol.

With NORM, the "bootstrap information" TESLA EXT_AUTH MUST be sent in a NORM_CMD(APPLICATION) message.



  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 (=45)  |  ASID |   0   |  Reserved |1|0|  ^
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
 |       1       |       1       |   1   |       128             |  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
 |       1       |      d        |             T_int             |  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
 |                                                               |  |
 +                      T_0 (NTP timestamp)                      +  |  4
 |                                                               |  |  8
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
 |                  N (Number of Keys in chain)                  |  |  b
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |  y
 |                   i (Interval Index of K_i)                   |  |  t
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |  e
 |                                                               |  |  s
 +                                                               +  |
 |                                                               |  |
 +                              K_i                              +  |
 |                          (20 bytes)                           |  |
 +                                                               +  |
 |                                                               |  |
 +                                                               +  |
 |                                                               |  v
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  ----
 |                                                               |  ^  1
 +                                                               +  |  2
 |                                                               |  |  8
 .                                                               .  |
 .                           Signature                           .  |  b
 .                          (128 bytes)                          .  |  y
 |                                                               |  |  t
 +                                                               +  |  e
 |                                                               |  v  s
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  ----
 |                        Weak Group MAC                         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Figure 14: Example: Format of the bootstrap information message (Type 0), using 1024 bit signatures, the default HMAC-SHA-1 and a Weak Group MAC. 

For instance Figure 14 (Example: Format of the bootstrap information message (Type 0), using 1024 bit signatures, the default HMAC-SHA-1 and a Weak Group MAC.) shows the bootstrap information message when using the HMAC-SHA-1 transform for the PRF, MAC, and Weak Group MAC functions, along with 128 byte (1024 bit) key digital signatures (which also means that the signature field is 128 byte long). The TESLA EXT_AUTH header extension is then 180 byte long (i.e. 45 words of 32 bits).



 TOC 

6.2.2.  EXT_AUTH Header Extension of Type Authentication Tag

The eight "authentication tag" TESLA EXT_AUTH (Type 1, 2, 3, 4, 5, 6, 7 and 8) MUST be attached to the ALC or NORM packet (data or control packet) that they protect.



  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 (=9)  |  ASID |   5   |     i_LSB     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 +                                                               +
 |                                                               |
 +                     Disclosed Key K_{i-d}                     +
 |                          (20 bytes)                           |
 +                                                               +
 |                                                               |
 +                                                               +
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 +                         MAC(K'_i, M)                          +
 |                          (10 bytes)                           |
 +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                               |             i_NSB             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Figure 15: Example: Format of the standard authentication tag (Type 5), using the default HMAC-SHA-1. 



  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 (=4)    |  ASID |   6   |     i_LSB     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 +                         MAC(K'_i, M)                          +
 |                          (10 bytes)                           |
 +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                               |             i_NSB             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Figure 16: Example: Format of the compact authentication tag without key disclosure (Type 6), using the default HMAC-SHA-1. 

For instance, Figure 15 (Example: Format of the standard authentication tag (Type 5), using the default HMAC-SHA-1.) and Figure 16 (Example: Format of the compact authentication tag without key disclosure (Type 6), using the default HMAC-SHA-1.) show the format of the compact authentication tags, respectively with and without the K_{i-d} key disclosure, when using the (default) HMAC-SHA-1 transform for the PRF and MAC functions. In this example, the Weak Group MAC feature is not used.



 TOC 

6.2.3.  EXT_AUTH Header Extension of Type Direct Time Synchronization Request

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, the "direct time synchronization request" TESLA EXT_AUTH cannot be included in an ALC packet, since ALC is restricted to unidirectional transmissions, from the session's sender to the receivers. An external mechanism, out of the scope of this document, must be used with ALC for carrying direct time synchronization requests to the session's sender.

In case of direct time synchronization, it is RECOMMENDED that the receivers spread the transmission of direct time synchronization requests over the time (Section 2.2.1 (Direct Time Synchronization)).



 TOC 

6.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 "direct time synchronization response" TESLA EXT_AUTH can be sent in an ALC control packet (i.e. containing no encoding symbol) or through the external mechanism use to carry the direct time synchronization request.



 TOC 

6.3.  Managing Silent Periods

An ALC or NORM sender may stop transmitting packet for some time, for various reasons. It can be the end of the session and all packets have already been sent, or the use-case may consist in a succession of busy periods (when fresh objects are available) followed by silent periods. In both cases, this is an issue since the authentication of the packets sent during the last d intervals requires that the associated keys be revealed, which can only take place after d additional intervals.

To solve this problem, it is recommended that the sender transmit null packets containing the TESLA EXT_AUTH header extension along with a standard authentication tag (Type==1) during at least d intervals after the end of the regular ALC or NORM packet transmissions. The number of such packets and the duration during which they are sent must be sufficient for all receivers to receive, which a high probability, at least one packet disclosing the last useful key.



 TOC 

7.  IANA Considerations

This document requires a IANA registration for the following attributes:

Cryptographic Pseudo-Random Function, TESLA-PRF: All implementations MUST support HMAC-SHA-1 (default).

PRF nameValuen_p and n_f
INVALID 0 N/A
HMAC-SHA-1 (default) 1 160 bits (20 bytes)
HMAC-SHA-224 2 224 bits (28 bytes)
HMAC-SHA-256 3 256 bits (32 bytes)
HMAC-SHA-384 4 384 bits (48 bytes)
HMAC-SHA-512 5 512 bits (64 bytes)

Cryptographic Message Authentication Code (MAC): All implementations MUST support HMAC-SHA-1 (default).

MAC nameValuen_mn_w
INVALID 0 N/A N/A
HMAC-SHA-1 (default) 1 80 bits (10 bytes) 32 bits (4 bytes)
HMAC-SHA-224 2 112 bits (14 bytes) 32 bits (4 bytes)
HMAC-SHA-256 3 128 bits (16 bytes) 32 bits (4 bytes)
HMAC-SHA-384 4 192 bits (24 bytes) 32 bits (4 bytes)
HMAC-SHA-512 5 256 bits (32 bytes) 32 bits (4 bytes)

Signature Encoding Algorithm: All implementations MUST support RSASSA-PKCS1-v1_5 (default).

Signature Algorithm NameValue
INVALID 0
RSASSA-PKCS1-v1_5 (default) 1
RSASSA-PSS 2



 TOC 

8.  Security Considerations

[RFC4082] (Perrig, A., Song, D., Canetti, R., Tygar, J., and B. Briscoe, “Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction,” June 2005.) discusses the security of TESLA in general. These considerations apply to the present specification, namely:

The current specification discusses additional aspects with more details.



 TOC 

8.1.  Dealing With DoS Attacks

TESLA introduces new opportunities for an attacker to mount DoS attacks: for instance by saturating the processing capabilities of the receiver (faked packets are easy to create but checking them requires to compute a MAC over the packet), or by saturating its memory (since authentication is delayed), or by making the receiver believe that a congestion has happened (since congestion control MUST be performed before authenticating incoming packets, Section 5.2 (Authentication of Received Packets)).

In order to mitigate these attacks, when it is believed that attackers do not belong to the group, it is RECOMMENDED to use the Weak Group MAC scheme (Section 4.2.4 (Weak Group MAC Tag)).

Generally, it is RECOMMENDED that the amount of memory used to store incoming packets waiting to be authenticated be limited to a reasonable value.



 TOC 

8.2.  Dealing With Replay Attacks

Replay attacks, whereby an attacker stores a valid message and replays it later on, can have significant impacts, depending on the message type. Two levels of impacts must be distinguished:



 TOC 

8.2.1.  Impacts of Replay Attacks on TESLA

Replay attacks can impact the TESLA component itself. We review here, type by type, the potential impacts of such an attack depending on the TESLA message type:

To conclude, TESLA itself is robust in front of replay attacks.



 TOC 

8.2.2.  Impacts of Replay Attacks on NORM

We review here the potential impacts of a replay attack on the NORM component.

First, let us consider replay attacks within a given NORM session. NORM defines a "sequence" field that can be used to protect against replay attacks [draft‑ietf‑rmt‑pi‑norm‑revised] (Adamson, B., Bormann, C., Handley, M., and J. Macker, “Negative-acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Protocol,” March 2007.) within a given NORM session. This "sequence" field is a 16-bit value that is set by the message originator (sender or receiver) as a monotonically increasing number incremented with each NORM message transmitted. It is RECOMMENDED that a receiver check this sequence field and drop messages considered as replayed. Similarly, it is RECOMMENDED that a sender check this sequence, for each known receiver, and drop messages considered as replayed. This analysis shows that NORM itself is robust in front of replay attacks within the same session.

Now let us consider replay attacks across several NORM sessions. Since the key chain used in each session MUST differ, a packet replayed in a subsequent session will be identified as unauthentic. Therefore NORM is robust in front of replay attacks across different sessions.



 TOC 

8.2.3.  Impacts of Replay Attacks on ALC

We review here the potential impacts of a replay attack on the ALC component. Note that we do not consider here the protocols that could be used along with ALC, for instance the layered or wave based congestion control protocols.

First, let us consider replay attacks within a given ALC session:

This analysis shows that ALC itself is robust in front of replay attacks within the same session.

Now let us consider replay attacks across several ALC sessions. Since the key chain used in each session MUST differ, a packet replayed in a subsequent session will be identified as unauthentic. Therefore ALC is robust in front of replay attacks across different sessions.



 TOC 

9.  Acknowledgments

The authors are grateful to Ran Canetti, David L. Mills and Lionel Giraud for their valuable comments while preparing this document.



 TOC 

10.  References



 TOC 

10.1. Normative References

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” RFC 2119, BCP 14, March 1997.
[RFC3926] Paila, T., Luby, M., Lehtonen, R., Roca, V., and R. Walsh, “FLUTE - File Delivery over Unidirectional Transport,” RFC 3926, October 2004 (TXT).
[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 (TXT).
[draft-ietf-rmt-bb-lct-revised] Luby, M., Watson, M., and L. Vicisano, “Layered Coding Transport (LCT) Building Block,”  draft-ietf-rmt-bb-lct-revised-06.txt (work in progress), November 2007.
[draft-ietf-rmt-pi-alc-revised] Luby, M., Watson, M., and L. Vicisano, “Asynchronous Layered Coding (ALC) Protocol Instantiation,”  draft-ietf-rmt-pi-alc-revised-05.txt (work in progress), November 2007.
[draft-ietf-rmt-pi-norm-revised] Adamson, B., Bormann, C., Handley, M., and J. Macker, “Negative-acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Protocol,”  draft-ietf-rmt-pi-norm-revised-05.txt (work in progress), March 2007.


 TOC 

10.2. Informative References

[Perrig04] Perrig, A. and J. Tygar, “Secure Broadcast Communication in Wired and Wireless Networks,” Kluwer Academic Publishers ISBN 0-7923-7650-1, 2004.
[RFC1305] Mills, D., “Network Time Protocol (Version 3) Specification, Implementation,” RFC 1305, March 1992 (TXT, PDF).
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, “HMAC: Keyed-Hashing for Message Authentication,” RFC 2104, February 1997 (TXT).
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, “The Secure Real-time Transport Protocol (SRTP),” RFC 3711, March 2004 (TXT).
[RFC4330] Mills, D., “Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI,” RFC 4330, January 2006 (TXT).
[RFC4359] Weis, B., “The Use of RSA/SHA-1 Signatures within Encapsulating Security Payload (ESP) and Authentication Header (AH),” RFC 4359, January 2006 (TXT).
[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 (TXT).
[RFC4442] Fries, S. and H. Tschofenig, “Bootstrapping Timed Efficient Stream Loss-Tolerant Authentication (TESLA),” RFC 4442, March 2006 (TXT).
[draft-ietf-ntp-ntpv4-proto] Burbank, J., Kasch, W., Martin, J., and D. Mills, “The Network Time Protocol Version 4 Protocol Specification,” draft-ietf-ntp-ntpv4-proto-07.txt (work in progress), May 2007 (TXT).


 TOC 

Authors' Addresses

  Vincent Roca
  INRIA
  655, av. de l'Europe
  Zirst; 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
  Zirst; 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
  Zirst; Montbonnot
  ST ISMIER cedex 38334
  France
Email:  faurite@lcpc.fr


 TOC 

Full Copyright Statement

Intellectual Property