One document matched: draft-ietf-msec-tesla-for-alc-norm-04.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
]>
<rfc category="exp" ipr="full3978" docName="draft-ietf-msec-tesla-for-alc-norm-04.txt">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<front>
<title abbrev='TESLA in ALC and NORM'>
Use of TESLA in the ALC and NORM Protocols
</title>
<author initials='V.R.' surname="Roca" fullname='Vincent Roca'>
<organization>INRIA</organization>
<address>
<postal>
<street>655, av. de l'Europe</street>
<street>Inovallee; Montbonnot</street>
<city>ST ISMIER cedex</city>
<code>38334</code>
<country>France</country>
</postal>
<!--
<phone></phone>
-->
<email>vincent.roca@inria.fr</email>
<uri>http://planete.inrialpes.fr/~roca/</uri>
</address>
</author>
<author initials='A.F.' surname="Francillon" fullname='Aurelien Francillon'>
<organization>INRIA</organization>
<address>
<postal>
<street>655, av. de l'Europe</street>
<street>Inovallee; Montbonnot</street>
<city>ST ISMIER cedex</city>
<code>38334</code>
<country>France</country>
</postal>
<!--
<phone></phone>
-->
<email>aurelien.francillon@inria.fr</email>
<uri>http://planete.inrialpes.fr/~francill/</uri>
</address>
</author>
<author initials='S.F.' surname="Faurite" fullname='Sebastien Faurite'>
<organization>INRIA</organization>
<address>
<postal>
<street>655, av. de l'Europe</street>
<street>Inovallee; Montbonnot</street>
<city>ST ISMIER cedex</city>
<code>38334</code>
<country>France</country>
</postal>
<email>faurite@lcpc.fr</email>
<!--
<phone></phone>
<uri></uri>
-->
</address>
</author>
<date day="18" month="February" year="2008"/>
<area>Transport</area>
<workgroup>MSEC</workgroup>
<keyword>TESLA</keyword>
<keyword>FLUTE</keyword>
<keyword>ALC</keyword>
<keyword>NORM</keyword>
<abstract>
<t>
This document details the TESLA packet source authentication and packet integrity
verification protocol and its integration within the ALC and NORM content delivery
protocols.
This document only considers the authentication/integrity verification of the packets
generated by the session's sender. Adding authentication/integrity verification to
the packets sent by receivers, if any, is out of the scope of this document.
</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<!-- ==================================== -->
<t>
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 the integrity of these packets.
This is the case with ALC <xref target="draft-ietf-rmt-pi-alc-revised"/> and
NORM <xref target="draft-ietf-rmt-pi-norm-revised"/>,
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.
On the opposite, the ALC protocol is based on purely unidirectional transmissions.
Reliability is achieved by means of the cyclic transmission of the content
within a carousel and/or by the use of proactive Forward Error Correction
codes (FEC).
<!--
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.
</t>
<t>
The goal of this document is to counter attacks where
an attacker impersonates the ALC or NORM session's sender and injects
forged packets to the receivers, thereby corrupting the objects reconstructed
by the receivers.
</t>
<t>
Preventing this attack is much more complex in case of group communications
than it is with unicast communications.
Indeed, in the latter case a simple solution to this problem exists: the sender
and the 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 multicast and broadcast
communications since sharing a group key between the sender and all
receivers implies that any group member can impersonate the sender and send
forged messages to other receivers.
</t>
<t>
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.
</t>
<t>
This document explains how to integrate the TESLA source authentication and
packet integrity protocol to the ALC and NORM CDP.
Any application built on top of ALC and NORM will directly benefit from the
services offered by TESLA at the transport layer.
In particular, this is the case of FLUTE <xref target="draft-ietf-rmt-flute-revised"/>.
</t>
<t>
This specification only considers the authentication/integrity of the packets
generated by the session's sender.
This specification does not consider the packets that may be sent by receivers,
for instance NORM's feedback packets.
Adding authentication/integrity to the packets sent by receivers is outside
the scope of this document.
</t>
<t>
For more information on the TESLA protocol and its principles, please refer to
<xref target="RFC4082"/><xref target="Perrig04"/>.
For more information on ALC and NORM, please refer to
<xref target="draft-ietf-rmt-pi-alc-revised"/>, <xref target="draft-ietf-rmt-bb-lct-revised"/>
and <xref target="draft-ietf-rmt-pi-norm-revised"/> respectively.
</t>
<section title="Conventions Used in this Document">
<!-- ------------------------------------ -->
<t>
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 <xref target="RFC2119"/>.</t>
</section>
<section title="Terminology and Notations">
<!-- ------------------------------------ -->
<t>
The following notations and definitions are used throughout this document.
</t>
<section title="Notations and Definitions Related to Cryptographic Functions">
<!-- ------------------------------------ -->
<t>
Notations and definitions related to cryptographic functions
<xref target="RFC4082"/><xref target="RFC4383"/>:
<list style='symbols'>
<t>PRF is the Pseudo Random Function;</t>
<t>MAC is the Message Authentication Code;</t>
<t>HMAC is the Keyed-Hash Message Authentication Code;</t>
<t>F is the one-way function used to create the key chain;</t>
<t>F' is the one-way function used to derive the HMAC keys;</t>
<t>n_p is the length, in bits, of the F function's output.
This is therefore the length of the keys in the key chain;</t>
<t>n_f is the length, in bits, of the F' function's output.
This is therefore the length of the HMAC keys;</t>
<t>n_m is the length of the truncated output of the MAC <xref target="RFC2104"/>.
Only the n_m left-most bits (most significant bits) of the MAC
output are kept;</t>
<t>N is 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;</t>
<t>n_c is the number of keys in a key chain. Therefore: n_c = N+1;</t>
<t>n_tx_lastkey is the number of 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 delay d. These extra transmissions
take place after the interval during which the last key is normally
disclosed. The n_tx_lastkey value is either 0 (no extra disclosure) or larger.
This parameter is sender specific and is not communicated to the receiver;</t>
<t>n_tx_newkcc is the number of intervals during which the commitment to
a new key chain SHOULD be sent, before switching to the new key chain.
The n_tx_newkcc value is either 0 (no commitment sent within authentication tags)
or larger.
This parameter is sender specific and is not communicated to the receiver;</t>
<t>K_g is a shared group key, communicated to all group members, confidentially,
before starting the session.
The mechanism by which this group key is shared by the group members is
out of the scope of this document;</t>
<t>n_w is the length of the truncated output of the MAC of the optional
weak group authentication scheme:
only the n_w most significant bits of the MAC output are kept.
n_w is typically a small value (e.g., 32 bits), multiple of 32 bits;</t>
</list></t>
</section>
<section title="Notations and Definitions Related to Time">
<!-- ------------------------------------ -->
<t>
Notations and definitions related to time:
<list style='symbols'>
<t>i is 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 might take place in long sessions.</t>
<t>t_s is the sender local time value at some absolute time;</t>
<t>t_r is the receiver local time value at the same absolute time;</t>
<t>T_0, the start time corresponding to the beginning of the session (NTP timestamp);</t>
<t>T_int, the interval duration (in milliseconds);</t>
<t>d, the key disclosure delay (in number of intervals);</t>
<t>D_t, the upper bound of the lag of the receiver's clock with respect to
the clock of the sender;</t>
<t>S_sr, an estimated bound of the clock drift between the sender and a receiver
throughout the duration of the session;</t>
<t>D^O_t, the upper bound of the lag of the sender's clock with respect to
the time reference in indirect time synchronization mode;</t>
<t>D^R_t, the upper bound of the lag of the receiver's clock with respect to
the time reference in indirect time synchronization mode;</t>
<t>D_err, an upper bound of the time error between all the time references,
in indirect time synchronization mode;</t>
</list></t>
</section>
</section>
</section><!-- =Introduction= -->
<!-- ======================================================================= -->
<section title="Using TESLA with ALC and NORM: General Operations" anchor="using_tesla_with_cdp">
<!-- ------------------------------------ -->
<section title="ALC and NORM Specificities that Impact TESLA"
anchor="alc_norm_specificities">
<!-- ------------------------------------ -->
<t>The ALC and NORM protocols have features and requirements that largely impact
the way TESLA can be used.</t>
<t>In case of ALC:
<list style='symbols'>
<t>ALC is massively scalable:
nothing in the protocol specification limits the number of receivers
that join a session.
Therefore an ALC session potentially includes a huge number (e.g., millions
or more) of receivers;
</t>
<t>ALC can work on top of purely unidirectional transport channels:
this is one of the assets of ALC, and examples of unidirectional channels
include satellite (even if a back channel might exist in some use cases)
and DVB-H/SH systems;
</t>
<t>ALC defines an on-demand content delivery model <xref target="draft-ietf-rmt-pi-alc-revised"/>
where receivers can arrive at any time, at their own discretion,
download the content and leave the session.
Other models (e.g., push or streaming) are also defined;
</t>
<t>ALC sessions are potentially very long:
a 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).</t>
</list>
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
with a limited number of receivers.
</t>
<t>In case of NORM:
<list style='symbols'>
<t>NORM has been designed for medium size sessions:
indeed, NORM relies on feedback messages and the sender
may collapse if the feedback message rate is too high;
</t>
<t>NORM requires a bidirectional transport channel:
the back channel is not necessarily a high data rate channel since
the control traffic sent over it by a single receiver is an order
of magnitude lower than the downstream traffic.
Networks with an asymmetric connectivity (e.g., a high rate satellite
downlink and a low-rate RTC based return channel) are appropriate;
</t>
</list>
</t>
</section>
<section title="Bootstrapping TESLA" anchor="sec:intro_to_bootstrap">
<!-- ------------------------------------ -->
<t>
In order to initialize the TESLA component at a receiver, the sender MUST
communicate some key information in a secure way, so that the receiver can check
the source of the information and its integrity.
Two general methods are possible:
<list style='symbols'>
<t> by using an out-of-band mechanism, or
</t>
<t> by using an in-band mechanism.
</t>
</list>
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.</t>
<section title="Bootstrapping TESLA with an Out-Of-Band Mechanism">
<!-- ------------------------------------ -->
<t>
For instance <xref target="RFC4442"/> 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 provide the required security
level.
</t>
</section>
<section title="Bootstrapping TESLA with an In-Band Mechanism">
<!-- ------------------------------------ -->
<t>
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 exchange of a bootstrap information message
(described in <xref target="sec:bootstrap_info_format"/>) and the knowledge
of a few additional parameters (listed below) are sufficient to bootstrap
TESLA at a receiver.
</t>
<t>
Some parameters cannot be communicated in-band.
In particular, the sender or a group controller:
<list style='symbols'>
<t> MUST either communicate his public key or a certificate (which also
means that a PKI has been setup), for each receiver to be able
to verify the signature of the bootstrap message and direct time
synchronization response messages (when applicable).
<!--
As a side effect, the receivers also know the key length
and the signature length, the two parameters being equal.
-->
</t>
<t> when time synchronization is performed with (S)NTP, MUST
communicate the list of valid (S)NTP servers, for all group
members (including the server) to synchronize themselves on
the same (S)NTP servers.</t>
<t> when the Weak Group MAC feature is used, MUST communicate
the K_g group key to the receivers.
This key might be periodically refreshed.</t>
</list>
These parameters MUST be communicated to all receivers to enable them to
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.
</t>
</section>
</section>
<section title="Setting Up a Secure Time Synchronization"
anchor="sec:need_for_time_sync">
<!-- ------------------------------------ -->
<t>
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:
<list style='symbols'>
<t>direct time synchronization, and</t>
<t>indirect time synchronization.</t>
</list>
</t>
<section title="Direct Time Synchronization" anchor="sec:intro_to_direct_time_sync">
<!-- ------------------------------------ -->
<t>
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" (<xref target="sec:direct_synch_request_format" />).
The sender then directly answers to each request with a "Direct Time Synchronization
Response" (<xref target="sec:direct_synch_response_format" />), 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 <xref target="sec:delay_bound_calc_direct_sync"/>.
</t>
<t>
This synchronization method is both simple and secure.
Yet there are two potential issues:
<list style='symbols'>
<t>a bidirectional channel must exist between the sender and each receiver,</t>
<t>the sender may collapse if the incoming request rate is too high.</t>
</list>
</t>
<t>
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.
</t>
<t>
But direct time synchronization is potentially incompatible with ALC since (1) there
might not be a back channel and (2) there are potentially
a huge number of receivers and therefore a risk that the sender collapses.
</t>
</section>
<section title="Indirect Time Synchronization"
anchor="sec:intro_to_indirect_time_sync">
<!-- ------------------------------------ -->
<t>
When indirect time synchronization is used, the sender and each receiver must
synchronize securely via an external time reference.
Several possibilities exist:
<list style='symbols'>
<t>sender and receivers can synchronize through a NTPv3
(Network Time Protocol version 3) <xref target="RFC1305"/>
hierarchy of servers.
The authentication mechanism of NTPv3 MUST be used in order
to authenticate each NTP message individually. It prevents
for instance an attacker to impersonate a NTP server;</t>
<t>they can synchronize through a NTPv4
(Network Time Protocol version 4) <xref target="draft-ietf-ntp-ntpv4-proto"/>
hierarchy of servers.
The Autokey security protocol of NTPv4 MUST be used in order
to authenticate each NTP message individually;</t>
<t>they can synchronize through a SNTPv4
(Simple Network Time Protocol version 4) <xref target="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 the time synchronization
service offered by SNTP;</t>
<t>they can synchronize through a GPS or Galileo (or similar) device
that also provides a high precision time reference.
This time reference is in general trusted, yet depending on the
use case, the security achieved will be or not acceptable;</t>
<t>they can synchronize thanks to a dedicated hardware,
embedded on each sender and receiver, that provides a clock
with a time-drift that is negligible in front of the TESLA time
accuracy requirements. This feature enables a device to synchronize
its embedded clock with the official time reference from time to
time (in an extreme case once, at manufacturing time),
and then to remain autonomous for a duration that depends on the
known maximum clock drift.</t>
</list>
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 (<xref target="alc_norm_specificities"/>), 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 can be a good choice.
</t>
<t>
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
<xref target="sec:delay_bound_calc_indirect_sync"/>.
</t>
<!--
<t>
In any case, this document does not explain in details how to achieve
time synchronization, whether it follows a direct or indirect scheme.
The document only provides general guidelines.
The details are outside the scope of this document.
</t>
-->
</section>
</section><!-- -The Need for Secure Time Synchronization- -->
<section title="Determining the Delay Bounds" anchor="delay_bound">
<!-- ------------------------------------ -->
<t>
Let us assume that a secure time synchronization has been set up.
This section explains how to define the various timing parameters that
are used during the authentication of received packets.
</t>
<section title="Delay Bound Calculation in Direct Time Synchronization Mode"
anchor="sec:delay_bound_calc_direct_sync">
<!-- ------------------------------------ -->
<t>
In direct time synchronization mode, synchronization between a receiver and the
sender follows the following protocol <xref target="RFC4082"/>:
<list style='symbols'>
<t> The receiver sends a "Direct Time Synchronization Request" message to the sender,
that includes t_r, the receiver local time at the moment of sending
(<xref target="sec:direct_synch_request_format" />).</t>
<t> Upon receipt of this message, the sender records its local time, t_s,
and sends to the receiver a "Direct Time Synchronization Response" that includes
t_r (taken from the request) and t_s (<xref target="sec:direct_synch_response_format" />),
signing this reply.</t>
<t> Upon receiving this response, the receiver first verifies that he actually
sent a request with t_r and then checks the signature.
Then he calculates D_t = t_s - t_r + S_sr, where S_sr is an estimated bound of the
clock drift between the sender and the receiver throughout the duration of the
session.
This document does not specify how S_sr is estimated.
</t>
</list>
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.
</t>
</section>
<section title="Delay Bound Calculation in Indirect time Synchronization Mode"
anchor="sec:delay_bound_calc_indirect_sync">
<!-- ----------------------------------------------------------------- -->
<t>
In indirect time synchronization, the sender and the receivers must synchronize
indirectly with one or several time references.
</t>
<section title="Single time reference">
<!-- ----------------------------- -->
<t>
Let's assume that there is a single time reference.
<list style='numbers'>
<t> 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
(<xref target="sec:bootstrap_info"/>).</t>
<t> 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.</t>
<t> 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.</t>
</list>
The D^O_t and D^R_t calculation depends on the time synchronization mechanism
used (<xref target="sec:intro_to_indirect_time_sync"/>).
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 <xref target="sec:delay_bound_calc_direct_sync"/>, for instance
when synchronization is achieved via a group controller <xref target="RFC4082"/>.
</t>
</section>
<section title="Multiple time references">
<!-- -------------------------------- -->
<t>
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.
</t>
<t>
In some cases, the D_t value is part of the time synchronization scheme specifications.
For instance NTPv3 <xref target="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".
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.
The choice of the security_factor value is left to the implementer, depending on
the target use-case.
</t>
</section>
</section>
</section>
</section><!-- -Time Synchronization and Delay Bound Calculations- -->
<!-- ======================================================================= -->
<section title="Sender Operations">
<!-- ==================================== -->
<t>
This section describes the TESLA operations at a sender.
</t>
<section title="TESLA Parameters">
<!-- ------------------------------------ -->
<section title="Time Intervals" anchor="sec:time_intervals">
<!-- ------------------------------------ -->
<t>
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.
</t>
</section>
<section title="Key Chains" anchor="sec:key_chains">
<!-- ------------------------------------ -->
<section title="Principles">
<!-- ------------------------------------ -->
<t>
The sender computes a one-way key chain of n_c = N+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.
</t>
<t>
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.
</t>
<t>The key chain has a finite length, N, which corresponds to a maximum duration
of (N + 1) * T_int.
The content delivery session has a duration T_delivery, which may either be
known in advance, or not.
A first solution consists in having a single key chain of an appropriate
length, so that 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 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 <xref target="fig:key_chain_switch"/>) <xref target="Perrig04"/>.
</t>
</section>
<section title="Using Multiple Key Chains">
<!-- ------------------------------------ -->
<t>
When several key chains are needed, all of them MUST be of the same length.
Switching from the current key chain to the next one requires that a commitment
to the new key chain be communicated in a secure way to the receiver.
This can be done by using either an out-of-band mechanism, or an in-band
mechanism.
This document only specifies the in-band mechanism.
</t>
<t>
<figure anchor='fig:key_chain_switch' title="Switching to the second key chain
with the in-band mechanism, assuming that d=2, n_tx_newkcc=3, n_tx_lastkey=3.">
<preamble></preamble>
<artwork>
< -------- 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)
</artwork>
</figure>
</t>
<t>
<xref target="fig:key_chain_switch"/> illustrates the switch to the
new key chain, using the in-band mechanism.
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 <xref target='sec:auth_tag_format_new_kcc'/>).
This commitment SHOULD be sent during n_tx_newkcc time 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.
</t>
<t>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.</t>
<t>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 <xref target='sec:auth_tag_format_old_kck'/>).
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 are usually sent during an 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.
</t>
<t>
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 only solution for this receiver to catch up consists in receiving an additional
bootstrap information message.
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 (<xref target="sec:bootstrap_info"/>).
</t>
</section>
<section title="Values of the n_tx_lastkey and n_tx_newkcc Parameters"
anchor="sec:value_of_tx_lastkey_tx_newkcc">
<!-- ------------------------------------ -->
<t>
When several key chains and the in-band commitment mechanism are used,
a sender MUST initialize the n_tx_lastkey
and n_tx_newkcc parameters in such a way that no overlapping occur.
In other words, once a sender starts transmitting commitments for a new
key chain, he MUST NOT send a disclosure for the last key of the old
key chain any more.
Therefore, the following property MUST be verified:
<list style="empty">
<t>d + n_tx_lastkey + n_tx_newkcc ≤ N + 1</t>
</list>
</t>
<t>
It is RECOMMENDED, for robustness purposes, that, once n_tx_lastkey has
been chosen, then:
<list style="empty">
<t>n_tx_newkcc = N + 1 - n_tx_lastkey - d</t>
</list>
In other words, the sender starts transmitting a commitment to the following
key chain immediately after having sent all the disclosures of the last
key of the previous key chain.
Doing so increases the probability that a receiver gets a commitment for
the following key chain.
</t>
<t>
In any case, these two parameters are sender specific and need not be
transmitted to the receivers.
Of course, as explained above, the sender alternates between the disclosure
of a key of the current key chain and the commitment to the new key chain
(or the last key of the old key chain).
</t>
</section>
<section title="The Particular Case of the Session Start">
<!-- ------------------------------------ -->
<t>
Since a key cannot be disclosed before the disclosure delay, d, no key will
be disclosed during the first d time intervals (intervals 0 and 1 in
<xref target="fig:key_chain_switch"/>) of the session.
To that purpose, the sender uses the standard authentication tag without key disclosure
<xref target="sec:auth_tag_wo_key_discl_format"/> or its compact flavor.
The following key chains, if any, are not concerned since they will
disclose the last d keys of the previous chain.
</t>
</section>
<section title="Managing Silent Periods">
<!-- ------------------------------------ -->
<t>
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
disclosed, which will take place during d additional time intervals.
</t>
<t>
To solve this problem, it is recommended that the sender transmit empty
packets (i.e., without payload) containing the TESLA EXT_AUTH header
extension along with a standard authentication tag (Type==1) during at
least d time 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, with a high probability,
at least one packet disclosing the last useful key (i.e., the key used for
the last non-empty packet sent).
</t>
</section>
</section>
<section title="Time Interval Schedule" anchor="sec:time_int_schedule">
<!-- ------------------------------------ -->
<t>
The sender must determine the following parameters:
<list style='symbols'>
<t>T_0, the start time corresponding to the beginning of the session;</t>
<t>T_int, the interval duration, usually ranging from 100 milliseconds to 1
second;</t>
<t>d, the key disclosure delay (in number of intervals). It is the time to wait
before disclosing a key;</t>
<t>N, the length of a key chain;</t>
</list></t>
<t>
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 prevents many receivers from verifying packets.
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.
<xref target="RFC4082"/> sections 3.2 and 3.6 give general guidelines for
initializing these parameters.
</t>
<t>
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
(e.g., if a sender was authorized to change the key disclosure schedule, a receiver that did
not receive the change notification would still believe in the old key disclosure schedule,
thereby creating vulnerabilities <xref target="RFC4082"/>).
</t>
</section>
<section title="Timing Parameters" anchor="sec:timing_params">
<!-- ------------------------------------ -->
<t>
In indirect time synchronization mode,
the sender must determine the following parameter:
<list style='symbols'>
<t> D^O_t, the upper bound of the lag of the sender's clock with respect
to the time reference.</t>
</list>
The D^O_t parameter MUST NOT be changed during the lifetime of the session.
</t>
</section>
</section><!-- TESLA Parameters -->
<section title="TESLA Messages and Authentication Tags">
<!-- ------------------------------------ -->
<t>
At a sender, TESLA produces four types of signaling information:
<list style='symbols'>
<t>The bootstrap information.
This information can be either sent out-of-band or in-band.
In the latter case, a digitally signed packet contains all the
information required to bootstrap TESLA at a receiver;</t>
<t>The time synchronization response, which enables a receiver to finish a
direct time synchronization;</t>
<t>The authentication tag, which is sent in all data packets and contains
the MAC of the packet;</t>
<t>Additionally, an optional weak group authentication tag can be added
to packets to mitigate attacks coming from outside of the group.</t>
</list>
</t>
<section title="Bootstrap Information" anchor="sec:bootstrap_info">
<!-- ------------------------------------ -->
<t>
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
<xref target="sec:intro_to_bootstrap"/>.
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.
</t>
<t>
The TESLA bootstrap information message MUST be digitally signed
(<xref target="sec:rsa_signatures"/>).
The goal is to enable a receiver to check the packet source and packet integrity.
Then, the bootstrap information can be:
<list style='symbols'>
<t> unicast to a receiver during a direct time synchronization request/response exchange;</t>
<t> broadcast to all receivers.
This is typically the case in indirect time synchronization mode.
It can also be used in direct time synchronization mode, for instance
when a large number of clients arrive at the same time, in which case
it is more efficient to answer globally.</t>
</list>
</t>
<t>
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.
</t>
<t>
Afterward, a periodic broadcast of the bootstrap information message
could be useful when:
<list style='symbols'>
<t>the ALC session uses an ``on-demand'' mode, clients arriving at their own
discretion;</t>
<t>some clients experience an intermittent connectivity.
This is particularly important when several key chains are used in an
ALC or NORM session, since there is a risk that a receivers
lose all the commitments to the new key chain.</t>
</list>
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.
</t>
</section>
<section title="Direct Time Synchronization Response" anchor="sec:direct_synch_response">
<!-- ------------------------------------ -->
<t>
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
(<xref target="sec:delay_bound_calc_direct_sync"/>).
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
(<xref target="sec:rsa_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.
</t>
<!--
<t>
When the Weak Group MAC feature is used (<xref target="sec:group_auth_tag"/>),
upon receipt of a synchronization request, the sender MUST perform a Weak Group MAC test,
i.e., the sender 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.
</t>
-->
<t>
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.
</t>
<t>
Note that a single session might include receivers that use the direct
time synchronization mode while others use the indirect time synchronization mode.
</t>
</section>
<section title="Authentication Tag" anchor="sec:auth_tag">
<!-- ------------------------------------ -->
<t>
Every packet MUST have an authentication tag containing:
<list style='symbols'>
<t>the interval index, which is also the index of the key
used for computing the MAC of this packet: i. This interval
index is optional when ;</t>
<t>either a disclosed key (that belongs to the current key chain or the
previous key chain) or a commitment to a new key chain;</t>
<t>and the MAC of the message: MAC(K'_i, M), where K'_i=F'(K_i);</t>
</list>
</t>
<t>
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
<!--
(see <xref target='sec:auth_tag_format'/>,
<xref target='sec:auth_tag_format_new_kcc'/>,
<xref target='sec:auth_tag_format_old_kck'/>, and
<xref target='sec:auth_tag_compact_format'/>)
-->
MUST be set to 0.
</t>
</section>
<section title="Weak Group MAC Tag" anchor="sec:group_auth_tag">
<!-- ------------------------------------ -->
<t>
An optional Weak Group MAC can be used to mitigate DoS attacks coming from attackers
that are not group member <xref target="RFC4082"/>.
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:
<list style='symbols'>
<t> a receiver can immediately drop packets identified as unauthentic, without
having to wait for the disclosure delay, d;
</t>
<t> a sender can immediately drop faked direct time synchronization requests,
and in particular avoid to compute the digital signature, a computation
intensive task;
</t>
<t> a receiver can immediately drop faked direct time synchronization response
message, without having to verify the digital signature, a computation
intensive task;
</t>
</list>
</t>
<t>
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.
</t>
<t>
This scheme features a few limits:
<list style='symbols'>
<t>it is of no help if a group member (who knows K_g) impersonates
the sender and sends forged messages to other receivers;</t>
<t>it requires an additional MAC computing for each packet,
both at the sender and receiver sides;</t>
<t>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 <xref target="RFC3711"/> section 9.5).
As a side effect, the authentication service is significantly weakened
(the probability that any packet be successfully forged is one in 2^32).
Since the weak group MAC check is only a pre-check that will be followed
by the standard TESLA authentication check, this is not considered to
be an issue.</t>
</list>
For a given use-case, the benefits brought by the group MAC must be balanced
against these limitations.
</t>
<t>
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.
</t>
</section>
<section title="Use of Digital Signatures"
anchor="sec:rsa_signatures">
<!-- ------------------------------------ -->
<t>
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).
</t>
<t>
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.
</t>
<t>
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
(<xref target="sec:intro_to_bootstrap"/>).
The details of how to do that are out of the scope of this document.
</t>
<t>
With RSASSA-PKCS1-v1_5 (default) and RSASSA-PSS signatures (<xref target="sec:iana"/>),
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
<xref target="RFC4359"/>.
The key size, which in practice is also equal to the "RSA modulus", has major security
implications.
<xref target="RFC4359"/> 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.
</t>
</section>
</section> <!-- TESLA Parameters -->
<section title="TESLA Messages and Authentication Tag Format">
<!-- ------------------------------------ -->
<t>
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 (<xref target="sec:alc_norm_integration"/>),
the beginning of the following formats is not aligned on 32 bit word
boundaries.
</t>
<section title="Bootstrap Information Format" anchor="sec:bootstrap_info_format">
<!-- ------------------------------------ -->
<t>
When bootstrap information is sent in-band, the following message is
used:
<figure anchor='fig:bootstrap_info_format' title="Bootstrap information format.">
<preamble></preamble>
<artwork>
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 |S|W|A| ^
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | f
| d | PRF Type | MAC Func Type |WG MAC Fun Type| | i
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | f
| Signature Type| CryptoFunType | Signature Length | | i
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | x
| Reserved | T_int | | e
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | d
| | |
+ T_0 (NTP timestamp) + | l
| | | e
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | n
| N (Key Chain Length) | | g
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | t
| Current Interval Index i | v h
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
| |
~ 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Weak Group MAC (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
</t>
<t>
The format of the bootstrap information is depicted in
<xref target="fig:bootstrap_info_format"/>.
The fields are:</t>
<t>"Reserved" fields (5 bits):</t>
<t><list><t>
This is a reserved field that MUST be set to zero in this specification.
</t></list></t>
<t>"S" (Single Key Chain) flag (1 bits):</t>
<t><list><t>
The "S" flag indicates whether this TESLA session is restricted to a single
key chain (S==1) or relies on one or multiple key chains (S==0).
</t></list></t>
<t>"W" (Weak Group MAC Present) flag (1 bits):</t>
<t><list><t>
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).
</t></list></t>
<t>"A" flag (1 bit):</t>
<t><list><t>
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).
</t></list></t>
<!--
<t>"Sequence Number" field (8 bits):</t>
<t><list><t>
The "Sequence Number" is incremented by the sender each time a new bootstrap
information is sent, and reset by the sender each time a new "i" value is used.
Since wrapping is prohibited, there can be a maximum of 256 bootstrap messages
sent for a given "i" value.
The Tuple (sequence number; i) is meant to protect the receiver against replay
attacks, where the attacker stores a valid bootstrap information message and
replays it after a certain delay.
</t></list></t>
-->
<t>"d" field (8 bits):</t>
<t><list><t>
d is an unsigned integer that defines the key disclosure delay (in number of intervals).
d MUST be greater or equal to 2.
</t></list></t>
<t>"PRF Type" field (8 bits):</t>
<t><list><t>
"PRF Type" is the reference number of the f function used to derive
the F (for key chain) and F' (for MAC keys) functions (<xref target="sec:iana"/>).
</t></list></t>
<t>"MAC Function Type" field (8 bits):</t>
<t><list><t>
The "MAC Function Type" is the reference number of the function used to compute
the MAC of the packets (<xref target="sec:iana"/>).
</t></list></t>
<t>"Weak Group MAC Function Type" field (8 bits):</t>
<t><list><t>
When W==1, the "Weak Group MAC Function Type" fields contains the reference number
of the function used to compute the group MAC (<xref target="sec:iana"/>) of the packets,
including this bootstrap message.
When W==0, this field MUST be set to zero (i.e., denote an INVALID MAC function
<xref target="sec:iana"/>).
</t></list></t>
<t>"Signature Type" field (8 bits):</t>
<t><list><t>
The "Signature Type" is the reference number (<xref target="sec:iana"/>) of the digital
signature used to authenticate this bootstrap information and included in the
"Signature" field.
</t></list></t>
<t>"Signature Cryptographic Function Type" field (8 bits):</t>
<t><list><t>
The "Signature Cryptographic Function Type" is the reference number (<xref target="sec:iana"/>)
of the cryptographic function used within the digital signature.
</t></list></t>
<t>"Signature Key Length" field (12 bits):</t>
<t><list><t>
The "Signature Length" is an unsigned integer that indicates the signature field size in bytes
in the "Signature Extension" field.
</t></list></t>
<t>"Reserved" fields (16 bits):</t>
<t><list><t>
This is a reserved field that MUST be set to zero in this specification.
</t></list></t>
<t>"T_int" field (16 bits):</t>
<t><list><t>
T_int is an unsigned 16 bit integer that defines the interval duration (in milliseconds).
</t></list></t>
<t>"T_0" field (64 bits):</t>
<t><list><t>
"T_0" is an NTP timestamp that indicates the time when this session began.
</t></list></t>
<t>"N" field (32 bits):</t>
<t><list><t>
"N" is an unsigned integer that indicates the key chain length.
There are N + 1 keys per chain.
</t></list></t>
<t>"i" (Interval Index of K_i) field (32 bits):</t>
<t><list><t>
"i" is an unsigned integer that indicates the current interval index
when this bootstrap information message is sent.
</t></list></t>
<t>"Current Key Chain Commitment" field (variable size):</t>
<t><list><t>
"Key Chain Commitment" is the commitment to the current key chain,
i.e., the key chain corresponding to interval i.
For instance, with the first key chain, this commitment is equal to F(K_0),
with the second key chain, this commitment is equal to F(K_{N+1}), etc.).
If need be, this field is padded (with 0) up to a multiple of 32 bits.
</t></list></t>
<t>"Signature" field (variable size):</t>
<t><list><t>
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.
</t></list></t>
<t>"P" flag (optional, 1 bit if present):</t>
<t><list><t>
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).
</t></list></t>
<t>"D^O_t" field (optional, 63 bits if present):</t>
<t><list><t>
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.
<!--
<list><t>----- Editor's note: a first alternative would be to use floating
point arithmetic, IEEE754 for carrying D^O_t.
NTP timestamp difference is usually performed with double floating
point arithmetic internally (at least in TESLA and NTPv4 implementations),
so it makes sense. But it looks a bit awkward.
A second alternative would be to use a signed integer representing the
difference in sub-second units (e.g., in milliseconds). This is simple
but it requires NTP timestamp/ms conversions on both sides.
The use of the "P" flag seems simpler...
-----</t>
</list>
-->
</t></list></t>
<t>"Weak Group MAC" field (optional, variable length, multiple of 32 bits):</t>
<t><list><t>
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.
</t></list></t>
<t>
Note that 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 but variable length fields.
The remaining D^O_t and Weak Group MAC fields are optional.
</t>
<t>
In order to prevent attacks, some parameters MUST NOT be changed during the lifetime of the session
(<xref target="sec:time_int_schedule"/>, <xref target="sec:timing_params"/>).
The following table summarizes the parameters status:
</t>
<texttable>
<preamble></preamble>
<ttcol align='center' width='35%'>Parameter</ttcol>
<ttcol align='center'>Status</ttcol>
<c>S</c><c>static (during whole session)</c>
<c>W</c><c>static (during whole session)</c>
<c>A</c><c>static (during whole session)</c>
<c>T_O</c><c>static (during whole session)</c>
<c>T_int</c><c>static (during whole session)</c>
<c>d</c><c>static (during whole session)</c>
<c>N</c><c>static (during whole session)</c>
<c>D^O_t (if present)</c><c>static (during whole session)</c>
<c>PRF Type</c><c>static (during whole session)</c>
<c>MAC Function Type</c><c>static (during whole session)</c>
<c>Signature Type</c><c>static (during whole session)</c>
<c>Signature Crypto. Function Type</c><c>static (during whole session)</c>
<c>Signature Length</c><c>static (during whole session)</c>
<c>Weak Group MAC Func. Type</c><c>static (during whole session)</c>
<c>i</c><c>dynamic (related to current key chain)</c>
<c>K_i</c><c>dynamic (related to current key chain)</c>
<c>signature</c><c>dynamic, packet dependent</c>
<c>Weak Group MAC (if present)</c><c>dynamic, packet dependent</c>
</texttable>
</section><!-- -Bootstrap Information Format- -->
<section title="Format of a Direct Time Synchronization Response"
anchor='sec:direct_synch_response_format'>
<!-- ------------------------------------ -->
<t>
<figure anchor='fig:direct_synch_response_format'
title="Format of a Direct Time Synchronization Response">
<preamble></preamble>
<artwork>
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) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
</t>
<t>The response to a direct time synchronization request contains the following
information:</t>
<t>"Reserved" fields (8 bits):</t>
<t><list><t>
This is a reserved field that MUST be set to zero in this specification.
</t></list></t>
<t>"t_s" (NTP timestamp, 64 bits):</t>
<t><list><t>
t_s is an NTP timestamp that corresponds to the sender local time value when receiving
the direct time synchronization request message.
</t></list></t>
<t>"t_r" (NTP timestamp, 64 bits):</t>
<t><list><t>
t_r is an NTP timestamp that contains the receiver local time value received
in the direct time synchronization request message.
</t></list></t>
<t>"Signature" field (variable size):</t>
<t><list><t>
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.
</t></list></t>
<t>"Weak Group MAC" field (optional, variable length, multiple of 32 bits):</t>
<t><list><t>
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.
</t></list></t>
</section><!-- -Direct Time Synch Response Format- -->
<section title="Format of a Standard Authentication Tag" anchor='sec:auth_tag_format'>
<!-- ------------------------------------ -->
<t>
<figure anchor='fig:authentication_tag' title="Format of the authentication tag">
<preamble></preamble>
<artwork>
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) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
</t>
<t>
<xref target='fig:authentication_tag'/> shows the format of the authentication tag:</t>
<t>"Reserved" field (8 bits):</t>
<t><list><t>
The "Reserved" field is not used in the current specification
and MUST be set to zero by the sender.
</t></list></t>
<t>"i" (Interval Index) field (32 bits):</t>
<t><list><t>
i is the interval index associated to the key (K'_i) used to compute
the MAC of this packet.
</t></list></t>
<t>"Disclosed Key" (variable size):</t>
<t><list><t>
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.
</t></list></t>
<t>"MAC(K'_i, M)" (variable size):</t>
<t><list><t>
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.
</t></list></t>
<t>"Weak Group MAC" field (optional, variable length, multiple of 32 bits):</t>
<t><list><t>
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.
</t></list></t>
<t>
Note that because a key cannot be disclosed before the disclosure delay, d,
the sender MUST NOT use this tag during the first d intervals: {0 .. d-1} (inclusive).
Instead the sender MUST use Standard or Compact Authentication Tag Without Key
Disclosure.
</t>
</section>
<section title="Format of a Standard Authentication Tag Without Key Disclosure"
anchor='sec:auth_tag_wo_key_discl_format'>
<!-- ------------------------------------ -->
<t>
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.
This authentication tag or its compact version MUST also be used during the first
d intervals: {0 .. d-1} (inclusive).
</t>
<t>
<figure anchor='fig:authentication_tag_wo_key_discl' title="Format of the authentication tag without key disclosure">
<preamble></preamble>
<artwork>
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) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
</t>
</section>
<section title="Format of an Authentication Tag with a New Key Chain Commitment"
anchor='sec:auth_tag_format_new_kcc'>
<!-- ------------------------------------ -->
<t>
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.).
<xref target='fig:new_comm_tag'/> shows the corresponding format.
</t>
<t>
<figure anchor='fig:new_comm_tag' title="Format of the authentication tag with a new
key chain commitment">
<preamble></preamble>
<artwork>
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) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
</t>
</section><!-- -New key chain commitment- -->
<section title="Format of an Authentication Tag with a Last Key of Old Chain Disclosure"
anchor='sec:auth_tag_format_old_kck'>
<!-- ------------------------------------ -->
<t>
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.).
<xref target='fig:old_comm_tag'/> 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.
</t>
<t>
<figure anchor='fig:old_comm_tag' title="Format of the authentication tag with an old chain
last key disclosure">
<preamble></preamble>
<artwork>
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) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
</t>
</section><!-- -Old key chain commitment- -->
<section title="Format of the Compact Authentication Tags" anchor='sec:auth_tag_compact_format'>
<!-- ------------------------------------ -->
<t>
The four compact flavors of the Authentication tags follow.
</t>
<t>
<figure anchor='fig:compact_authentication_tag'
title="Format of the compact authentication tag">
<preamble></preamble>
<artwork>
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) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
</t>
<t>
<figure anchor='fig:compact_authentication_tag_wo_key_discl'
title="Format of the compact authentication tag without key disclosure">
<preamble></preamble>
<artwork>
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) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
</t>
<t>
<figure anchor='fig:compact_new_comm_tag'
title="Format of the compact authentication tag with a new key chain commitment">
<preamble></preamble>
<artwork>
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) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
</t>
<t>
<figure anchor='fig:compact_old_comm_tag'
title="Format of the compact authentication tag with a last key of old chain disclosure">
<preamble></preamble>
<artwork>
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) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
</t>
<t>
where:
</t>
<t>"i_LSB" (Interval Index Least Significant Byte) field (8 bits):</t>
<t><list><t>
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.
</t></list></t>
<t>"i_NSB" (Interval Index Next Significant Bytes) field (variable length, depending on the MAC type):</t>
<t><list><t>
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.
</t></list></t>
<t>
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.
</t>
<t>
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.
</t>
</section>
</section><!-- -Signaling Information Format- -->
</section><!-- =Sender= -->
<!-- ======================================================================= -->
<section title="Receiver Operations">
<!-- ==================================== -->
<section title="Initialization of a Receiver">
<!-- ------------------------------------ -->
<t>
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 (<xref target="sec:intro_to_bootstrap"/>).
Let's focus on the in-band mechanism.
Two actions must be performed:
<list style='symbols'>
<t>receive and process a bootstrap information message, and</t>
<t>calculate an upper bound of the sender's local time.
To that purpose, the receiver must perform time synchronization.</t>
</list>
</t>
<section title="Processing the Bootstrap Information Message" anchor="sec:recv_process_bootstrap">
<!-- ------------------------------------ -->
<t>
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.
<!--
Time synchronization is detailed in <xref target="sec:rx_time_synchro"/>.
The receiver stores the parameters related to the interval schedule
and key chain.
-->
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.
</t>
<t>
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).
</t>
</section>
<section title="Time Synchronization" anchor="sec:rx_time_synchro">
<!-- ------------------------------------ -->
<t>
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.
</t>
<section title="Direct Time Synchronization" anchor="sec:direct_synch_request_format">
<!-- ------------------------------------ -->
<t>
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.
</t>
<t>
The direct time synchronization request message format is the following:
</t>
<t>
<figure anchor='fig:direct_synch_request_format'
title="Format of a Direct Time Synchronization Request">
<preamble></preamble>
<artwork>
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) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
</t>
<t>The direct time synchronization request (<xref target="fig:direct_synch_request_format"/>)
contains the following information:</t>
<t>"t_r" (NTP timestamp, 64 bits):</t>
<t><list><t>
t_r is an NTP timestamp that contains the receiver local time value when
sending this direct time synchronization request message;
</t></list></t>
<t>"Weak Group MAC" field (optional, variable length, multiple of 32 bits):</t>
<t><list><t>
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.
</t></list></t>
<t>
<xref target="sec:direct_synch_response_format"/> specifies the
direct time synchronization response message format.
</t>
<t>
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.
</t>
</section>
<section title="Indirect Time Synchronization">
<!-- ------------------------------------ -->
<t>
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.
</t>
<t>
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.
</t>
<t>
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
(<xref target="sec:delay_bound_calc_indirect_sync"/>).
</t>
</section>
</section>
</section><!-- -Initialization of a Receiver- -->
<section title="Authentication of Received Packets" anchor="sec:auth_received_pkts_guidelines">
<!-- ------------------------------------ -->
<t>
The receiver can now authenticate incoming packets.
To that purpose, he MUST follow different steps (see <xref target="RFC4082"/> section 3.5):
<list style='numbers'>
<t>The receiver parses the different packet headers.
If none of the eight TESLA authentication tags is present, the receiver MUST
discard the packet.
If the session is in "Single Key Chain" mode (e.g., when the "S" flag is set
in the bootstrap information message), then the receiver MUST discard
any packet containing an authentication tag with a new key chain commitment
or an authentication tag with a last key of old chain disclosure.
</t>
<t> 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:
<list style='symbols'>
<t> with a non compact authentication tag, the "i" interval
index is available. Get it from the header.
</t>
<t>
When a compact authentication tag is used, the receiver must
compute the corresponding "i" interval index from the "i_LSB"
and perhaps "i_NSB" fields. The following algorithm is used:
<figure>
<artwork>
if (MAC(K'_i, M) is not padded) {
// with HMAC-SHA-256 and higher, the i_LSB field is the only
// field available to guess i.
i_mask = 0xFFFFFF00;
i_low = i_LSB; // lower bits of "i"
} else {
// with a two byte padding (i.e., HMAC-SHA-1 and HMAC-SHA-224),
// the 2 byte i_NSB field is available in addition to i_LSB.
i_mask = 0xFF000000;
i_low = i_LSB + i_NSB; // lower bits of "i"
}
i_high = highest_i & i_mask; // (guessed) higher bits of "i", using
// the highest interval the sender can
// possibly be in.
i = i_high + i_low; // raw guessed "i"
if (i > highest_i) {
// cycling took place. Since "i" cannot be larger than "highest_i",
// decrement it.
i_cycle = (~i_mask) + 1; // length of a cycle
i = i - i_cycle;
}
</artwork>
</figure>
</t>
</list>
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.
</t>
<t> 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.
</t>
<!--
<t> New key index test: Next the receiver checks whether a key K_v
has already been disclosed with the same index v as the
current disclosed key K_{i-d}, or with a later one; that is,
with v >= i-d.
</t>
<t> Key verification test: If the disclosed key index is new, the
receiver checks the legitimacy of K_{i-d} by verifying, for
some earlier disclosed key K_v (with v < i-d), that
K_v = F^{i-d- v}(K_{i-d}).
In other words, the receiver checks the disclosed key by
computing the necessary number of PRF functions to obtain a
previously safe disclosed key.
If the key verification fails, the receiver MUST discard the packet.
If the key verification succeeds, this key is said legitimate.
</t>
-->
<t> 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 a last key of old chain disclosure), the following tests are
performed:
<list style='symbols'>
<t> New key index test: the receiver checks whether a legitimate key
already exists with the same index (i.e., i-d), or with an index
strictly superior (i.e., with an index > i-d).
If such a legitimate key exists, the receiver ignores the current
disclosed key and skips the "Key verification test".
</t>
<t> Key verification test: If the disclosed key index is new, the
receiver checks the legitimacy of K_{i-d} by verifying, for
some earlier disclosed and legitimate key K_v (with v < i-d), that
K_v = F^{i-d-v}(K_{i-d}).
In other words, the receiver checks the disclosed key by
computing the necessary number of PRF functions to obtain a
previously disclosed and legitimate (i.e., verified) key.
If the key verification fails, the receiver MUST discard the packet.
If the key verification succeeds, this key is said legitimate and
is stored by the receiver.
</t>
</list>
</t>
<!--
<t> 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.
</t>
-->
<t>When applicable, the receiver performs congestion control, even if the packet has
not yet been authenticated <xref target="draft-ietf-rmt-bb-lct-revised"/>.
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.
</t>
<t>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).
In some situations, this packet might also be discarded later on, if
it turns out that the receiver will never be able to deduce the associated key.
</t>
<t>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 does not equal the MAC stored in the packet, the receiver
MUST discard the packet.
If the two MAC are equal, the packet is successfully authenticated and the
receiver continues processing it.
</t>
<t>Authenticated new key chain commitment processing:
If the authenticated packet contains a new key chain commitment and if
no verified commitment already exists, then the receiver stores the
commitment to the new key chain.
Then, if there are non authenticated packets for a previous chain
(i.e., the key chain before the current one), all these packets can be
discarded (<xref target="sec:flushing_pkts_of_prev_key_chain"/>).
</t>
<t>The receiver continues the ALC or NORM processing of all the packets
authenticated during the authentication test.
</t>
</list></t>
<t>
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.
</t>
</section><!-- -Receiving authenticated data- -->
<section title="Flushing the Non Authenticated Packets of a Previous Key Chain"
anchor="sec:flushing_pkts_of_prev_key_chain">
<!-- ------------------------------------ -->
<t>
In some cases a receiver having experienced a very long disconnection might
have lost all the disclosures of the last key(s) of a previous key chain.
Let j be the index of this key chain for which there remains non authenticated
packets.
This receiver can flush all the packets of the key chain j if he determines that:
<list style='symbols'>
<t>he has just switched to a chain of index j+2 (inclusive) or higher; </t>
<t>the sender has sent a commitment to the new key chain of index j+2
(<xref target="sec:value_of_tx_lastkey_tx_newkcc"/>).
This situation requires that the receiver has received a packet containing
such a commitment and that he has been able to check its integrity.
In some cases it might require to receive a bootstrap information message
for the current key chain.</t>
</list>
If one of the above two tests succeeds, the sender can discard all the awaiting
packets since there is no way to authenticate them.
</t>
</section><!-- -Flushing non auth pkts- -->
</section><!-- =Receiver= -->
<!-- ======================================================================= -->
<section title="Integration in the ALC and NORM Protocols"
anchor='sec:alc_norm_integration'>
<!-- ------------------------------------ -->
<section title="Authentication Header Extension Format"
anchor='sec:auth_he_format'>
<!-- ------------------------------------ -->
<t>
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 <xref target="draft-ietf-rmt-bb-lct-revised"/>.
</t>
<t>
<list><t>----- 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.
-----</t>
</list>
</t>
<t>
Several fields are added in addition to the HET (Header Extension Type) and HEL
(Header Extension Length) fields (<xref target="lct_integration"/>).
</t>
<t>
<figure title='Format of the TESLA EXT_AUTH header extension.'
anchor='lct_integration'>
<artwork>
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 |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
</t>
<t>
The fields of the TESLA EXT_AUTH header extension are:</t>
<t>"ASID" (Authentication Scheme Identifier) field (4 bits):</t>
<t><list><t>
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.
</t></list></t>
<t>"Type" field (4 bits):</t>
<t><list><t>
The "Type" field identifies the type of TESLA information carried
in this header extension.
This specification defines the following types:
<list style='symbols'>
<t>0: bootstrap information, sent by the sender periodically
or after a direct time synchronization request;</t>
<t>1: standard authentication tag for the on-going key chain, sent by
the sender along with a packet;</t>
<t>2: authentication tag without key disclosure, sent by
the sender along with a packet;</t>
<t>3: authentication tag with a new key chain commitment,
sent by the sender when approaching the end of a key chain;</t>
<t>4: authentication tag with a last key of old chain disclosure,
sent by the sender some time after moving to a new key chain;</t>
<t>5: compact (i.e., that contains the last byte of the interval index)
authentication tag
for the on-going key chain, sent by the sender along with a packet;</t>
<t>6: compact (i.e., that contains the last byte of the interval index)
authentication tag without any key disclosure, sent by the sender
along with a packet;</t>
<t>7: compact (i.e., that contains the last byte of the interval index)
authentication tag with a new key chain commitment,
sent by the sender when approaching the end of a key chain;</t>
<t>8: compact (i.e., that contains the last byte of the interval index)
authentication tag with a last key of old chain disclosure,
sent by the sender some time after moving to a new key chain;</t>
<t>9: direct time synchronization request, sent by a NORM receiver.
This type of message is invalid in case of an ALC session
since ALC is restricted to unidirectional transmissions.
Yet an external mechanism may provide
the direct time synchronization functionality.
How this is done is out of the scope of this document;</t>
<t>10: direct time synchronization response, sent by a NORM sender.
This type of message is invalid in case of an ALC session
since ALC is restricted to unidirectional transmissions.
Yet an external mechanism may provide
the direct time synchronization functionality.
How this is done is out of the scope of this document;</t>
</list>
</t></list></t>
<t>"Content" field (variable length):</t>
<t><list><t>
This is the TESLA information carried in the header extension, whose
type is given by the "Type" field.
</t></list></t>
</section>
<section title="Use of Authentication Header Extensions"
anchor='sec:auth_he_use'>
<!-- ------------------------------------ -->
<t>
Each packet sent by the session's sender MUST contain exactly one
TESLA EXT_AUTH header extension.
</t>
<t>
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.
</t>
<section title="EXT_AUTH Header Extension of Type Bootstrap Information"
anchor='sec:auth_he_use_bootstrap'>
<!-- ------------------------------------ -->
<t>
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.
</t>
<t>
With ALC, the "bootstrap information" TESLA EXT_AUTH MUST be sent in a
control packet, i.e., containing no encoding symbol.
</t>
<t>
With NORM, the "bootstrap information" TESLA EXT_AUTH MUST be sent in a
NORM_CMD(APPLICATION) message.
</t>
<t>
<figure anchor='fig:bootstrap_with_1024b_sig'
title="Example: Format of the bootstrap information message (Type 0),
using SHA-1/1024 bit signatures, the default HMAC-SHA-1 and a Weak Group MAC.">
<preamble></preamble>
<artwork>
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|1|0| ^
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| d | 1 | 1 | 1 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| 1 | 1 | 128 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| 0 (reserved) | T_int | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | |
+ T_0 (NTP timestamp) + | 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
| Weak Group MAC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
</t>
<t>
For instance <xref target="fig:bootstrap_with_1024b_sig"/> shows the bootstrap information
message when using the HMAC-SHA-1 transform for the PRF, MAC, and Weak Group MAC functions,
along with SHA-1/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 184 byte long (i.e., 46 words of 32 bits).
</t>
</section>
<section title="EXT_AUTH Header Extension of Type Authentication Tag"
anchor='sec:auth_he_use_auth_info'>
<!-- ------------------------------------ -->
<t>
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.
</t>
<t>
<figure anchor='fig:example_compact_authentication_tag'
title="Example: Format of the standard authentication tag (Type 5), using the default HMAC-SHA-1.">
<preamble></preamble>
<artwork>
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
</t>
<t>
<figure anchor='fig:example_compact_authentication_tag_wo_key_discl'
title="Example: Format of the compact authentication tag without key disclosure (Type 6),
using the default HMAC-SHA-1.">
<preamble></preamble>
<artwork>
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
</t>
<t>
For instance, <xref target='fig:example_compact_authentication_tag'/> and
<xref target='fig:example_compact_authentication_tag_wo_key_discl'/>
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.
</t>
</section>
<section title="EXT_AUTH Header Extension of Type Direct Time Synchronization Request"
anchor='sec:auth_he_use_direct_synch_req'>
<!-- ------------------------------------ -->
<t>
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.
</t>
<t>
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.
</t>
<t>
In case of direct time synchronization, it is RECOMMENDED that the
receivers spread the transmission of direct time synchronization
requests over the time (<xref target="sec:intro_to_direct_time_sync"/>).
</t>
</section>
<section title="EXT_AUTH Header Extension of Type Direct Time Synchronization Response"
anchor='sec:auth_he_use_direct_synch_resp'>
<!-- ------------------------------------ -->
<t>
With NORM, the "direct time synchronization response" TESLA EXT_AUTH (Type==8)
MUST be sent by the sender in a NORM_CMD(APPLICATION) message.
</t>
<t>
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.
</t>
</section>
</section>
</section><!-- -LCT or NORM integration- -->
<section title="IANA Considerations" anchor="sec:iana">
<!-- ==================================== -->
<t>This document requires a IANA registration for the following attributes:</t>
<t>Cryptographic Pseudo-Random Function, TESLA-PRF:
All implementations MUST support HMAC-SHA-1 (default).</t>
<texttable>
<preamble></preamble>
<ttcol align='center'>PRF name</ttcol>
<ttcol align='center'>Value</ttcol>
<ttcol align='center'>n_p and n_f</ttcol>
<c>INVALID</c> <c>0</c> <c>N/A</c>
<c>HMAC-SHA-1 (default)</c> <c>1</c> <c>160 bits (20 bytes)</c>
<c>HMAC-SHA-224</c> <c>2</c> <c>224 bits (28 bytes)</c>
<c>HMAC-SHA-256</c> <c>3</c> <c>256 bits (32 bytes)</c>
<c>HMAC-SHA-384</c> <c>4</c> <c>384 bits (48 bytes)</c>
<c>HMAC-SHA-512</c> <c>5</c> <c>512 bits (64 bytes)</c>
</texttable>
<t>Cryptographic Message Authentication Code (MAC):
All implementations MUST support HMAC-SHA-1 (default).</t>
<texttable>
<preamble></preamble>
<ttcol align='center'>MAC name</ttcol>
<ttcol align='center'>Value</ttcol>
<ttcol align='center'>n_m</ttcol>
<ttcol align='center'>n_w</ttcol>
<c>INVALID</c> <c>0</c> <c>N/A</c> <c>N/A</c>
<c>HMAC-SHA-1 (default)</c> <c>1</c> <c>80 bits (10 bytes)</c> <c>32 bits (4 bytes)</c>
<c>HMAC-SHA-224</c> <c>2</c> <c>112 bits (14 bytes)</c> <c>32 bits (4 bytes)</c>
<c>HMAC-SHA-256</c> <c>3</c> <c>128 bits (16 bytes)</c> <c>32 bits (4 bytes)</c>
<c>HMAC-SHA-384</c> <c>4</c> <c>192 bits (24 bytes)</c> <c>32 bits (4 bytes)</c>
<c>HMAC-SHA-512</c> <c>5</c> <c>256 bits (32 bytes)</c> <c>32 bits (4 bytes)</c>
</texttable>
<t>Signature Encoding Algorithm:
All implementations MUST support RSASSA-PKCS1-v1_5 (default).</t>
<texttable>
<preamble></preamble>
<ttcol align='center'>Signature Algorithm Name</ttcol>
<ttcol align='center'>Value</ttcol>
<c>INVALID</c><c>0</c>
<c>RSASSA-PKCS1-v1_5 (default)</c><c>1</c>
<c>RSASSA-PSS</c><c>2</c>
</texttable>
<t>Signature Cryptographic Function:
All implementations MUST support SHA-1 (default).</t>
<texttable>
<preamble></preamble>
<ttcol align='center'>Cryptographic Function Name</ttcol>
<ttcol align='center'>Value</ttcol>
<c>INVALID</c><c>0</c>
<c>SHA-1 (default)</c><c>1</c>
</texttable>
</section>
<section title="Security Considerations">
<!-- ==================================== -->
<t>
<xref target="RFC4082"/> discusses the security of TESLA in general.
These considerations apply to the present specification, namely:
<list style='symbols'>
<t>great care must be taken to the timing aspects. In particular the D_t parameter
is critical and must be initialized correctly, depending on the use-case;</t>
<t>if the key disclosure schedule is to be changed (e.g., because the sender
realizes that the parameters do not meet the receiver requirements), then
this change MUST NOT be announced in-line, within the session.
Indeed, a receiver that missed the announcement would be vulnerable to
attacks.
Note that in the current specification, the parameters that define the
key disclosure schedule MUST be fixed during the whole session
(<xref target="sec:time_int_schedule"/>).
</t>
<t>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 located between these components inject faked data.
Similarly, when the verifier and the secure timing system are two
different components, there is a risk that an attacker located between
these components inject faked timing information.
For instance, when the verifier reads the local time by means of a
dedicated system call (e.g., gettimeofday()), if an attacker controls
the host, he may catch the system call and return a faked time information.
</t>
</list>
The current specification discusses additional aspects with more details.
</t>
<section title="Dealing With DoS Attacks">
<!-- ------------------------------------ -->
<t>
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, <xref target="sec:auth_received_pkts_guidelines"/>).
</t>
<t>
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 (<xref target="sec:group_auth_tag"/>).
</t>
<t>
Generally, it is RECOMMENDED that the amount of memory used to store
incoming packets waiting to be authenticated be limited to a reasonable
value.
</t>
</section>
<section title="Dealing With Replay Attacks">
<!-- ------------------------------------ -->
<t>
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:
<list style='symbols'>
<t> within the TESLA protocol, and</t>
<t> within the ALC or NORM protocol.</t>
</list>
</t>
<section title="Impacts of Replay Attacks on TESLA">
<!-- ------------------------------------ -->
<t>
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:
<list style='symbols'>
<t> bootstrap information:
since most parameters contained in a bootstrap information message
are static, replay attacks have no consequences.
The fact that the "i" and "K_i" fields can be updated in subsequent
bootstrap information messages does not create a problem either,
since all "i" and "K_i" fields sent remain valid.
Finally, a receiver that successfully initialized its TESLA component
should ignore the following messages (<xref target="sec:recv_process_bootstrap"/>),
which voids replay attacks.
</t>
<t> direct time synchronization request:
If the Weak Group MAC scheme is used, an attacker that is not member of
the group can replay a packet and oblige the sender to to respond, which
requires to digitally sign the response, a time-consuming process.
If the Weak Group MAC scheme is not used, an attack can anyway easily
forge a request.
In both cases, the attack will not compromise TESLA component, but might
create a DoS.
If this is a concern, it is RECOMMENDED, when the Weak Group MAC scheme is used,
that the sender verify the "t_r" NTP timestamp contained in the request
and respond only if this value is strictly larger than the previous one
received from this receiver.
When the Weak Group MAC scheme is not used, this attack can be mitigated
by limiting the number of requests per second that will be processed.
</t>
<t> direct time synchronization response:
Upon receiving a response, a receiver who has no pending request
MUST immediately drop the packet.
If this receiver that previously issued a request, he first checks
the Weak Group MAC (if applicable), then the "t_r" field, to be sure
it is a response to his request, and finally the digital signature.
A replayed packet will be dropped during these verifications, without
compromising the TESLA component.
</t>
<t> other messages, containing an authentication tag:
Replaying a packet containing a TESLA authentication tag will never
compromise the TESLA component itself (but perhaps the underlying
ALC or NORM component, see below).
</t>
</list>
To conclude, TESLA itself is robust in front of replay attacks.
</t>
</section>
<section title="Impacts of Replay Attacks on NORM">
<!-- ------------------------------------ -->
<t>
We review here the potential impacts of a replay attack on the NORM component.
</t>
<t>
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 <xref target="draft-ietf-rmt-pi-norm-revised"/> 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.
</t>
<t>
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.
</t>
</section>
<section title="Impacts of Replay Attacks on ALC">
<!-- ------------------------------------ -->
<t>
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.
</t>
<t>
First, let us consider replay attacks within a given ALC session:
<list style='symbols'>
<t>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 will be silently discarded.
This kind of replay attack is only penalizing in terms of memory and
processing load, but does not compromise the ALC behavior.
</t>
<t>Control packets containing an authentication tag:
ALC control packets, by definition, do not include any encoding symbol
and therefore do not include any object/block/symbol identifier that would
enable a receiver to identify duplicates.
However, a sender has a very limited number of reasons to send control packets.
More precisely:
<list style='symbols'>
<t>At the end of the session, a "close session" packet is sent.
Replaying this packet has no impact since the receivers already left.</t>
<t>The same remark can be done for the "close object" packets.</t>
</list>
</t>
</list>
This analysis shows that ALC itself is robust in front of replay attacks
within the same session.
</t>
<t>
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.
</t>
</section>
</section>
</section>
<section title="Acknowledgments">
<!-- ==================================== -->
<t>
The authors are grateful to Ran Canetti, David L. Mills and Lionel Giraud for their valuable
comments while preparing this document.
</t>
</section>
</middle>
<back>
<references title="Normative References">
<!-- ==================================== -->
<reference anchor="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials="S." surname="Bradner">
<organization />
</author>
<date month="March" year="1997" />
</front>
<seriesInfo name="RFC" value="2119" />
<seriesInfo name="BCP" value="14" />
</reference>
<reference anchor="RFC4082">
<front>
<title>Timed Efficient Stream Loss-Tolerant Authentication (TESLA):
Multicast Source Authentication Transform Introduction
</title>
<author initials="A." surname="Perrig" fullname="A. Perrig">
<organization/></author>
<author initials="D." surname="Song" fullname="D. Song">
<organization/></author>
<author initials="R." surname="Canetti" fullname="R. Canetti">
<organization/></author>
<author initials="J.D." surname="Tygar" fullname="J.D. Tygar">
<organization/></author>
<author initials="B." surname="Briscoe" fullname="B. Briscoe">
<organization/></author>
<date year="2005" month="June"/>
</front>
<seriesInfo name="RFC" value="4082"/>
<format type="TXT" octets="54316" target="ftp://ftp.isi.edu/in-notes/rfc4082.txt"/>
</reference>
<!--
<reference anchor='RFC3450'>
<front>
<title>Asynchronous Layered Coding (ALC) Protocol Instantiation</title>
<author initials='M.' surname='Luby' fullname='M. Luby'>
<organization /></author>
<author initials='J.' surname='Gemmell' fullname='J. Gemmell'>
<organization /></author>
<author initials='L.' surname='Vicisano' fullname='L. Vicisano'>
<organization /></author>
<author initials='L.' surname='Rizzo' fullname='L. Rizzo'>
<organization /></author>
<author initials='J.' surname='Crowcroft' fullname='J. Crowcroft'>
<organization /></author>
<date year='2002' month='December' />
</front>
<seriesInfo name='RFC' value='3450' />
<format type='TXT' octets='86022' target='ftp://ftp.isi.edu/in-notes/rfc3450.txt' />
</reference>
<reference anchor="RFC3451">
<front>
<title>Layered Coding Transport (LCT) Building Block</title>
<author initials="M." surname="Luby" fullname="M. Luby">
<organization/></author>
<author initials="J." surname="Gemmell" fullname="J. Gemmell">
<organization/></author>
<author initials="L." surname="Vicisano" fullname="L. Vicisano">
<organization/></author>
<author initials="L." surname="Rizzo" fullname="L. Rizzo">
<organization/></author>
<author initials="M." surname="Handley" fullname="M. Handley">
<organization/></author>
<author initials="J." surname="Crowcroft" fullname="J. Crowcroft">
<organization/></author>
<date year="2002" month="December"/>
</front>
<seriesInfo name="RFC" value="3451"/>
<format type="TXT" octets="72594" target="ftp://ftp.isi.edu/in-notes/rfc3451.txt"/>
</reference>
-->
<reference anchor="draft-ietf-rmt-pi-alc-revised">
<front>
<title>Asynchronous Layered Coding (ALC) Protocol Instantiation</title>
<author initials='M.' surname='Luby'>
<organization />
</author>
<author initials="M." surname="Watson">
<organization/>
</author>
<author initials='L.' surname='Vicisano'>
<organization />
</author>
<date month="November" year="2007"/>
</front>
<seriesInfo name="" value="draft-ietf-rmt-pi-alc-revised-05.txt (work in progress)"/>
</reference>
<reference anchor="draft-ietf-rmt-bb-lct-revised">
<front>
<title>Layered Coding Transport (LCT) Building Block</title>
<author initials='M.' surname='Luby'>
<organization />
</author>
<author initials="M." surname="Watson">
<organization/>
</author>
<author initials='L.' surname='Vicisano'>
<organization />
</author>
<date month="November" year="2007"/>
</front>
<seriesInfo name="" value="draft-ietf-rmt-bb-lct-revised-06.txt (work in progress)"/>
</reference>
<!--
<reference anchor="RFC3926">
<front>
<title>FLUTE - File Delivery over Unidirectional Transport</title>
<author initials="T." surname="Paila" fullname="T. Paila">
<organization/></author>
<author initials="M." surname="Luby" fullname="M. Luby">
<organization/></author>
<author initials="R." surname="Lehtonen" fullname="R. Lehtonen">
<organization/></author>
<author initials="V." surname="Roca" fullname="V. Roca">
<organization/></author>
<author initials="R." surname="Walsh" fullname="R. Walsh">
<organization/></author>
<date year="2004" month="October"/>
</front>
<seriesInfo name="RFC" value="3926"/>
<format type="TXT" octets="81224" target="ftp://ftp.isi.edu/in-notes/rfc3926.txt"/>
</reference>
<reference anchor="RFC3940">
<front>
<title>Negative-acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Protocol</title>
<author initials="B." surname="Adamson" fullname="B. Adamson">
<organization/></author>
<author initials="C." surname="Bormann" fullname="C. Bormann">
<organization/></author>
<author initials="M." surname="Handley" fullname="M. Handley">
<organization/></author>
<author initials="J." surname="Macker" fullname="J. Macker">
<organization/></author>
<date year="2004" month="November"/>
</front>
<seriesInfo name="RFC" value="3940"/>
<format type="TXT" octets="220549" target="ftp://ftp.isi.edu/in-notes/rfc3940.txt"/>
</reference>
-->
<reference anchor="draft-ietf-rmt-pi-norm-revised">
<front>
<title>Negative-acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Protocol</title>
<author initials="B." surname="Adamson" fullname="B. Adamson">
<organization/></author>
<author initials="C." surname="Bormann" fullname="C. Bormann">
<organization/></author>
<author initials="M." surname="Handley" fullname="M. Handley">
<organization/></author>
<author initials="J." surname="Macker" fullname="J. Macker">
<organization/></author>
<date year="2007" month="March"/>
</front>
<seriesInfo name="" value="draft-ietf-rmt-pi-norm-revised-05.txt (work in progress)"/>
</reference>
<!--
<reference anchor="RFC3941">
<front>
<title>Negative-Acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Building Blocks</title>
<author initials="B." surname="Adamson" fullname="B. Adamson">
<organization/></author>
<author initials="C." surname="Bormann" fullname="C. Bormann">
<organization/></author>
<author initials="M." surname="Handley" fullname="M. Handley">
<organization/></author>
<author initials="J." surname="Macker" fullname="J. Macker">
<organization/></author>
<date year="2004" month="November"/>
</front>
<seriesInfo name="RFC" value="3941"/>
<format type="TXT" octets="92785" target="ftp://ftp.isi.edu/in-notes/rfc3941.txt"/>
</reference>
-->
</references>
<references title="Informative References">
<!-- ==================================== -->
<reference anchor="Perrig04">
<front>
<title>Secure Broadcast Communication in Wired and Wireless Networks</title>
<author initials="A." surname="Perrig" fullname="A. Perrig">
<organization /></author>
<author initials="J.D." surname="Tygar" fullname="J.D. Tygar">
<organization/></author>
<date year="2004" />
</front>
<seriesInfo name="Kluwer Academic Publishers" value="ISBN 0-7923-7650-1"/>
</reference>
<!--
<reference anchor="tesla/spec">
<front>
<title>TESLA: Multicast Source Authentication Transform Specification</title>
<author initials="A." surname="Perrig">
<organization />
</author>
<author initials="R." surname="Canetti">
<organization />
</author>
<author initials="B." surname="Whillock">
<organization />
</author>
<date month="October" year="2002" />
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-msec-tesla-spec-00.txt"/>
<seriesInfo name="" value="NB: REFERENCE TO REMOVE"/>
</reference>
-->
<reference anchor="RFC4442">
<front>
<title>Bootstrapping Timed Efficient Stream Loss-Tolerant Authentication (TESLA)</title>
<author initials="S." surname="Fries" fullname="S. Fries">
<organization/>
</author>
<author initials="H." surname="Tschofenig" fullname="H. Tschofenig">
<organization/>
</author>
<date month="March" year="2006"/>
</front>
<seriesInfo name="RFC" value="4442"/>
<format type="TXT" octets="37345" target="ftp://ftp.isi.edu/in-notes/rfc4442.txt"/>
</reference>
<reference anchor="RFC4383">
<front>
<title>
The Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Secure Real-time Transport Protocol (SRTP)
</title>
<author initials="M." surname="Baugher" fullname="M. Baugher"><organization/></author>
<author initials="E." surname="Carrara" fullname="E. Carrara"><organization/></author>
<date year="2006" month="February"/>
</front>
<seriesInfo name="RFC" value="4383"/>
<format type="TXT" octets="41766" target="ftp://ftp.isi.edu/in-notes/rfc4383.txt"/>
</reference>
<reference anchor="RFC3711">
<front>
<title>The Secure Real-time Transport Protocol (SRTP)</title>
<author initials="M." surname="Baugher" fullname="M. Baugher"><organization/></author>
<author initials="D." surname="McGrew" fullname="D. McGrew"><organization/></author>
<author initials="M." surname="Naslund" fullname="M. Naslund"><organization/></author>
<author initials="E." surname="Carrara" fullname="E. Carrara"><organization/></author>
<author initials="K." surname="Norrman" fullname="K. Norrman"><organization/></author>
<date year="2004" month="March"/>
</front>
<seriesInfo name="RFC" value="3711"/>
<format type="TXT" octets="134270" target="ftp://ftp.isi.edu/in-notes/rfc3711.txt"/>
</reference>
<reference anchor="draft-ietf-rmt-flute-revised">
<front>
<title>FLUTE - File Delivery over Unidirectional Transport</title>
<author initials='T.' surname='Paila'> <organization /></author>
<author initials="R." surname="Walsh"> <organization/></author>
<author initials='M.' surname='Luby'> <organization /></author>
<author initials='R.' surname='Lehtonen'> <organization /></author>
<author initials='V.' surname='Roca'> <organization /></author>
<date month="October" year="2007"/>
</front>
<seriesInfo name="" value="draft-ietf-rmt-flute-revised-05.txt (work in progress)"/>
</reference>
<reference anchor="RFC4359">
<front>
<title>
The Use of RSA/SHA-1 Signatures within Encapsulating Security Payload (ESP) and Authentication Header (AH)
</title>
<author initials="B." surname="Weis" fullname="B. Weis"><organization/></author>
<date year="2006" month="January"/>
</front>
<seriesInfo name="RFC" value="4359"/>
<format type="TXT" octets="26989" target="ftp://ftp.isi.edu/in-notes/rfc4359.txt"/>
</reference>
<reference anchor="draft-ietf-ntp-ntpv4-proto">
<front>
<title>The Network Time Protocol Version 4 Protocol Specification</title>
<author initials="J." surname="Burbank" fullname="Jack Burbank"><organization/></author>
<author initials="W." surname="Kasch" fullname="W. Kasch"><organization/></author>
<author initials="J." surname="Martin" fullname="J. Martin"><organization/></author>
<author initials="D." surname="Mills" fullname="David L. Mills"><organization/></author>
<date month="May" year="2007"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-ntp-ntpv4-proto-07.txt"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-ntp-ntpv4-proto-07.txt"/>
</reference>
<!--
<reference anchor="Neumann05">
<front>
<title>Large Scale Content Distribution Protocols</title>
<author initials="C." surname="Neumann" fullname="Christoph Neumann">
<organization/>
</author>
<author initials="V." surname="Roca" fullname="Vincent Roca">
<organization/>
</author>
<author initials="R." surname="Walsh" fullname="Rod Walsh">
<organization/>
</author>
<date year="2005" month="October"/>
</front>
<seriesInfo name="" value="ACM Computer Communication Review (CCR), Vol. 35 No. 5"/>
</reference>
-->
<reference anchor="RFC1305">
<front>
<title>Network Time Protocol (Version 3) Specification, Implementation</title>
<author initials="D." surname="Mills" fullname="David L. Mills">
<organization />
</author>
<date year="1992" month="March"/>
</front>
<seriesInfo name="RFC" value="1305"/>
<format type="TXT" octets="307085" target="ftp://ftp.isi.edu/in-notes/rfc1305.txt"/>
<format type="PDF" octets="442493" target="ftp://ftp.isi.edu/in-notes/rfc1305.pdf"/>
</reference>
<reference anchor="RFC4330">
<front>
<title>Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI</title>
<author initials="D." surname="Mills" fullname="David L. Mills">
<organization/>
</author>
<date year="2006" month="January"/>
</front>
<seriesInfo name="RFC" value="4330"/>
<format type="TXT" octets="67930" target="ftp://ftp.isi.edu/in-notes/rfc4330.txt"/>
</reference>
<reference anchor="RFC2104">
<front>
<title abbrev="HMAC">HMAC: Keyed-Hashing for Message Authentication</title>
<author initials="H." surname="Krawczyk" fullname="Hugo Krawczyk">
<organization>IBM, T.J. Watson Research Center</organization>
</author>
<author initials="M." surname="Bellare" fullname="Mihir Bellare">
<organization>University of California at San Diego, Dept of Computer Science and Engineering</organization>
</author>
<author initials="R." surname="Canetti" fullname="Ran Canetti">
<organization>IBM T.J. Watson Research Center</organization>
</author>
<date year="1997" month="February"/>
</front>
<seriesInfo name="RFC" value="2104"/>
<format type="TXT" octets="22297" target="ftp://ftp.isi.edu/in-notes/rfc2104.txt"/>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:06:32 |