RMT V. Roca
Internet-Draft A. Francillon
Expires: August 28, 2006 S. Faurite
INRIA
February 24, 2006
The Use of TESLA in the ALC and NORM Protocols
draft-faurite-rmt-tesla-for-alc-norm-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 28, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document explains how to integrate the TESLA source
authentication and packet integrity protocol to the ALC and NORM
content delivery protocols. This document only considers the
authentication/integrity of the packets generated by the session's
sender.
Roca, et al. Expires August 28, 2006 [Page 1]
Internet-Draft TESLA in ALC and NORM February 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions Used in this Document . . . . . . . . . . . . 4
1.2. Terminology and Notations . . . . . . . . . . . . . . . . 4
2. Using TESLA with ALC and NORM . . . . . . . . . . . . . . . . 6
2.1. ALC and NORM Specificities that Impact TESLA . . . . . . . 6
2.2. The Need for Secure Time Synchronization . . . . . . . . . 7
2.2.1. Direct Time Synchronization . . . . . . . . . . . . . 7
2.2.2. Indirect Time Synchronization . . . . . . . . . . . . 7
3. Sender Operations . . . . . . . . . . . . . . . . . . . . . . 9
3.1. TESLA Parameters . . . . . . . . . . . . . . . . . . . . . 9
3.1.1. Key Chains . . . . . . . . . . . . . . . . . . . . . . 9
3.1.2. Time Interval Schedule . . . . . . . . . . . . . . . . 10
3.2. TESLA Messages and Authentication Tags . . . . . . . . . . 10
3.2.1. Bootstrap Information . . . . . . . . . . . . . . . . 10
3.2.2. Direct Time Synchronization Response . . . . . . . . . 11
3.2.3. Authentication Tag . . . . . . . . . . . . . . . . . . 12
3.3. TESLA Messages and Authentication Tag Format . . . . . . . 12
3.3.1. Bootstrap Information Format . . . . . . . . . . . . . 12
3.3.2. Format of a Direct Time Synchronization Response . . . 18
3.3.3. Format of a Standard Authentication Tag . . . . . . . 19
3.3.4. Format of an Authentication Tag with a New Key
Chain Commitment . . . . . . . . . . . . . . . . . . . 19
3.3.5. Format of an Authentication Tag with an Old Chain
Last Key Disclosure . . . . . . . . . . . . . . . . . 20
4. Receiver Operations . . . . . . . . . . . . . . . . . . . . . 21
4.1. Initialization of a Receiver . . . . . . . . . . . . . . . 21
4.1.1. Processing the Bootstrap Information Message . . . . . 21
4.1.2. Time Synchronization . . . . . . . . . . . . . . . . . 21
4.1.3. Format of a Direct Time Synchronization Request . . . 22
4.2. Authentication of Received Packets . . . . . . . . . . . . 23
5. Integration in the ALC and NORM Protocols . . . . . . . . . . 24
5.1. Authentication Header Extension Format . . . . . . . . . . 24
5.2. Use of Authentication Header Extensions . . . . . . . . . 26
5.3. Managing Silent Periods . . . . . . . . . . . . . . . . . 26
6. Security Considerations . . . . . . . . . . . . . . . . . . . 28
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
8.1. Normative References . . . . . . . . . . . . . . . . . . . 30
8.2. Informative References . . . . . . . . . . . . . . . . . . 30
Appendix A. IANA Considerations . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
Intellectual Property and Copyright Statements . . . . . . . . . . 34
Roca, et al. Expires August 28, 2006 [Page 2]
Internet-Draft TESLA in ALC and NORM February 2006
1. Introduction
Many applications using multicast and broadcast communications
require that each receiver be able to authenticate the source of any
packet it receives as well as its integrity. For instance, ALC
[RFC3450] and NORM [RFC3940] are two Content Delivery Protocols (CDP)
designed to transfer reliably objects (e.g. files) between a
session's sender and several receivers.
The NORM protocol is based on bidirectional transmissions. Each
receiver acknowledges data received or, in case of packet erasures,
asks for retransmissions. The ALC protocol defines unidirectional
transmissions. Reliability can be achieved by means of cyclic
transmissions of the content within a carousel, or by the use of
proactive Forward Error Correction codes (FEC), or by the joint use
of these mechanisms. Being purely unidirectional, ALC is massively
scalable, while NORM is intrinsically limited in terms of the number
of receivers that can be handled in a session. Both protocols have
in common the fact that they operate at application level, on top of
an erasure channel (e.g. the Internet) where packets can be lost
(erased) during the transmission. With some use case, an attacker
might impersonate the the ALC or NORM session's sender and inject
forged packets to the receivers, thereby corrupting the objects
reconstructed by the receivers.
The situation is much more complex in case of group communications
than it is with unicast communications. Indeed, in the latter case a
simple solution exist: the sender and receiver can share a secret key
to compute a Message Authentication Code (MAC) of all messages
exchanged. This is no longer feasible in case of a multicast and
broadcast communications since sharing a group key between the sender
and all receivers and using the same MAC scheme means that any group
member can impersonate the sender and send forged messages to other
receivers.
The usual solution to provide the source authentication and message
integrity services in case of multicast and broadcast communications
consists in relying on asymmetric cryptography and using digital
signatures. Yet this solution is limited by high computational costs
and high transmission overheads. The Timed Efficient Stream Loss-
tolerant Authentication protocol (TESLA) is an alternative solution
that provides the two required services, while being compatible with
high rate transmissions over lossy channels.
This document explains how to integrate the TESLA source
authentication and packet integrity protocol to the ALC and NORM
content delivery protocols. Since the FLUTE application [RFC3926] is
built on top of ALC, it will directly benefit from the services
Roca, et al. Expires August 28, 2006 [Page 3]
Internet-Draft TESLA in ALC and NORM February 2006
offered by TESLA at the transport layer.
This specification only considers the authentication/integrity of the
packets generated by the session's sender. This specification does
not consider the packets that will be generated by receivers, for
instance the feedback packets of NORM. Adding authentication/
integrity to the packets sent by receivers is outside the scope of
this document. Of course, this remark does not apply to ALC where
transmissions are purely unidirectional.
For more information on the TESLA protocol and its principles, please
refer to [RFC4082][Perrig.book04]. For more information on ALC, NORM
and FLUTE, please refer to [RFC3450], [RFC3940] and [RFC3926]
respectively, or [Neumann.ccr05].
1.1. Conventions Used in this Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
1.2. Terminology and Notations
The following notations and definitions are used throughout this
document:
o PRF is the Pseudo Random Function;
o MAC is the Message Authentication Code;
o HMAC is the Keyed-Hash Message Authentication Code;
o t_s is the sender local time value at some absolute time;
o t_r is the receiver local time value at the same absolute time;
o T_0, the start time corresponding to the beginning of the session
(NTP timestamp);
o T_int, the interval duration (in milliseconds);
o d, the key disclosure delay (in number of intervals);
o D_t, the upper bound of the lag of the receiver's clock with
respect to the clock of the sender (in sign/second/sub-second
format);
Roca, et al. Expires August 28, 2006 [Page 4]
Internet-Draft TESLA in ALC and NORM February 2006
o D^0_t, the upper bound on the lag of the sender's clock with
respect to the time reference in indirect time synchronization
mode;
o D^R_t, the upper bound on the lag of the receivers's clock with
respect to the time reference in indirect time synchronization
mode;
o N is the number of keys in a key chain. When several chains are
used, all chains MUST have the same length, N;
o N_tx_old_kck 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 waiting for the disclosure delay d;
o N_tx_new_kcc is the number of intervals during which the
commitment to a new key chain SHOULD be sent, before switching to
the new key chain;
Roca, et al. Expires August 28, 2006 [Page 5]
Internet-Draft TESLA in ALC and NORM February 2006
2. Using TESLA with ALC and NORM
2.1. ALC and NORM Specificities that Impact TESLA
The ALC and NORM protocols have features and requirements that
largely impact the way TESLA can be used.
In case of ALC:
o ALC is massively scalable: nothing in the protocol specification
limits the number of receivers that join an on-going session.
Therefore an ALC session potentially includes a huge number (e.g.
millions or more) receivers;
o ALC can work on top of purely unidirectional transport channels:
this is one of the assets of ALC, and examples of unidirectional
channels include satellites (even if a back channel might exist)
and DVB-H systems.
o ALC defines an on-demand content delivery model [RFC3451] 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.
o ALC sessions are potentially very long: with some use cases, in
particular in an on-demand mode, a session can last several months
during which the content is continuously transmitted within a
carousel. The content can either be static (e.g. in case of a
software update) or be regularly updated (e.g. in case of a web
site).
Depending on the use case, some of the above features may not apply.
For instance ALC can also be used over a bidirectional channel, or
ALC can be used for small groups.
In case of NORM:
o NORM has been designed for limited size sessions: unlike ALC, NORM
is not massively scalable. The reason is that NORM relies on
feedback messages and the source may collapse if the feedback
message rate is too high;
o NORM requires a bidirectional transport channel: yet the back
channel is not necessarily a high rate channel since only low to
medium rate control traffic will flow on it. Networks with an
asymmetric connectivity (e.g. a high rate satellite downlink and a
low-rate RTC based return channel) is appropriate;
Roca, et al. Expires August 28, 2006 [Page 6]
Internet-Draft TESLA in ALC and NORM February 2006
2.2. The Need for Secure Time Synchronization
The security offered by TESLA relies heavily on time. Therefore the
session's sender and each receiver need to be time synchronized in a
secure way. To that purpose, two general methods exist:
o direct time synchronization, and
o indirect time synchronization.
2.2.1. Direct Time Synchronization
When direct time synchronization is used, each receiver asks the
sender for a time synchronization. The source then directly answers
to each request, signing the reply. The security of this
synchronization method is guaranteed, but there are two potential
issues:
o a bidirectional channel MUST exist between the source and each
receiver,
o the source may collapse it the rate of requests is too high.
Direct time synchronization may not be an issue with NORM since
bidirectional communications already take place. Yet direct time
synchronization may be an issue with ALC since: there might not be
any back channel to the session's sender and there are potentially a
huge number of receivers.
2.2.2. Indirect Time Synchronization
When indirect time synchronization is used, the source and each
receiver must synchronize securely via an external time reference.
Several possibilities exist:
o sender and receivers can synchronize through a NTPv3 (Network Time
Protocol version 3) [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;
o similarly sender and receivers can synchronize through a NTPv4
(Network Time Protocol version 4) [I-D.ietf-ntp-ntpv4-proto]
hierarchy of servers. The Autokey security protocol of NTPv4 MUST
be used in order to authenticate each NTP message individually;
o similarly, they can synchronize through a SNTPv4 (Simple Network
Time Protocol version 4) [RFC2030] hierarchy of servers. The
Roca, et al. Expires August 28, 2006 [Page 7]
Internet-Draft TESLA in ALC and NORM February 2006
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;
o they can synchronize through a GPS or Galileo (or similar) device
that also provide a high precision time reference. This time
reference is in general trusted, yet depending on the use case,
this trust will or not be acceptable;
o they can synchronize thanks to a dedicated hardware, embedded on
each sender and receiver, that offers 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,
when feasible (in an extreme case once, at manufacturing time),
and then to remain autonomous for some time, depending on the
known maximum clock drift.
A bidirectional channel is required by the NTP/SNTP schemes. On the
opposite, with the GPS/Galileo and high precision clock schemes, no
such assumption is made. In situations where ALC is used on purely
unidirectional transport channels (Section 2.1), using the NTP/SNTP
schemes is not possible. Another aspect is the scalability
requirement of ALC, and to a lesser extent NORM. From this point of
view, the above mechanisms usually do not raise any problem, unlike
the direct synchronization schemes. Therefore, using indirect time
synchronization is a good candidate, in particular with ALC.
In any case, this document does not explain in details how to achieve
time synchronization, whether it follows a direct or indirect sheme.
The document only provides general guidelines. The details are
outside the scope of this document.
Roca, et al. Expires August 28, 2006 [Page 8]
Internet-Draft TESLA in ALC and NORM February 2006
3. Sender Operations
3.1. TESLA Parameters
3.1.1. Key Chains
The sender divides the time into uniform intervals of duration T_int.
The sender then computes a one-way key chain of N keys, and assigns
one key from the chain to each interval in sequence. In order to
compute this chain, it must first select a Primary Key, choose two
PRF function F and F'. Then it computes all the previous keys 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 is vital to the security since no one should be able
to guess it.
The key chain has a finite length, N, so the TESLA session must
finish before the end of the key chain. But the longer the key
chain, the higher the memory and computation required to cope with
it. Another solution consists in switching to a new key chain when
necessary [Perrig.book04].
To do so, the sender commits the new key chain with the old key
chain. Let's say that the old key chain stops at K_N and the new key
chain starts at K_{N+1}. Then the sender includes the commitment
F(K_{N+1}) to the new key chain to packets authenticated with the old
key chain. This commitment SHOULD be sent during N_tx_new_kcc
intervals before the end of the old key chain. Since several packets
are usually sent during a time interval, the sender should alternate
between sending a disclosed key of the old key chain, and the
commitment to the new key chain.
The receiver will keep the commitment, until the key K_{N+1} is
disclosed, at interval N+1+d. Then the receiver will be able to test
the validity of that key by computing F(K_{N+1}) and comparing it to
the commitment.
When the key chain is changed, it becomes impossible to recover a
previous key from the old key chain. This is a problem if the
receiver lost the packets disclosing the last key of the old key
chain. A solution consists in re-sending the last key, K_N, of the
old key chain. This SHOULD be done during N_tx_old_kck intervals at
the beginning of the new key chain, after the disclosure delay d.
Since several packets are usually sent during a time interval, the
sender should alternate between sending a disclosed key of the new
key chain, and the last key of the old key chain.
In some cases a receiver having experienced a very long disconnection
Roca, et al. Expires August 28, 2006 [Page 9]
Internet-Draft TESLA in ALC and NORM February 2006
might have lost the commitment of the new chain. Therefore this
receiver will be unable to authenticate any packet related to the new
chain and all the following ones. The solution for this receiver to
catch up consists in receiving the bootstrap information. This can
happen by waiting for the next periodic transmission (indirect time
synchronization), by requesting it (direct time synchronization), or
through an external mechanism (Section 3.2.1).
3.1.2. Time Interval Schedule
The sender must determine the following parameters:
o T_0, the start time corresponding to the beginning of the session;
o T_int, the interval duration, usually ranging from 100
milliseconds to 1 second;
o d, the key disclosure delay (in number of intervals). It is the
time to wait before disclosing a key;
o N, the number of keys in a key chain;
The correct choice of T_int, d, and N is crucial for the usability 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 is too short will cause too many packets to be
unverifiable by some receivers. A N*T_int product that is too small
will cause the sender to switch too often to new key chains. A N
that is too long with respect to the expected session duration, if
this latter is known, will require the sender to compute too many
keys without using them all. [RFC4082] (sections 3.2 and 3.6) gives
general guidelines for initializing these parameters.
3.2. TESLA Messages and Authentication Tags
At a sender, TESLA produces two types of signaling information:
o The bootstrap information, which is a digitally signed packet
containing all the information required to bootstrap TESLA at a
receiver.
o The authentication tag, which is sent in all packets (see
Section 5 for exceptions) and contains the MAC of the packet.
3.2.1. Bootstrap Information
In order to initialize the TESLA component at a receiver, the sender
must communicate some key information. This TESLA bootstrap
Roca, et al. Expires August 28, 2006 [Page 10]
Internet-Draft TESLA in ALC and NORM February 2006
information MUST be securely transmitted, in particular a receiver
must be able to check the packet source and the packet integrity
using standard protocols. Any digital signature will do.
The bootstrap information can be sent in point to point after a
direct synchronization request/response exchange. The bootstrap
information can also be broadcast to all receivers, for instance
periodically, either in indirect time synchronization mode, or in
direct synchronization mode when a large number of clients arrive at
the same time.
More specifically, the periodic broadcast of the bootstrap
information message will be required when:
o the ALC session uses an ``on-demand'' mode, clients arriving at
their own discretion;
o some clients experience an intermittent connectivity. This is
particularly true when several key chains are used in an ALC or
NORM session, since there is a risk that some receivers loose all
the commitments to the new key chain.
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.
The bootstrap information message will be broadcast a limited number
of times, at the beginning of the session, in other cases. This is
true in particular with ALC or NORM sessions in ``push'' mode, when
all clients have a high probability of receiving at least one packet.
An extreme case consists in sending the bootstrap information only
once.
In some use cases, the bootstrapping information MAY be sent to
receivers through an external mechanism, for instance in a way
similar to [I-D.ietf-msec-bootstrapping-tesla]. How to do that is
outside the scope of this document.
3.2.2. Direct Time Synchronization Response
In direct time synchronization mode, receivers will send request
messages to the session's sender and include their local time, t_r
(Section 4.1.2). Upon receipt of this request, the sender records
its local time, t_s, and sends a response message that contains both
t_r and t_s ([RFC4082], section 3.3.1). This message is unicast to
the receiver. This direct time synchronization response message MUST
Roca, et al. Expires August 28, 2006 [Page 11]
Internet-Draft TESLA in ALC and NORM February 2006
be securely transmitted, in particular the receiver must be able to
check the packet source and the packet integrity using standard
protocols. Any digital signature will do.
The Direct time synchronization messages are distinct from the
Bootstrap Information message. 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. Otherwise, a separate
Bootstrap Information message can be broadcast to each client after
the direct time synchronization response message.
The same session might include receivers that use either time
synchronization mode. A common Bootstrap Information message enables
both kinds of receivers to initialize their TESLA component.
3.2.3. Authentication Tag
Every authenticated packet must have an authentication tag,
containing the MAC of the message and either a disclosed key or a
commitment to a new key chain.
The computation of the MAC, 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
Section 3.3.3 Section 3.3.4 Section 3.3.5) MUST be set to 0.
3.3. TESLA Messages and Authentication Tag Format
This section specifies the format of the various kinds of TESLA
messages and authentication tags sent by the session's sender.
3.3.1. Bootstrap Information Format
Roca, et al. Expires August 28, 2006 [Page 12]
Internet-Draft TESLA in ALC and NORM February 2006
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| KC PRF type | MAC PRF type | HMAC func type| Signature type|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| K_j Key length | Signature length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|# cert |rsv|B|A| d | T_int |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Id j of K_j |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ K_j +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ T_0 +
| (NTP timestamp) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Signature extension ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P| |
~-+ D^0_t (optional, present if A==1) ~
| (NTP timestamp diff, with P==1 if positive) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ NTP extension (optional, present if B==1) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Bootstrap information format.
The format of the bootstrap information is depicted in Figure 1.
o The key chain PRF type is the reference number of the F function
used to calculate the key chain (Appendix A).
o The MAC PRF type is the reference number of the F' function used
to derive the MAC key from the key chain (Appendix A).
o The HMAC function type is the reference number of the function
used to compute the HMAC of the packets (Appendix A).
Roca, et al. Expires August 28, 2006 [Page 13]
Internet-Draft TESLA in ALC and NORM February 2006
o Signature type is the reference number of the digital signature
used to authenticate this bootstrap information (Appendix A).
o # of certs is the number of certificates present in the signature
extension.
o A is a flag indicating whether or not the P flag and D^0_t field
are present (A==1) or not (A==0). The P flag and D^0_t field are
needed in indirect time synchronization mode.
o d is an unsigned integer that defines the key disclosure delay (in
number of intervals). d MUST be greater or equal to 2.
o T_int is an unsigned integer that defines the interval duration
(in milliseconds) one interval.
o K_j Key length is the length in bits of key K_j.
o Signature length is the number of bytes of the signature included
in the signature extension.
o N is the number of keys of the key chain.
o Id j of K_j is an unsigned integer corresponding to the index of
the interval of the key released in this bootstrap information.
For performance reasons, the sender SHOULD always send a bootstrap
information with the highest Id j possible since this will reduce
the number of computation for the receivers that join later.
o K_j is the key corresponding to the interval j. If i is the
current interval we MUST have: j < i - d.
o T_0 is the start time corresponding to the beginning of the
session, i.e. interval 0. It is a NTP timestamp.
o The signature extension is described in Section 3.3.1.1. It's
format depends on the "# of certs" field.
o P is optional. It is a flag indicating whether the D^0_t NTP
timestamp difference is positive (P==1) or negative (P==0). It is
only used in indirect time synchronization mode when the A flag is
1.
o D^0_t is optional. It is the upper bound on 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^0_t is the maximum upper bound on the lag with each time
reference. D^0_t is composed of two unsigned integers, as with
Roca, et al. Expires August 28, 2006 [Page 14]
Internet-Draft TESLA in ALC and NORM February 2006
NTP timestamps: the first 31 bits give the time difference in
seconds (the MSB is used by the P flag); the remaining 32 bits
give the sub-second time difference. It is only used in indirect
time synchronization mode when flag A==1.
* ----- Editor's note: a first alternative would be to use
floating point arithmetic, IEEE754 for carrying D^0_t. NTP
timestamp difference is usually performed with double floating
point arithmetic internally (at least in TESLA and NTPv4), so
it makes sense. Is single-precision (32-bit) sufficient or
should double-precision (64-bit) be used? 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. -----
o The NTP extension is optional is described in Section 3.3.1.2.
Its presence can be detected by the total length of the signature.
3.3.1.1. Signature Extension Format
The signature extension format when the "# of certs" field is
strictly greater than 0 (2 in this example) is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cert 1 type | cert 1 length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
~ Certificate 1 +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cert 2 type | cert 2 length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
~ Certificate 2 +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Signature +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Signature extension format when #cert==2.
In Figure 2:
Roca, et al. Expires August 28, 2006 [Page 15]
Internet-Draft TESLA in ALC and NORM February 2006
o Type of certificate identifies the algorithm used for the
certificate (see Appendix A).
o The certificate length is the length in bytes of the certificate.
o The certificate field contains a certificate signed by an external
authority and that certifies the sender's public key. This field
is padded (with 0) up to a multiple of 32 bits.
o The signature is a digital signature using the type and length
specified in the main part of the bootstrap information message.
This field is padded (with 0) up to a multiple of 32 bits.
The signature extension format when the "# of certs" field is zero
(i.e. when no certificate is provided) is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Signature +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Signature extension format when #cert==0.
In Figure 3:
o The signature is a digital signature using the type and length
specified in the main part of the bootstrap information message.
This field is padded (with 0) up to a multiple of 32 bits.
3.3.1.2. NTP Extension Format
In some use cases, when NTP or SNTP is used in indirect
synchronization mode, the session's sender must have a way to
indicate to receivers one or more NTP server that will act as time
reference (Section 4.1.2).
Roca, et al. Expires August 28, 2006 [Page 16]
Internet-Draft TESLA in ALC and NORM February 2006
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| total length | # of entries | reserved (0) | cert type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FQDN 1 length | cert 1 length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
~ NTP Server 1 FQDN +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ NTP Certificate 1 (optional) +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FQDN 2 length | cert 2 length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
~ NTP Server 2 FQDN +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ NTP Certificate 2 (optional) +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Optional NTP information format, when two NTP servers are
specified
Figure 4 shows the optional NTP information format, when two NTP
servers are specified:
o The total length is the total length in units of 32 bit words of
this NTP information extension;
o The # of entries is the number of NTP entries;
o Type of certificates identifies the algorithm used for all the
certificates that may be provided (see Appendix A).
o The FQDN length is the number of bytes of the NTP server fully
qualified domain name;
o The NTP server FQDN is a string containing the NTP server Fully
Qualified Domain Name (e.g. "ntp.foo.bar."). This field is padded
(with 0) up to a multiple of 32 bits;
Roca, et al. Expires August 28, 2006 [Page 17]
Internet-Draft TESLA in ALC and NORM February 2006
o The NTP Certificate is optional. The content delivery server can
use it to self-certify the NTP public key. The certificate length
indicates whether this field is present or not. This field is
padded (with 0) up to a multiple of 32 bits.
----- Editor's note: Providing only NTP Server FQDN is perhaps too
limitative. It should be possible to use either a FQDN or an
IPv4/IPv6 address. -----
3.3.2. Format of a Direct Time Synchronization Response
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ t_s (NTP timestamp) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ t_r (NTP timestamp) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|# cert | reserved (0) |
+-------+-------------------------------------------------------+
| |
~ Signature extension ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Format of a Direct Time Synchronization Response
The response to a direct time synchronization request contains the
following information:
o t_s, the sender local time value when receiving the direct time
synchronization request message;
o t_r, the receiver local time value contained in the direct time
synchronization request message;
o # of certs is the number of certificates present in the signature
extension.
o The signature extension is described in Section 3.3.1.1. It's
format depends on the "# of certs" field.
Roca, et al. Expires August 28, 2006 [Page 18]
Internet-Draft TESLA in ALC and NORM February 2006
3.3.3. Format of a Standard Authentication Tag
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Id i of K_i |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Disclosed Key K_{i-d} +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ MAC(K_i, M) +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Format of the authentication tag
Figure 6 shows the format of the authentication tag:
o The Id i is the index of the key used for computing the MAC of
this packet.
o The disclosed key MUST be the key used for interval i-d.
o MAC(K_i, M) is the message authentication code of the current
packet, including the ALC or NORM header (including the header
extensions), plus the payload when applicable.
3.3.4. Format of an Authentication Tag with a New Key Chain Commitment
During the last N_tx_new_kcc intervals of the current key chain, the
sender MUST 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}). Figure 7 shows the corresponding
format.
Roca, et al. Expires August 28, 2006 [Page 19]
Internet-Draft TESLA in ALC and NORM February 2006
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Id i of K_i |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ New Key Commitment F(K_{N+1}) +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ MAC(K_i, M) +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Format of the authentication tag with a new key chain
commitment
3.3.5. Format of an Authentication Tag with an Old Chain Last Key
Disclosure
During the first N_tx_old_kcc 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. Figure 8
shows the corresponding format.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Id i of K_i |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Last Key of Old Chain, K_N +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ MAC(K_i, M) +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Format of the authentication tag with an old chain last key
disclosure
Roca, et al. Expires August 28, 2006 [Page 20]
Internet-Draft TESLA in ALC and NORM February 2006
4. Receiver Operations
4.1. Initialization of a Receiver
A receiver must be initialized before being able to authenticate the
source of incoming packets. Two actions must be performed:
o receive and process a bootstrap information message, and
o calculate an upper bound of the sender's local time, and to that
purpose, he must perform time synchronization.
4.1.1. Processing the Bootstrap Information Message
A receiver must first receive a packet containing the bootstrap
information, digitally signed by the sender, and verify its
signature. Because the packet is signed, the receiver also needs to
know the public key of the sender. The present document does not
specify how the public key of the sender is communicated reliably and
in a secure way to all possible receivers. Once the bootstrap
information has been verified, the receiver can initialize its TESLA
component. The receiver SHOULD then ignore the following bootstrap
information messages, if any. There is an exception though: when a
new key chain is used and a receiver missed all the commitments for
this new key chain, then this latter SHOULD process any new Bootstrap
information message.
Before TESLA has been initialized, a receiver MUST ignore all packets
other than the bootstrap information message. Yet, a receiver MAY
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.
4.1.2. Time Synchronization
First of all, the receiver must know whether the ALC or NORM session
relies on direct or indirect 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 acceptable in the same
session.
4.1.2.1. Direct Time Synchronization
In case of a direct time synchronization, a receiver MUST first
synchronize with the sender. To that purpose, the receiver sends a
direct time synchronization request message. This message includes
Roca, et al. Expires August 28, 2006 [Page 21]
Internet-Draft TESLA in ALC and NORM February 2006
the local time (NTP timestamp) at the receiver when sending the
message. This timestamp will be integrated in the sender's response.
Figure 9 details the direct time synchronization message format.
4.1.2.2. Indirect Time Synchronization
With the indirect time synchronization method, the sender MAY provide
in its bootstrap information, the URL or IP address of the NTP
server(s) he trusts along with an OPTIONAL certificate for each NTP
server. When several NTP servers are specified, a receiver MUST
choose one of them. This document does not specify how the choice is
made, but for the sake of scalability, the clients SHOULD NOT use the
same server if several possibilities are offered. The NTP
synchronization between the NTP server and the receiver MUST be
authenticated, either using the certificate provided by the content
delivery server, or another certificate the client may obtain for
this NTP server.
Then the receiver computes the time offset between itself and the NTP
server chosen. Note that the receiver does not need to update the
local time, since this operation would often require some privileges,
computing the time offset is sufficient.
Since the offset between the server and the time reference is
indicated in the bootstrap information message, the receiver can now
calculate an upper bound of the sender's local time.
4.1.3. Format of a Direct Time Synchronization Request
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) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Format of a Direct Time Synchronization Request
The direct time synchronization request (Figure 9) contains the
following information:
o t_r, the receiver local time value when sending this direct time
synchronization request message;
Roca, et al. Expires August 28, 2006 [Page 22]
Internet-Draft TESLA in ALC and NORM February 2006
4.2. Authentication of Received Packets
The receiver can now authenticate incoming packets. To that purpose,
he MUST follow different steps ([RFC4082] section 3.5):
1. The receiver parses the different packet headers. If the TESLA
authentication tag is not present, the receiver MUST reject the
packet.
2. Then proceed with the TESLA safe test: (1) check that the key
used to compute the MAC of this packet has not already been
disclosed, and (2) check the disclosed key by computing the
necessary number of PRF functions to obtain a previously safe
disclosed key. If any of these two tests fail, the receiver MUST
reject the packet.
3. Then, according to the [RFC3451], when applicable, perform
congestion control even if the packet has not yet been
authenticated. If this feature leads to a potential DoS attack,
it does not compromise the security features offered by TESLA and
enables a rapid reaction in front of congestion problems.
4. Then buffer the packet for a later authentication, once the
corresponding key will be received or deduced from another key.
5. If the disclosed key is a new one, then the receiver can
authenticate previously stored packets using this key or any key
derived from this one.
6. If a packet fails to be authenticated, then this packet MUST be
rejected.
7. If a packet is successfully authenticated, then the receiver
continues processing it.
----- Editor's note: [RFC4082] explains that unauthenticated
packets SHOULD be destroyed, and if not this is at the own risk of
the receiver. We choose the other strategy, requiring that unsafe
packets be destroyed when the client decides to use TESLA. But
the client can at any time choose to continue an ALC or NORM
session in unsafe mode, ignoring TESLA extensions. -----
Roca, et al. Expires August 28, 2006 [Page 23]
Internet-Draft TESLA in ALC and NORM February 2006
5. Integration in the ALC and NORM Protocols
5.1. Authentication Header Extension Format
The integration of TESLA in ALC or NORM is similar and relies on the
header extension mechanism defined in both protocols. More precisely
we further specify the EXT_AUTH=1 header extension defined in
[RFC3451].
Several fields are added in addition to the HET (Header Extension
Type) and HEL (Header Extension Length) fields (Figure 10).
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET (=1) | HEL |Scheme |Version| Resvd |Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ~
| Content |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Format of the TESLA EXT_AUTH header extension.
The fields of the TESLA EXT_AUTH header extension are:
Scheme (Authentication Scheme) field (4 bits):
"Scheme" identifies the source authentication scheme or protocol
in use. The value 0 is reserved for TESLA.
Version field (4 bits):
"Version" identifies the version number of the TESLA
authentication scheme. The value 0 is reserved for the current
specification.
Resvd (Reserved) field (5 bits):
The "resvd" field is not used in the current specification and
MUST be set to zero by the sender.
Type field(3 bits):
Roca, et al. Expires August 28, 2006 [Page 24]
Internet-Draft TESLA in ALC and NORM February 2006
The "Type" field identifies the type of TESLA information carried
in this header extension. This specification defines the
following types:
* 0: bootstrap information, sent by the sender periodically or
after a direct synchronization request;
* 1: authentication information for the on-going key chain, sent
by the sender along with each packet;
* 2: authentication information along with a new key chain
commitment, sent by the sender when approaching the end of a
key chain;
* 3: authentication information along with an old key chain
commitment, sent by the sender some time after moving to a new
key chain;
* 4: 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;
* 5: direct 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;
Content (variable length, multiple of 32 bits):
This is the TESLA information carried in the header extension,
whose type is given by the "Type" field.
All receivers MUST recognize EXT_AUTH but MAY NOT be able to parse
its content, for instance because they do not include the TESLA
building block. In that case these receivers MUST ignore the
EXT_AUTH extensions. In case of NORM, the packets sent by receivers
MAY contain a direct synchronization request but MUST NOT contain any
of the other four TESLA EXT_AUTH header extensions.
All authentication schemes using the EXT_AUTH header extension MUST
reserve the same 4 bit "Scheme" field after the HET/HEL fields. This
way, several authentication schemes can be used in the same ALC or
NORM session. For instance, in case of NORM, TESLA can be used for
the downstream traffic while another scheme is used for the upstream
traffic.
Roca, et al. Expires August 28, 2006 [Page 25]
Internet-Draft TESLA in ALC and NORM February 2006
5.2. Use of Authentication Header Extensions
Each packet sent by the sessions's sender MUST contain exactly one
TESLA EXT_AUTH header extension.
The "bootstrap information" TESLA EXT_AUTH (Type=1) MUST be sent in a
stand-alone control packet, rather than packets containing
application data. The reason is the large size of this bootstrap
information which largely increases the maximum ALC/LCT or NORM
header size. By having the bootstrap information header extension in
stand-alone packets, the maximum payload size of data packets is only
affected by the unavoidable authentication tag, not by any additional
large header extension sent at a low frequency. With NORM, the
"bootstrap information" TESLA EXT_AUTH MUST be sent in a NORM_INFO
message. With ALC, the "bootstrap information" TESLA EXT_AUTH MUST
be sent in a control packet, i.e. containing no encoding symbol.
The three "authentication information" TESLA EXT_AUTH (Type=2, 3, or
4) MUST be attached to the ALC or NORM packet (data or control
packet) that they protect.
With NORM, the direct synchronization request extension header
(Type=5) is sent by a receiver in a (TBD) NORM packet (see editor's
note below). There is no authentication information header extension
in this case since this draft only considers the authentication/
integrity of the packets generated by the session's sender.
----- Editor's note: what type of NORM packet should be used to
that purpose? NORM_REPORT is one possibility. -----
With ALC, the direct synchronization request information 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 synchronization requests to the
session's sender.
5.3. Managing Silent Periods
An ALC or NORM sender may stop transmitting packet for some time, for
various reasons. It can be the end of the session and all packets
have already been sent. The use scenario may consist in a succession
of busy periods, when fresh objects are available, and silent
periods. In both cases, this is an issue since the authentication of
the packets sent during the last d intervals requires that the
associated keys be revealed, which can only take place after d
additional intervals. To resolve this boundary problem, the
session's sender MUST sent null packets containing the TESLA EXT_AUTH
Roca, et al. Expires August 28, 2006 [Page 26]
Internet-Draft TESLA in ALC and NORM February 2006
header extension along with the authentication information (Type=2)
for at least d intervals after the end of the regular ALC or NORM
packet transmissions. The transmission rate of these null packets
must be sufficient to guaranty that each receiver receives at least
that containing the last key with a sufficiently high probability.
Roca, et al. Expires August 28, 2006 [Page 27]
Internet-Draft TESLA in ALC and NORM February 2006
6. Security Considerations
The security of the TESLA protocol is discussed in [RFC4082].
Security considerations specific to its use in ALC and NORM remain
TBD...
Roca, et al. Expires August 28, 2006 [Page 28]
Internet-Draft TESLA in ALC and NORM February 2006
7. Acknowledgments
The authors are grateful to David L. Mills. MORE TO COME...
Roca, et al. Expires August 28, 2006 [Page 29]
Internet-Draft TESLA in ALC and NORM February 2006
8. References
8.1. Normative References
[RFC1305] Mills, D., "Network Time Protocol (Version 3)
Specification, Implementation", RFC 1305, March 1992.
[RFC2030] Mills, D., "Simple Network Time Protocol (SNTP) Version 4
for IPv4, IPv6 and OSI", RFC 2030, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997.
[RFC3450] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., and J.
Crowcroft, "Asynchronous Layered Coding (ALC) Protocol
Instantiation", RFC 3450, December 2002.
[RFC3451] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., Handley,
M., and J. Crowcroft, "Layered Coding Transport (LCT)
Building Block", RFC 3451, December 2002.
[RFC3926] Paila, T., Luby, M., Lehtonen, R., Roca, V., and R. Walsh,
"FLUTE - File Delivery over Unidirectional Transport",
RFC 3926, October 2004.
[RFC3940] Adamson, B., Bormann, C., Handley, M., and J. Macker,
"Negative-acknowledgment (NACK)-Oriented Reliable
Multicast (NORM) Protocol", RFC 3940, November 2004.
[RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B.
Briscoe, "Timed Efficient Stream Loss-Tolerant
Authentication (TESLA): Multicast Source Authentication
Transform Introduction", RFC 4082, June 2005.
8.2. Informative References
[I-D.ietf-msec-bootstrapping-tesla]
Fries, S. and H. Tschofenig, "Bootstrapping TESLA",
draft-ietf-msec-bootstrapping-tesla-03 (work in progress),
January 2006.
[I-D.ietf-ntp-ntpv4-proto]
Burbank, J., "The Network Time Protocol Version 4 Protocol
Specification", draft-ietf-ntp-ntpv4-proto-01 (work in
progress), October 2005.
[Neumann.ccr05]
Neumann, C., Roca, V., and R. Walsh, "Large Scale Content
Roca, et al. Expires August 28, 2006 [Page 30]
Internet-Draft TESLA in ALC and NORM February 2006
Distribution Protocols", ACM Computer Communication
Review (CCR), Vol. 35 No. 5, October 2005.
[Perrig.book04]
Perrig, A. and J. Tygar, "Secure Broadcast Communication
in Wired and Wireless Networks", Kluwer Academic
Publishers ISBN 0-7923-7650-1, 2004.
Roca, et al. Expires August 28, 2006 [Page 31]
Internet-Draft TESLA in ALC and NORM February 2006
Appendix A. IANA Considerations
This document requires an IANA registration for the following
attributes:
Cryptographic pseudo-random function, TESLA-PRF:
The currently defined values are:
+--------------+-------+
| PRF function | Value |
+--------------+-------+
| HMAC-SHA1 | 0 |
+--------------+-------+
Cryptographic message authentication code (MAC):
The currently defined values are:
+--------------+-------+
| MAC function | Value |
+--------------+-------+
| HMAC-SHA1 | 0 |
+--------------+-------+
Signature type:
The currently defined values are:
+------------------------------------+-------+
| Signature type | Value |
+------------------------------------+-------+
| PKCS #1: RSA Cryptography Standard | 0 |
+------------------------------------+-------+
Certificate type:
The currently defined values are:
+------------------------------------+-------+
| Certificate type | Value |
+------------------------------------+-------+
| PKCS #1: RSA Cryptography Standard | 0 |
+------------------------------------+-------+
Roca, et al. Expires August 28, 2006 [Page 32]
Internet-Draft TESLA in ALC and NORM February 2006
Authors' Addresses
Vincent Roca
INRIA
655, av. de l'Europe
Zirst; Montbonnot
ST ISMIER cedex 38334
France
Email: vincent.roca@inrialpes.fr
URI: http://planete.inrialpes.fr/~roca/
Aurelien Francillon
INRIA
655, av. de l'Europe
Zirst; Montbonnot
ST ISMIER cedex 38334
France
Email: aurelien.francillon@inrialpes.fr
URI: http://planete.inrialpes.fr/~francill/
Sebastien Faurite
INRIA
655, av. de l'Europe
Zirst; Montbonnot
ST ISMIER cedex 38334
France
Roca, et al. Expires August 28, 2006 [Page 33]
Internet-Draft TESLA in ALC and NORM February 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Roca, et al. Expires August 28, 2006 [Page 34]