One document matched: draft-ietf-msec-tesla-for-alc-norm-06.txt
Differences from draft-ietf-msec-tesla-for-alc-norm-05.txt
MSEC V. Roca
Internet-Draft A. Francillon
Intended status: Experimental S. Faurite
Expires: April 25, 2009 INRIA
October 22, 2008
Use of TESLA in the ALC and NORM Protocols
draft-ietf-msec-tesla-for-alc-norm-06.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 April 25, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Roca, et al. Expires April 25, 2009 [Page 1]
Internet-Draft TESLA in ALC and NORM October 2008
Abstract
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. The authentication and integrity
verification of the packets sent by receivers, if any, is out of the
scope of this document.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Scope of this Document . . . . . . . . . . . . . . . . . . 5
1.2. Conventions Used in this Document . . . . . . . . . . . . 6
1.3. Terminology and Notations . . . . . . . . . . . . . . . . 6
1.3.1. Notations and Definitions Related to Cryptographic
Functions . . . . . . . . . . . . . . . . . . . . . . 6
1.3.2. Notations and Definitions Related to Time . . . . . . 7
2. Using TESLA with ALC and NORM: General Operations . . . . . . 9
2.1. ALC and NORM Specificities that Impact TESLA . . . . . . . 9
2.2. Bootstrapping TESLA . . . . . . . . . . . . . . . . . . . 10
2.2.1. Bootstrapping TESLA with an Out-Of-Band Mechanism . . 10
2.2.2. Bootstrapping TESLA with an In-Band Mechanism . . . . 10
2.3. Setting Up a Secure Time Synchronization . . . . . . . . . 11
2.3.1. Direct Time Synchronization . . . . . . . . . . . . . 11
2.3.2. Indirect Time Synchronization . . . . . . . . . . . . 12
2.4. Determining the Delay Bounds . . . . . . . . . . . . . . . 13
2.4.1. Delay Bound Calculation in Direct Time
Synchronization Mode . . . . . . . . . . . . . . . . . 13
2.4.2. Delay Bound Calculation in Indirect time
Synchronization Mode . . . . . . . . . . . . . . . . . 14
3. Sender Operations . . . . . . . . . . . . . . . . . . . . . . 15
3.1. TESLA Parameters . . . . . . . . . . . . . . . . . . . . . 15
3.1.1. Time Intervals . . . . . . . . . . . . . . . . . . . . 15
3.1.2. Key Chains . . . . . . . . . . . . . . . . . . . . . . 15
3.1.3. Time Interval Schedule . . . . . . . . . . . . . . . . 18
3.1.4. Timing Parameters . . . . . . . . . . . . . . . . . . 19
3.2. TESLA Signaling Messages . . . . . . . . . . . . . . . . . 19
3.2.1. Bootstrap Information . . . . . . . . . . . . . . . . 19
3.2.2. Direct Time Synchronization Response . . . . . . . . . 20
3.3. TESLA Authentication Information . . . . . . . . . . . . . 21
3.3.1. Authentication Tags . . . . . . . . . . . . . . . . . 21
3.3.2. Digital Signatures . . . . . . . . . . . . . . . . . . 21
3.3.3. Group MAC Tags . . . . . . . . . . . . . . . . . . . . 23
3.4. Format of TESLA Messages and Authentication Tags . . . . . 24
3.4.1. Format of a Bootstrap Information Message . . . . . . 24
Roca, et al. Expires April 25, 2009 [Page 2]
Internet-Draft TESLA in ALC and NORM October 2008
3.4.2. Format of a Direct Time Synchronization Response . . . 30
3.4.3. Format of a Standard Authentication Tag . . . . . . . 31
3.4.4. Format of a Standard Authentication Tag Without
Key Disclosure . . . . . . . . . . . . . . . . . . . . 32
3.4.5. Format of an Authentication Tag with a ``New Key
Chain'' Commitment . . . . . . . . . . . . . . . . . . 33
3.4.6. Format of an Authentication Tag with a ``Last Key
of Old Chain'' Disclosure . . . . . . . . . . . . . . 34
3.4.7. Format of the Compact Authentication Tags . . . . . . 35
4. Receiver Operations . . . . . . . . . . . . . . . . . . . . . 39
4.1. Verification of the Authentication Information . . . . . . 39
4.1.1. Processing the Group MAC Tag . . . . . . . . . . . . . 39
4.1.2. Processing the Digital Signature . . . . . . . . . . . 39
4.1.3. Processing the Authentication Tag . . . . . . . . . . 40
4.2. Initialization of a Receiver . . . . . . . . . . . . . . . 40
4.2.1. Processing the Bootstrap Information Message . . . . . 40
4.2.2. Performing Time Synchronization . . . . . . . . . . . 41
4.3. Authentication of Received Packets . . . . . . . . . . . . 42
4.3.1. Wrong Guess of the i Parameter . . . . . . . . . . . . 45
4.3.2. Discarding Unnecessary Packets Earlier . . . . . . . . 46
4.4. Flushing the Non Authenticated Packets of a Previous
Key Chain . . . . . . . . . . . . . . . . . . . . . . . . 46
5. Integration in the ALC and NORM Protocols . . . . . . . . . . 48
5.1. Authentication Header Extension Format . . . . . . . . . . 48
5.2. Use of Authentication Header Extensions . . . . . . . . . 50
5.2.1. EXT_AUTH Header Extension of Type Bootstrap
Information . . . . . . . . . . . . . . . . . . . . . 50
5.2.2. EXT_AUTH Header Extension of Type Authentication
Tag . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.2.3. EXT_AUTH Header Extension of Type Direct Time
Synchronization Request . . . . . . . . . . . . . . . 53
5.2.4. EXT_AUTH Header Extension of Type Direct Time
Synchronization Response . . . . . . . . . . . . . . . 53
6. Security Considerations . . . . . . . . . . . . . . . . . . . 55
6.1. Dealing With DoS Attacks . . . . . . . . . . . . . . . . . 55
6.2. Dealing With Replay Attacks . . . . . . . . . . . . . . . 56
6.2.1. Impacts of Replay Attacks on TESLA . . . . . . . . . . 56
6.2.2. Impacts of Replay Attacks on NORM . . . . . . . . . . 57
6.2.3. Impacts of Replay Attacks on ALC . . . . . . . . . . . 57
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 59
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 61
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 62
9.1. Normative References . . . . . . . . . . . . . . . . . . . 62
9.2. Informative References . . . . . . . . . . . . . . . . . . 62
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 64
Intellectual Property and Copyright Statements . . . . . . . . . . 65
Roca, et al. Expires April 25, 2009 [Page 3]
Internet-Draft TESLA in ALC and NORM October 2008
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 the integrity of these packets. This
is the case with ALC [RMT-PI-ALC] and NORM [RMT-PI-NORM], 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).
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.
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.
Preventing this attack is much more complex in case of group
communications than it is with unicast communications. Indeed, with
unicast communications a simple solution exists: the sender and the
receiver 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.
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 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.
Roca, et al. Expires April 25, 2009 [Page 4]
Internet-Draft TESLA in ALC and NORM October 2008
For more information on the TESLA protocol and its principles, please
refer to [RFC4082][Perrig04]. For more information on ALC and NORM,
please refer to [RMT-PI-ALC], [RMT-BB-LCT] and [RMT-PI-NORM]
respectively. For more information on FLUTE, please refer to
[RMT-FLUTE].
1.1. Scope of this Document
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. However, since this is usually a low-rate
flow (unlike the downstream flow), using computing intensive
techniques like digital signatures is often acceptable. The
Section 5 explains how to use several authentication schemes in a
given session, which can be used to that purpose.
This specification relies on several external mechanisms, for
instance:
o to communicate securely the public key or a certificate for the
session's sender (Section 2.2.2);
o to communicate securely and confidentially the group key, K_g,
used by the Group MAC feature, when applicable (Section 3.3.3).
In some situations, this group key will have to be periodically
refreshed;
o to perform secure time synchronization in indirect mode
(Section 2.3.2) or in direct mode (Section 2.3.1) to carry the
request/response messages with ALC which is purely unidirectional;
These mechanisms are required in order to bootstrap TESLA at a sender
and at a receiver and must be deployed in parallel to TESLA.
Besides, the randomness of the Primary Key of the key chain
(Section 3.1.2) is vital to the security of TESLA. Therefore the
sender needs a appropriate mechanism to generate this random key.
Several technical details of TESLA, like the most appropriate way to
alternate between the transmission of a key disclosure and a
commitment to a new key chain, or the transmission of a key
disclosure and the last key of the previous key chain, or the
disclosure of a key and the compact flavor that does not disclose any
key, are specific to the target use-case (Section 3.1.2). For
instance, it depends on the number of packets sent per time interval,
on the desired robustness and the acceptable transmission overhead,
which can only be optimized after taking into account the use-case
specificities.
Roca, et al. Expires April 25, 2009 [Page 5]
Internet-Draft TESLA in ALC and NORM October 2008
1.2. 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.3. Terminology and Notations
The following notations and definitions are used throughout this
document.
1.3.1. Notations and Definitions Related to Cryptographic Functions
Notations and definitions related to cryptographic functions
[RFC4082][RFC4383]:
o PRF is the Pseudo Random Function;
o MAC is the Message Authentication Code;
o HMAC is the Keyed-Hash Message Authentication Code;
o F is the one-way function used to create the key chain
(Section 3.1.2.1);
o F' is the one-way function used to derive the HMAC keys
(Section 3.1.2.1);
o 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;
o n_f is the length, in bits, of the F' function's output. This is
therefore the length of the HMAC keys;
o n_m is the length, in bits, of the truncated output of the MAC
[RFC2104]. Only the n_m most significant bits of the MAC output
are kept;
o 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;
o n_c is the number of keys in a key chain. Therefore: n_c = N+1;
o n_tx_lastkey is the number of additional intervals during which
the last key of the old key chain SHOULD be sent, after switching
to a new key chain and after waiting for the disclosure delay d.
Roca, et al. Expires April 25, 2009 [Page 6]
Internet-Draft TESLA in ALC and NORM October 2008
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;
o 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;
o K_g is a shared group key, communicated to all group members,
confidentially, during the TESLA bootstrapping (Section 2.2);
o n_w is the length, in bits, of the truncated output of the MAC of
the optional group authentication scheme: only the n_w most
significant bits of the MAC output are kept. n_w is typically
small, multiple of 32 bits (e.g., 32 bits);
1.3.2. Notations and Definitions Related to Time
Notations and definitions related to time:
o 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 to 0 might take place in long
sessions.
o t_s is the sender local time value at some absolute time (in NTP
timestamp format);
o t_r is the receiver local time value at the same absolute time (in
NTP timestamp format);
o T_0 is the start time corresponding to the beginning of the
session (in NTP timestamp format);
o T_int is the interval duration (in milliseconds);
o d is the key disclosure delay (in number of intervals);
o D_t is the upper bound of the lag of the receiver's clock with
respect to the clock of the sender;
o S_sr is an estimated bound of the clock drift between the sender
and a receiver throughout the duration of the session;
Roca, et al. Expires April 25, 2009 [Page 7]
Internet-Draft TESLA in ALC and NORM October 2008
o D^O_t is the upper bound of the lag of the sender's clock with
respect to the time reference in indirect time synchronization
mode;
o D^R_t is the upper bound of the lag of the receiver's clock with
respect to the time reference in indirect time synchronization
mode;
o D_err is an upper bound of the time error between all the time
references, in indirect time synchronization mode;
o NTP timestamp format consists in a 64-bit unsigned fixed-point
number, in seconds relative to 0h on 1 January 1900. The integer
part is in the first 32 bits and the fraction part in the last 32
bits [RFC1305];
Roca, et al. Expires April 25, 2009 [Page 8]
Internet-Draft TESLA in ALC and NORM October 2008
2. Using TESLA with ALC and NORM: General Operations
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 a session. Therefore an
ALC session potentially includes a huge number (e.g., millions or
more) of 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 satellite (even if a back channel might exist in
some use cases) and broadcasting networks like DVB-H/SH;
o ALC defines an on-demand content delivery model [RMT-PI-ALC] 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: 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).
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.
In case of NORM:
o 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;
o 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;
Roca, et al. Expires April 25, 2009 [Page 9]
Internet-Draft TESLA in ALC and NORM October 2008
2.2. Bootstrapping TESLA
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:
o by using an out-of-band mechanism, or
o by using an in-band mechanism.
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.
2.2.1. Bootstrapping TESLA with an Out-Of-Band Mechanism
For instance [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.
2.2.2. Bootstrapping TESLA with an In-Band Mechanism
This specification describes an in-band mechanism. In some use-
cases, it might be desired 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 Section 3.4.1) and the knowledge of a few additional parameters
(listed below) are sufficient to bootstrap TESLA at a receiver.
Some parameters cannot be communicated in-band. In particular:
o the sender or group controller MUST either communicate the public
key of the sender or a certificate (which also means that a PKI
has been setup) to all receivers, so that each receiver be able to
verify the signature of the bootstrap message and direct time
synchronization response messages (when applicable).
o when time synchronization is performed with NTP/SNTP, the sender
or group controller MUST communicate the list of valid NTP/SNTP
Roca, et al. Expires April 25, 2009 [Page 10]
Internet-Draft TESLA in ALC and NORM October 2008
servers to all the session members (sender included), so that they
all be able to synchronize themselves on the same NTP/SNTP
servers.
o when the Group MAC feature is used, the sender or group controller
MUST communicate the K_g group key to all the session members
(sender included). This group key may be periodically refreshed.
The way these parameters are communicated is out of the scope of this
document.
2.3. Setting Up a Secure Time Synchronization
The security offered by TESLA heavily relies 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.
It is also possible that a given session include receivers that use
the direct time synchronization mode while others use the indirect
time synchronization mode.
2.3.1. Direct Time Synchronization
When direct time synchronization is used, each receiver asks the
sender for a time synchronization. To that purpose, a receiver sends
a "Direct Time Synchronization Request" (Section 4.2.2.1). The
sender then directly answers to each request with a "Direct Time
Synchronization Response" (Section 3.4.2), signing this reply. Upon
receiving this response, a receiver first verifies the signature, and
then calculates an upper bound of the lag of his clock with respect
to the clock of the sender, D_t. The details on how to calculate D_t
are given in Section 2.4.1.
This synchronization method is both simple and secure. Yet there are
two potential issues:
o a bidirectional channel must exist between the sender and each
receiver, and
o the sender may collapse if the incoming request rate is too high.
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
Roca, et al. Expires April 25, 2009 [Page 11]
Internet-Draft TESLA in ALC and NORM October 2008
that a mechanism, that is out of the scope of this document, be used
to spread the transmission of "Direct time synchronization request"
messages over the time if there is a risk that the sender may
collapse.
But direct time synchronization is potentially incompatible with ALC
since (1) there might not be a back channel and (2) there are
potentially a huge number of receivers and therefore a risk that the
sender collapses.
2.3.2. Indirect Time Synchronization
When indirect time synchronization is used, the sender and each
receiver must synchronize securely via an external time reference.
Several possibilities exist:
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 they can synchronize through a NTPv4 (Network Time Protocol
version 4) [NTP-NTPv4] hierarchy of servers. The Autokey security
protocol of NTPv4 MUST be used in order to authenticate each NTP
message individually;
o they can synchronize through a SNTPv4 (Simple Network Time
Protocol version 4) [RFC4330] hierarchy of servers. The
authentication features of SNTPv4 must then be used. Note that
TESLA only needs a loose (but secure) time synchronization, which
is in line with the time synchronization service offered by SNTP;
o they can synchronize through a GPS or Galileo (or similar) device
that also provides a high precision time reference. Spoofing
attacks on the GPS system have recently been reported. Depending
on the use case, the security achieved will be or not acceptable;
o 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.
A bidirectional channel is required by the NTP/SNTP schemes. On the
Roca, et al. Expires April 25, 2009 [Page 12]
Internet-Draft TESLA in ALC and NORM October 2008
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 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.
The details on how to calculate an upper bound of the lag of a
receiver's clock with respect to the clock of the sender, D_t, are
given in Section 2.4.2.
2.4. Determining the Delay Bounds
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.
2.4.1. Delay Bound Calculation in Direct Time Synchronization Mode
In direct time synchronization mode, synchronization between a
receiver and the sender follows the following protocol [RFC4082]:
o 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 (Section 4.2.2.1).
o 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
(Section 3.4.2), signing this reply.
o 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.
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.
Roca, et al. Expires April 25, 2009 [Page 13]
Internet-Draft TESLA in ALC and NORM October 2008
2.4.2. Delay Bound Calculation in Indirect time Synchronization Mode
In indirect time synchronization, the sender and the receivers must
synchronize indirectly with one or several time references.
2.4.2.1. Single time reference
Let us assume that there is a single time reference.
1. The sender calculates D^O_t, the upper bound of the lag of the
sender's clock with respect to the time reference. This D^O_t
value is then be communicated to the receivers (Section 3.2.1).
2. Similarly, a receiver R calculates D^R_t, the upper bound of the
lag of the receiver's clock with respect to the time reference.
3. Then, for receiver R, the overall upper bound of the lag of the
receiver's clock with respect to the clock of the sender, D_t, is
the sum: D_t = D^O_t + D^R_t.
The D^O_t and D^R_t calculation depends on the time synchronization
mechanism used (Section 2.3.2). In some cases, the synchronization
scheme specifications provide these values. In other cases, these
parameters can be calculated by means of a scheme similar to the one
specified in Section 2.4.1, for instance when synchronization is
achieved via a group controller [RFC4082].
2.4.2.2. Multiple time references
Let us now assume that there are several time references (e.g.,
several NTP/SNTP servers). The sender and receivers use the direct
time synchronization scheme to synchronize with the various time
references. It results in D^O_t and D^R_t. Let D_err be an upper
bound of the time error between all the time references. Then, the
overall value of D_t within receiver R is set to the sum: D_t = D^O_t
+ D^R_t + D_err.
In some cases, the D_t value is part of the time synchronization
scheme specifications. For instance NTPv3 [RFC1305] 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.
Roca, et al. Expires April 25, 2009 [Page 14]
Internet-Draft TESLA in ALC and NORM October 2008
3. Sender Operations
This section describes the TESLA operations at a sender.
3.1. TESLA Parameters
3.1.1. Time Intervals
The sender divides the time into uniform intervals of duration T_int.
Time interval numbering starts at 0 and is incremented consecutively.
The interval index MUST be stored in an unsigned 32 bit integer so
that wrapping to 0 takes place only after 2^^32 intervals. For
instance, if T_int is equal to 0.5 seconds, then wrapping takes place
after approximately 68 years.
3.1.2. Key Chains
3.1.2.1. Principles
The sender computes a one-way key chain of n_c = N+1 keys, and
assigns one key from the chain to each interval, consecutively but in
reverse order. Key numbering starts at 0 and is incremented
consecutively, following the time interval numbering: K_0, K_1 ..
K_N.
In order to compute this chain, the sender must first select a
Primary Key, K_N, and a PRF function, f. The functions F and F' are
two one-way functions that are defined as: F(k)=f_k(0) and
F'(k)=f_k(1), where f_k is the result of the k-th application of the
PRF function f. The sender computes all the keys of the 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 and no one should be able to guess it.
The key chain has a finite length, N, which corresponds to a maximum
time duration of (N + 1) * T_int. The content delivery session has a
duration T_delivery, which 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 Figure 1)
[Perrig04].
Roca, et al. Expires April 25, 2009 [Page 15]
Internet-Draft TESLA in ALC and NORM October 2008
3.1.2.2. Using Multiple Key Chains
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.
< -------- old key chain --------- >||< -------- new key chain --...
+-----+-----+ .. +-----+-----+-----+||+-----+-----+-----+-----+-----+
0 1 .. N-2 N-1 N || N+1 N+2 N+3 N+4 N+5
||
Key disclosures: ||
N/A N/A .. K_N-4 K_N-3 K_N-2 || K_N-1 K_N K_N+1 K_N+2 K_N+3
| || | |
|< -------------- >|| |< ------------- >|
Additional key F(K_N+1) || K_N
disclosures (commitment to || (last key of the
(in parallel): the new chain) || old chain)
Figure 1: Switching to the second key chain with the in-band
mechanism, assuming that d=2, n_tx_newkcc=3, n_tx_lastkey=3.
Figure 1 illustrates the switch to the new key chain, using the in-
band mechanism. Let us say that the old key chain stops at K_N and
the new key chain starts at K_{N+1} (i.e., F(K_{N+1}) and K_N are two
different keys). Then the sender includes the commitment F(K_{N+1})
to the new key chain to packets authenticated with the old key chain
(see Section 3.4.5). This commitment SHOULD be sent during
n_tx_newkcc time intervals before the end of the old key chain.
Since several packets are usually sent during an interval, the sender
SHOULD alternate between sending a disclosed key of the old key chain
and the commitment to the new key chain. The details of how to
alternate between the disclosure and commitment are out of the scope
of this document.
The receiver will keep the commitment until the key K_{N+1} is
disclosed, at interval N+1+d. Then the receiver will be able to test
the validity of that key by computing F(K_{N+1}) and comparing it to
the commitment.
When the key chain is changed, it becomes impossible to recover a
previous key from the old key chain. This is a problem if the
receiver lost the packets disclosing the last key of the old key
chain. A solution consists in re-sending the last key, K_N, of the
old key chain (see Section 3.4.6). This SHOULD be done during
Roca, et al. Expires April 25, 2009 [Page 16]
Internet-Draft TESLA in ALC and NORM October 2008
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.
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 (Section 3.2.1).
3.1.2.3. Values of the n_tx_lastkey and n_tx_newkcc Parameters
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:
d + n_tx_lastkey + n_tx_newkcc <= N + 1
It is RECOMMENDED, for robustness purposes, that, once n_tx_lastkey
has been chosen, then:
n_tx_newkcc = N + 1 - n_tx_lastkey - d
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.
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).
Roca, et al. Expires April 25, 2009 [Page 17]
Internet-Draft TESLA in ALC and NORM October 2008
3.1.2.4. The Particular Case of the Session Start
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 Figure 1) of the session. To that purpose, the sender uses
the standard authentication tag without key disclosure Section 3.4.4
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.
3.1.2.5. Managing Silent Periods
An ALC or NORM sender may stop transmitting packets for some time.
For instance 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 any case, 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.
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 (or its
compact flavor) 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).
3.1.3. 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 length of a key chain;
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 *
Roca, et al. Expires April 25, 2009 [Page 18]
Internet-Draft TESLA in ALC and NORM October 2008
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 known) will require the
sender to compute too many useless keys. [RFC4082] sections 3.2 and
3.6 give general guidelines for initializing these parameters.
The T_0, T_int, d and N parameters MUST NOT be changed during the
lifetime of the session. This restriction is meant to prevent
introducing vulnerabilities. For instance if a sender 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 [RFC4082].
3.1.4. Timing Parameters
In indirect time synchronization mode, the sender must determine the
following parameter:
o D^O_t, the upper bound of the lag of the sender's clock with
respect to the time reference.
The D^O_t parameter MUST NOT be changed during the lifetime of the
session.
3.2. TESLA Signaling Messages
At a sender, TESLA produces two types of signaling information:
o The bootstrap information: it 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;
o The direct time synchronization response, which enables a receiver
to finish a direct time synchronization;
3.2.1. Bootstrap Information
In order to initialize the TESLA component at a receiver, the sender
must communicate some key information in a secure way. This
information can be sent in-band or out-of-band, as discussed in
Section 2.2. In this section we only consider the in-band scheme.
The TESLA bootstrap information message MUST be digitally signed
(Section 3.3.2). The goal is to enable a receiver to check the
packet source and packet integrity. Then, the bootstrap information
can be:
Roca, et al. Expires April 25, 2009 [Page 19]
Internet-Draft TESLA in ALC and NORM October 2008
o unicast to a receiver during a direct time synchronization
request/response exchange;
o 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.
Let us 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.
A periodic broadcast of the bootstrap information message could also
be useful 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 important when several key chains are used in an ALC
or NORM session, since there is a risk that a receiver loses 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 period of a few seconds for the
transmission of this bootstrap information is often a reasonable
value.
3.2.2. Direct Time Synchronization Response
In Direct Time Synchronization, upon receipt of a synchronization
request, the sender records its local time, t_s, and sends a response
message that contains both t_r and t_s (Section 2.4.1). This message
is unicast to the receiver. This Direct Time Synchronization
Response message MUST be digitally signed in order to enable a
receiver to check the packet source and packet integrity
(Section 3.3.2). The receiver MUST also be able to associate this
response and his request, which is the reason why t_r is included in
the response message.
Roca, et al. Expires April 25, 2009 [Page 20]
Internet-Draft TESLA in ALC and NORM October 2008
3.3. TESLA Authentication Information
At a sender, TESLA produces three types of security tags:
o an authentication tag, in case of data packets, and which contains
the MAC of the packet;
o a digital signature, in case of one of the two TESLA signaling
packets, namely a Bootstrap Information Message or a Direct Time
Synchronization Response; and
o an optional group authentication tag, that can be added to all the
packets to mitigate attacks coming from outside of the group.
Because of interdependencies, their computation MUST follow a strict
order:
o first of all, compute the authentication tag (with data packet) or
the digital signature (with signaling packet);
o finally compute the Group Mac;
3.3.1. Authentication Tags
All the data packets sent MUST have an authentication tag containing:
o the interval index, i, which is also the index of the key used for
computing the MAC of this packet. With the compact authentication
tags, a subset of i will be communicated. In that case, a
receiver must guess the original i value from the few bits carried
in the packet (Section 4.3);
o the MAC of the message: MAC(K'_i, M), where K'_i=F'(K_i);
o either a disclosed key (that belongs to the current key chain or
the previous key chain), or a commitment to a new key chain, or no
key at all;
The computation of MAC(K'_i, M) MUST include the ALC or NORM header
(with the various header extensions) and the payload (when
applicable). The UDP/IP headers MUST NOT be included. During this
computation, the MAC(K'_i, M) field of the authentication tag MUST be
set to 0.
3.3.2. Digital Signatures
The Bootstrap Information message (with the in-band bootstrap scheme)
and Direct Time Synchronization Response message (with the indirect
Roca, et al. Expires April 25, 2009 [Page 21]
Internet-Draft TESLA in ALC and NORM October 2008
time synchronization scheme) both need to be signed by the sender.
These two messages contain a "Signature" field to hold the digital
signature. The bootstrap information message also contains the
"Signature Encoding Algorithm", the "Signature Cryptographic
Function", and the "Signature Length" fields that enable a receiver
to process the "Signature" field. Note that there is no such
"Signature Encoding Algorithm", "Signature Cryptographic Function"
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).
Several "Signature Encoding Algorithms" can be used, including
RSASSA-PKCS1-v1_5, the default, and RSASSA-PSS (Section 7). With
these encodings, SHA-1 is the default "Signature Cryptographic
Function".
The computation of the signature MUST include the ALC or NORM header
(with the various header extensions) and the payload when applicable.
The UDP/IP headers MUST NOT be included. During this computation,
the "Signature" field MUST be set to 0 as well as the optional Group
MAC, when present, since this Group MAC is calculated later on.
More specifically, from [RFC4359]: digital signature generation is
performed as described in [RFC3447], Section 8.2.1 for RSASSA-PKCS1-
v1_5 and Section 8.1.1 for RSASSA-PSS. The authenticated portion of
the packet is used as the message M, which is passed to the signature
generation function. The signer's RSA private key is passed as K. In
summary (when SHA-1 is used), the signature generation process
computes a SHA-1 hash of the authenticated packet bytes, signs the
SHA-1 hash using the private key, and encodes the result with the
specified RSA encoding type. This process results in a value S,
which is the digital signature to be included in the packet.
With RSASSA-PKCS1-v1_5 and RSASSA-PSS signatures, the size of the
signature is equal to the "RSA modulus", unless the "RSA modulus" is
not a multiple of 8 bits. In that case, the signature MUST be
prepended with between 1 and 7 bits set to zero such that the
signature is a multiple of 8 bits [RFC4359]. The key size, which in
practice is also equal to the "RSA modulus", has major security
implications. [RFC4359] explains how to choose this value depending
on the maximum expected lifetime of the session. This choice is out
of the scope of this document.
Roca, et al. Expires April 25, 2009 [Page 22]
Internet-Draft TESLA in ALC and NORM October 2008
3.3.3. Group MAC Tags
An optional Group MAC can be used to mitigate DoS attacks coming from
attackers that are not group members [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:
o a receiver can immediately drop faked packets, without having to
wait for the disclosure delay, d;
o a sender can immediately drop faked direct time synchronization
requests, and avoid to check the digital signature, a computation
intensive task;
o a receiver can immediately drop faked direct time synchronization
response and bootstrap messages, without having to verify the
digital signature, a computation intensive task;
The computation of the group MAC, MAC(K_g, M), MUST include the ALC
or NORM header (with the various header extensions) and the payload
when applicable. The UDP/IP headers MUST NOT be included. During
this computation, the Group MAC field MUST be set to 0. However the
digital signature (e.g., of a bootstrap message) and the MAC fields
(e.g., of an authentication tag), when present, MUST have been
calculated since they are included in the Group MAC calculation
itself. Then the sender truncates the MAC output to keep the n_w
most significant bits and stores the result in the Group MAC field.
This scheme features a few limits:
o it is of no help if a group member (who knows K_g) impersonates
the sender and sends forged messages to other receivers;
o it requires an additional MAC computing for each packet, both at
the sender and receiver sides;
o it increases the size of the TESLA authentication headers. In
order to limit this problem, the length of the truncated output of
the MAC, n_w, SHOULD be kept small (e.g., 32 bits) (see [RFC3711]
section 9.5). As a side effect, the authentication service is
significantly weakened: the probability that any forged packet be
successfully authenticated becomes one in 2^32. Since the group
MAC check is only a pre-check that must be followed by the
standard TESLA authentication check, this is not considered to be
an issue.
For a given use-case, the benefits brought by the group MAC must be
Roca, et al. Expires April 25, 2009 [Page 23]
Internet-Draft TESLA in ALC and NORM October 2008
balanced against these limitations.
Note that the Group MAC function can be different from the TESLA MAC
function (e.g., it can use a weaker but faster MAC function). Note
also that the mechanism by which the group key, K_g, is communicated
to all group members, and perhaps periodically updated, is out of the
scope of this document.
3.4. Format of TESLA Messages and Authentication Tags
This section specifies the format of the various kinds of TESLA
messages and authentication tags sent by the session's sender.
Because these TESLA messages are carried as EXT_AUTH header
extensions of the ALC or NORM packets (Section 5), the following
formats do not start on 32 bit word boundaries.
3.4.1. Format of a Bootstrap Information Message
When bootstrap information is sent in-band, the following message is
used:
Roca, et al. Expires April 25, 2009 [Page 24]
Internet-Draft TESLA in ALC and NORM October 2008
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+ ---
| V |resvd|S|G|A| ^
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| d | PRF Type | MAC Func Type |WG MAC Fun Type| | f
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | i
| SigEncAlgo | SigCryptoFunc | Signature Key Length | | x
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | e
| Reserved | T_int | | d
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | l
+ T_0 (NTP timestamp format) + | e
| | | n
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | g
| N (Key Chain Length) | | t
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h
| Current Interval Index i | v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
| |
~ Current Key Chain Commitment +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
~ Signature ~
+ +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P| |
+-+ D^O_t Extension (optional, present if A==1) +
| (NTP timestamp diff, positive if P==1, negative if P==0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Group MAC (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Bootstrap information format.
The format of the bootstrap information is depicted in Figure 2. The
fields are:
"V" (Version) field (2 bits):
The "V" field contains the version number of the protocol. For
this specification, the value of 0 MUST be used.
"Reserved" field (3 bits):
Roca, et al. Expires April 25, 2009 [Page 25]
Internet-Draft TESLA in ALC and NORM October 2008
This is a reserved field that MUST be set to zero in this
specification.
"S" (Single Key Chain) flag (1 bits):
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).
"G" (Group MAC Present) flag (1 bits):
The "G" flag indicates whether the Group MAC feature is used
(G==1) or not (G==0). When it is used, a "Group MAC" field is
added to all the packets containing a TESLA EXT_AUTH Header
Extension (including this bootstrap message).
"A" flag (1 bit):
The "A" flag indicates whether the P flag and D^O_t fields are
present (A==1) or not (A==0). In indirect time synchronization
mode, A MUST be equal to 1 since these fields are needed.
"d" field (8 bits):
d is an unsigned integer that defines the key disclosure delay (in
number of intervals). d MUST be greater or equal to 2.
"PRF Type" field (8 bits):
The "PRF Type" is the reference number of the f function used to
derive the F (for key chain) and F' (for MAC keys) functions
(Section 7).
"MAC Function Type" field (8 bits):
The "MAC Function Type" is the reference number of the function
used to compute the MAC of the packets (Section 7).
"Group MAC Function Type" field (8 bits):
When G==1, this field contains the reference number of the
cryptographic MAC function used to compute the group MAC
(Section 7). When G==0, this field MUST be set to zero.
"Signature Encoding Algorithm" field (8 bits):
Roca, et al. Expires April 25, 2009 [Page 26]
Internet-Draft TESLA in ALC and NORM October 2008
The "Signature Encoding Algorithm" is the reference number
(Section 7) of the digital signature used to authenticate this
bootstrap information and included in the "Signature" field.
"Signature Cryptographic Function" field (8 bits):
The "Signature Cryptographic Function" is the reference number
(Section 7) of the cryptographic function used within the digital
signature.
"Signature Key Length" field (12 bits):
The "Signature Length" is an unsigned integer that indicates the
signature field size in bytes in the "Signature Extension" field.
"Reserved" fields (16 bits):
This is a reserved field that MUST be set to zero in this
specification.
"T_int" field (16 bits):
T_int is an unsigned 16 bit integer that defines the interval
duration (in milliseconds).
"T_0" field (64 bits):
"T_0" is a timestamp in NTP timestamp format that indicates the
time when this session began.
"N" field (32 bits):
"N" is an unsigned integer that indicates the key chain length.
There are N + 1 keys per chain.
"i" (Interval Index of K_i) field (32 bits):
"i" is an unsigned integer that indicates the current interval
index when this bootstrap information message is sent.
"Current Key Chain Commitment" field (variable size, padded if
necessary for 32 bit word alignment):
"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
Roca, et al. Expires April 25, 2009 [Page 27]
Internet-Draft TESLA in ALC and NORM October 2008
of 32 bits.
"Signature" field (variable size, padded if necessary for 32 bit word
alignment):
The "Signature" field is mandatory. It contains a digital
signature of this message, as specified by the encoding algorithm,
cryptographic function and key length parameters. If the
signature length is not multiple of 32 bits, this field is padded
with 0.
"P" flag (optional, 1 bit if present):
The "P" flag is optional and only present if the A flag is equal
to 1.. It is only used in indirect time synchronization mode.
This flag indicates whether the D^O_t NTP timestamp difference is
positive (P==1) or negative (P==0).
"D^O_t" field (optional, 63 bits if present):
The "D^O_t" field is optional and only present if the A flag is
equal to 1. 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.
"Group MAC" field (optional, variable length, multiple of 32 bits):
This field contains the group MAC, calculated with the group key,
K_g, shared by all group members. The field length, in bits, is
given by n_w which is known once the group MAC function type is
known (Section 7).
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 Group MAC fields are optional.
In order to prevent attacks, some parameters MUST NOT be changed
during the lifetime of the session (Section 3.1.3, Section 3.1.4).
The following table summarizes the parameters status:
Roca, et al. Expires April 25, 2009 [Page 28]
Internet-Draft TESLA in ALC and NORM October 2008
+--------------------------+----------------------------------------+
| Parameter | Status |
+--------------------------+----------------------------------------+
| V | set to 0 in this specification |
| | |
| S | static (during whole session) |
| | |
| G | static (during whole session) |
| | |
| A | static (during whole session) |
| | |
| T_O | static (during whole session) |
| | |
| T_int | static (during whole session) |
| | |
| d | static (during whole session) |
| | |
| N | static (during whole session) |
| | |
| D^O_t (if present) | static (during whole session) |
| | |
| PRF Type | static (during whole session) |
| | |
| MAC Function Type | static (during whole session) |
| | |
| Signature Encoding | static (during whole session) |
| Algorithm | |
| | |
| Signature Crypto. | static (during whole session) |
| Function | |
| | |
| Signature Length | static (during whole session) |
| | |
| Group MAC Func. Type | static (during whole session) |
| | |
| i | dynamic (related to current key chain) |
| | |
| K_i | dynamic (related to current key chain) |
| | |
| signature | dynamic, packet dependent |
| | |
| Group MAC (if present) | dynamic, packet dependent |
+--------------------------+----------------------------------------+
Roca, et al. Expires April 25, 2009 [Page 29]
Internet-Draft TESLA in ALC and NORM October 2008
3.4.2. Format of a Direct Time Synchronization Response
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ t_s (NTP timestamp) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ t_r (NTP timestamp) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
~ Signature ~
+ +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Group MAC (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Format of a Direct Time Synchronization Response
The response to a direct time synchronization request contains the
following information:
"Reserved" fields (8 bits):
This is a reserved field that MUST be set to zero in this
specification.
"t_s" (NTP timestamp, 64 bits):
t_s is a timestamp in NTP timestamp format that corresponds to the
sender local time value when receiving the direct time
synchronization request message.
"t_r" (NTP timestamp, 64 bits):
t_r is a timestamp in NTP timestamp format that contains the
receiver local time value received in the direct time
synchronization request message.
"Signature" field (variable size, padded if necessary for 32 bit word
Roca, et al. Expires April 25, 2009 [Page 30]
Internet-Draft TESLA in ALC and NORM October 2008
alignment):
The "Signature" field is mandatory. It contains a digital
signature of this message, as specified by the encoding algorithm,
cryptographic function and key length parameters communicated in
the bootstrap information message (if applicable) or out-of-band.
If the signature length is not multiple of 32 bits, this field is
padded with 0.
"Group MAC" field (optional, variable length, multiple of 32 bits):
This field contains the Group MAC, calculated with the group key,
K_g, shared by all group members. The field length, in bits, is
given by n_w, which is known once the group MAC function type is
known (Section 7).
3.4.3. Format of a Standard Authentication Tag
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| i (Interval Index of K'_i) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Disclosed Key K_{i-d} ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ MAC(K'_i, M) +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Group MAC (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Format of the authentication tag
Figure 4 shows the format of the authentication tag:
"Reserved" field (8 bits):
The "Reserved" field is not used in the current specification and
MUST be set to zero by the sender.
"i" (Interval Index) field (32 bits):
Roca, et al. Expires April 25, 2009 [Page 31]
Internet-Draft TESLA in ALC and NORM October 2008
i is the interval index associated to the key (K'_i) used to
compute the MAC of this packet.
"Disclosed Key" (variable size, non padded):
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. There is no padding between the "Disclosed Key" and
"MAC(K'_i, M)" fields, and this latter MAY not start on a 32 bit
boundary, depending on the n_p parameter.
"MAC(K'_i, M)" (variable size, padded if necessary for 32 bit word
alignment):
MAC(K'_i, M) is the truncated message authentication code of the
current packet. Only the n_m most significant bits of the MAC
output are kept [RFC2104].
"Group MAC" field (optional, variable length, multiple of 32 bits):
This field contains the Group MAC, calculated with a group key,
K_g, shared by all group members. The field length is given by
n_w, in bits.
Note that because a key cannot be disclosed before the disclosure
delay, d, the sender MUST NOT use this tag during the first d
intervals of the session: {0 .. d-1} (inclusive). Instead the sender
MUST use a Standard or a Compact Authentication Tag Without Key
Disclosure.
3.4.4. Format of a Standard Authentication Tag Without Key Disclosure
The authentication tag without key disclosure is meant to be used in
situations where a high number of packets are sent in a given time
interval. In such a case, it can be advantageous to disclose the
K_{i-d} key only in a subset of the packets sent, using a standard
authentication tag, and use the shortened version that does not
disclose the K_{i-d} key in the remaining packets. It is left to the
implementer to decide how many packets should disclose the K_{i-d}
key. This authentication tag or its compact flavor MUST also be used
during the first d intervals: {0 .. d-1} (inclusive).
Roca, et al. Expires April 25, 2009 [Page 32]
Internet-Draft TESLA in ALC and NORM October 2008
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| i (Interval Index of K'_i) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ MAC(K'_i, M) +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Group MAC (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Format of the authentication tag without key disclosure
3.4.5. Format of an Authentication Tag with a ``New Key Chain''
Commitment
During the last n_tx_newkcc intervals of the current key chain, the
sender SHOULD send commitments to the next key chain. This is done
by replacing the disclosed key of the authentication tag with the new
key chain commitment, F(K_{N+1}) (or F(K_{2N+2}) in case of a switch
between the second and third key chains, etc.). Figure 6 shows the
corresponding format.
Note that since there is no padding between the "F(K_{N+1})" and
"MAC(K'_i, M)" fields, this latter MAY not start on a 32 bit
boundary, depending on the n_p parameter.
Roca, et al. Expires April 25, 2009 [Page 33]
Internet-Draft TESLA in ALC and NORM October 2008
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| i (Interval Index of K'_i) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ New Key Commitment F(K_{N+1}) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ MAC(K'_i, M) +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Group MAC (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Format of the authentication tag with a new key chain
commitment
3.4.6. Format of an Authentication Tag with a ``Last Key of Old Chain''
Disclosure
During the first n_tx_lastkey intervals of the new key chain after
the disclosing interval, d, the sender SHOULD disclose the last key
of the old key chain. This is done by replacing the disclosed key of
the authentication tag with the last key of the old chain, K_N (or
K_{2N+1} in case of a switch between the second and third key chains,
etc.). Figure 7 shows the corresponding format.
Note that since there is no padding between the "K_N" and "MAC(K'_i,
M)" fields, this latter MAY not start on a 32 bit boundary, depending
on the n_p parameter.
Roca, et al. Expires April 25, 2009 [Page 34]
Internet-Draft TESLA in ALC and NORM October 2008
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| i (Interval Index of K'_i) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Last Key of Old Chain, K_N ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ MAC(K'_i, M) +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Group MAC (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Format of the authentication tag with an old chain last key
disclosure
3.4.7. Format of the Compact Authentication Tags
The four compact flavors of the Authentication tags follow.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+
| i_LSB |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Disclosed Key K_{i-d} ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ MAC(K'_i, M) +-+-+-+-+-+-+-+-+
| | i_NSB (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Group MAC (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Format of the compact authentication tag
Roca, et al. Expires April 25, 2009 [Page 35]
Internet-Draft TESLA in ALC and NORM October 2008
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Group MAC (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Format of the compact authentication tag without key
disclosure
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+
| i_LSB |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ New Key Commitment F(K_{N+1}) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ MAC(K'_i, M) +-+-+-+-+-+-+-+-+
| | i_NSB (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Group MAC (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Format of the compact authentication tag with a new key
chain commitment
Roca, et al. Expires April 25, 2009 [Page 36]
Internet-Draft TESLA in ALC and NORM October 2008
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Group MAC (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Format of the compact authentication tag with a last key
of old chain disclosure
where:
"i_LSB" (Interval Index Least Significant Byte) field (8 bits):
the i_LSB field contains the least significant byte of the
interval index associated to the key (K'_i) used to compute the
MAC of this packet.
"i_NSB" (Interval Index Next Significant Bytes) field (variable
length, depending on the MAC type):
the i_NSB field contains the next significant bytes (after i_LSB)
of the interval index. This field replaces the "Padding" field
when the MAC(K'_i, M) field length is not a multiple of 32 bits.
The compact version does not include the "i" interval index but the
"i_LSB" field and sometimes, depending on the MAC type, the "i_NSB"
field. Upon receiving such an authentication tag, a receiver infers
the associated "i" value, by estimating the current interval where
the sender is supposed to be, assuming that this packet has not been
significantly delayed by the network. The remaining of the
processing does not change.
For instance, with HMAC-SHA-1, the MAC(K'_i, M) field is 10 byte
long. In that case the i_NSB field contains the middle two bytes of
"i". 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"
Roca, et al. Expires April 25, 2009 [Page 37]
Internet-Draft TESLA in ALC and NORM October 2008
field) for sessions that last at most 2330 hours.
Roca, et al. Expires April 25, 2009 [Page 38]
Internet-Draft TESLA in ALC and NORM October 2008
4. Receiver Operations
This section describes the TESLA operations at a receiver.
4.1. Verification of the Authentication Information
This section details the computation steps required to verify each of
the three possible authentication information of an incoming packet.
The verification MUST follow a strict order:
o first of all, verify the Group Mac if present;
o then verify the digital signature (with TESLA signaling packets)
or enter the TESLA authentication process (with data packets)
4.1.1. Processing the Group MAC Tag
Upon receiving a packet containing a Group MAC Tag, 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.
More specifically, recomputing the Group MAC requires to save the
value of the Group MAC field, to set this field to 0, and to do the
same computation as a sender does (see Section 3.3.3).
4.1.2. Processing the Digital Signature
Upon receiving a packet containing a digital signature, the receiver
verifies the signature as follows.
The computation of the signature MUST include the ALC or NORM header
(with the various header extensions) and the payload when applicable.
The UDP/IP headers MUST NOT be included. During this computation,
the "Signature" field MUST be set to 0 as well as the optional Group
MAC, when present.
From [RFC4359]: Digital signature verification is performed as
described in [RFC3447], Section 8.2.2 (RSASSA-PKCS1-v1_5) and
[RFC3447], Section 8.1.2 (RSASSA-PSS). Upon receipt, the digital
signature is passed to the verification function as S. The
authenticated portion of the packet is used as the message M, and the
RSA public key is passed as (n, e). In summary (when SHA-1 is used),
the verification function computes a SHA-1 hash of the authenticated
packet bytes, decrypts the SHA-1 hash in the packet, and validates
that the appropriate encoding was applied. The two SHA-1 hashes are
compared, and if they are identical the validation is successful.
It is assumed that the receivers have the possibility to retrieve the
Roca, et al. Expires April 25, 2009 [Page 39]
Internet-Draft TESLA in ALC and NORM October 2008
sender's public key required to check this digital signature
(Section 2.2). This document does not specify how the public key of
the sender is communicated reliably and in a secure way to all
possible receivers.
4.1.3. Processing the Authentication Tag
When a receiver wants to authenticate a packet using an
Authentication Tag and when he has the key for the associated time
interval (i.e., after the disclosing delay, d), the receiver
recomputes the MAC and compares it to the value carried in the
packet. If the check fails, the packet MUST be immediately dropped.
More specifically, recomputing the MAC requires to save the value of
the MAC field, to set this field to 0, and to do the same computation
as a sender does (see Section 3.3.1).
4.2. Initialization of a Receiver
A receiver must be initialized before being able to authenticate the
source of incoming packets. This can be done by an out-of-band
mechanism or an in-band mechanism (Section 2.2). Let us focus on the
in-band mechanism. 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. To that
purpose, the receiver must perform time synchronization.
4.2.1. Processing the Bootstrap Information Message
A receiver must first receive a packet containing the bootstrap
information, digitally signed by the sender. Once the bootstrap
information has been authenticated (sec Section 4.1), the receiver
can initialize its TESLA component. The receiver MUST then ignore
the following bootstrap information messages, if any. There is an
exception though: when a new key chain is used and if a receiver
missed all the commitments for this new key chain, then this receiver
MUST process one of the future Bootstrap information messages (if
any) in order to be able to authenticate the incoming packets
associated to this new key chain.
Before TESLA has been initialized, a receiver MUST NOT process
incoming packets other than the bootstrap information message and
direct time synchronization response.
Roca, et al. Expires April 25, 2009 [Page 40]
Internet-Draft TESLA in ALC and NORM October 2008
4.2.2. Performing Time Synchronization
First of all, the receiver must know whether the ALC or NORM session
relies on direct or indirect time synchronization. This information
is communicated by an out-of-band mechanism (for instance when
describing the various parameters of an ALC or NORM session. In some
cases, both mechanisms might be available and the receiver can choose
the preferred technique.
4.2.2.1. Direct Time Synchronization
In case of a direct time synchronization, a receiver MUST synchronize
with the sender. To that purpose, the receiver sends a direct time
synchronization request message. This message includes the local
time (in NTP timestamp format) at the receiver when sending the
message. This timestamp will be copied in the sender's response for
the receiver to associate the response to the request.
The direct time synchronization request message format is the
following:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ t_r (NTP timestamp) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Group MAC (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: Format of a Direct Time Synchronization Request
The direct time synchronization request (Figure 12) contains the
following information:
"t_r" (NTP timestamp, 64 bits):
t_r is a timestamp in NTP timestamp format that contains the
receiver local time value when sending this direct time
synchronization request message;
"Group MAC" field (optional, variable length, multiple of 32 bits):
This field contains the Group MAC, calculated with the group key,
K_g, shared by all group members. The field length, in bits, is
given by n_w, which is known once the Group MAC function type is
Roca, et al. Expires April 25, 2009 [Page 41]
Internet-Draft TESLA in ALC and NORM October 2008
known (Section 7).
The receiver then awaits a response message (Section 3.4.2). Upon
receiving this message, the receiver:
checks that this response relates to the request, by comparing the
t_r fields;
checks the Group MAC if present;
checks the signature;
retrieves the t_s value and calculates D_t (Section 2.4.1);
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.
4.2.2.2. Indirect Time Synchronization
With the indirect time synchronization method, the sender MAY provide
out-of-band the URL or IP address of the NTP server(s) he trusts
along with an OPTIONAL certificate for each NTP server. When several
NTP servers are specified, a receiver MUST choose one of them. This
document does not specify how the choice is made, but for the sake of
scalability, the clients SHOULD NOT use the same server if several
possibilities are offered. The NTP synchronization between the NTP
server and the receiver MUST be authenticated, either using the
certificate provided by the 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, (which often requires root privileges), computing the
time offset is sufficient.
Since the offset between the server and the time reference, D^O_t, is
indicated in the bootstrap information message (or communicated out-
of-band), the receiver can now calculate an upper bound of the
sender's local time (Section 2.4.2).
4.3. Authentication of Received Packets
The receiver can now authenticate incoming packets (other than
bootstrap information and direct time synchronization response
packets). To that purpose, he MUST follow different steps (see
[RFC4082] section 3.5):
Roca, et al. Expires April 25, 2009 [Page 42]
Internet-Draft TESLA in ALC and NORM October 2008
1. 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.
2. Safe packet test: When the receiver receives packet P_j, it first
records the local time T at which the packet arrived. The
receiver then computes an upper bound t_j on the sender's clock
at the time when the packet arrived: t_j = T + D_t. The receiver
then computes the highest interval the sender could possibly be
in: highest_i = floor((t_j - T_0) / T_int). Two possibilities
arise then:
* with a non compact authentication tag, the "i" interval index
is available. Get it from the header.
* 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:
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;
}
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
Roca, et al. Expires April 25, 2009 [Page 43]
Internet-Draft TESLA in ALC and NORM October 2008
not necessarily authentic). If the test fails, the packet is
unsafe, and the receiver MUST discard the packet.
3. Group MAC test: The receiver checks the optional Group Tag, if
present. To that purpose, the receiver recomputes the group MAC
and compares it to the value stored in the "Group MAC" field. If
the check fails, the packet is immediately dropped.
4. Disclosed Key processing: When the packet discloses a key (i.e.,
with a standard or compact authentication tag, or with a standard
or compact authentication tag with a last key of old chain
disclosure), the following tests are performed:
* New key index test: the receiver checks whether a legitimate
key already exists with the same index (i.e., i-d). If such a
legitimate key exists, the receiver compares its value with
the current disclosed key and if they are identical, skips the
"Key verification test". If such a legitimate key exists but
the values differ, the receiver MUST discard the packet.
* 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, as well as all the keys between indexes v and i-d.
5. When applicable, the receiver performs congestion control, even
if the packet has not yet been authenticated [RMT-BB-LCT]. 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.
6. 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.
7. 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
Roca, et al. Expires April 25, 2009 [Page 44]
Internet-Draft TESLA in ALC and NORM October 2008
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.
8. 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
(Section 4.4).
9. The receiver continues the ALC or NORM processing of all the
packets authenticated during the authentication test.
In this specification, a receiver using TESLA MUST immediately drop
unsafe packets. But the receiver MAY also decide, at any time, to
continue an ALC or NORM session in unsafe mode, ignoring TESLA
extensions.
4.3.1. Wrong Guess of the i Parameter
When a compact authentication tag is used, the receiver computes the
"i" interval index from the "i_LSB" and perhaps "i_NSB" fields, and
therefore there is a risk of error. Let us consider the case where
only "i_LSB" is used (situation with the highest risks of error). An
error occurs when the calculated i_high (at a receiver) differs from
the original i_high (at the sender), where the receiver calculates
i_high by: i_high = floor((t_j - T_0) / T_int) & 0xFFFFFF00). So an
error occurs if the elapsed time: t_j - T_0 >= K*(256*T_int), where K
is an integer greater or equal to 1. So there will be an error if
the packet has been delayed by at least 256*T_int milliseconds.
Since T_int is roughly equal to the RTT, the probability is low.
This is even more true when both "i_LSB" and "i_NSB" fields are used.
Of course, an attacker can also deliberately corrupt the
"i_LSB"/"i_NSB" fields, but the same remark can be done with the "i"
field.
If ever an error occurs, be it intentional (attack) or not, this
error will be caught either (Section 4.3):
Roca, et al. Expires April 25, 2009 [Page 45]
Internet-Draft TESLA in ALC and NORM October 2008
o by the safe packet test (step 2), or
o by the new key index test (step 4a) or key verification test (step
4b) if this packet discloses a key,
o or by the authentication test (step 7), when the key corresponding
to this wrong interval index is disclosed.
TESLA is therefore robust to wrong "i" parameter values.
4.3.2. Discarding Unnecessary Packets Earlier
Following strictly the above steps can lead to excessive processing
overhead in certain situations. This is the case when a receiver
receives packets for an unwanted object with the ALC or NORM
protocols, i.e., an object for which the application (or the end
user) explicitly mentioned it is not interested in. This is also the
case when a receiver receivers packets for an already decoded object,
or when this object has been partitioned in several blocks, for an
already decoded block. When such a packet is received, which is
easily identified by looking at the receiver's status for the
incoming ALC or NORM packet, the receiver MUST also check that the
packet is a pure data packet that does not contain any signaling
information of importance for the session. For instance, an ALC
packet containing a "A" flag ("Close Session") MUST NOT be discarded
before having been authenticated and processed normally. Otherwise,
the receiver can safely discard the incoming packet for instance just
after step 1 of Section 4.3. This optimization can dramatically
reduce the processing overhead, by avoiding many useless
authentication checks.
4.4. Flushing the Non Authenticated Packets of a Previous Key Chain
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:
o he has just switched to a chain of index j+2 (inclusive) or
higher;
o the sender has sent a commitment to the new key chain of index j+2
(Section 3.1.2.3). 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.
Roca, et al. Expires April 25, 2009 [Page 46]
Internet-Draft TESLA in ALC and NORM October 2008
If one of the above two tests succeeds, the sender can discard all
the awaiting packets since there is no way to authenticate them.
Roca, et al. Expires April 25, 2009 [Page 47]
Internet-Draft TESLA in ALC and NORM October 2008
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
this document details the EXT_AUTH==1 header extension defined in
[RMT-BB-LCT].
Editor's note: All authentication schemes using the EXT_AUTH
header extension MUST reserve the same 4 bit "ASID" field after
the HET/HEL fields. This way, several authentication schemes can
be used in the same ALC or NORM session, even on the same
communication path.
Several fields are added in addition to the HET (Header Extension
Type) and HEL (Header Extension Length) fields (Figure 14).
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET (=1) | HEL | ASID | Type | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
~ ~
| Content |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: Format of the TESLA EXT_AUTH header extension.
The fields of the TESLA EXT_AUTH header extension are:
"ASID" (Authentication Scheme Identifier) field (4 bits):
The "ASID" identifies the source authentication scheme or protocol
in use. The association between the "ASID" value and the actual
authentication scheme is defined out-of-band, at session startup.
"Type" field (4 bits):
The "Type" field identifies the type of TESLA information carried
in this header extension. This specification defines the
following types:
Roca, et al. Expires April 25, 2009 [Page 48]
Internet-Draft TESLA in ALC and NORM October 2008
* 0: bootstrap information, sent by the sender periodically or
after a direct time synchronization request;
* 1: standard authentication tag for the on-going key chain, sent
by the sender along with a packet;
* 2: authentication tag without key disclosure, sent by the
sender along with a packet;
* 3: authentication tag with a new key chain commitment, sent by
the sender when approaching the end of a key chain;
* 4: authentication tag with a last key of old chain disclosure,
sent by the sender some time after moving to a new key chain;
* 5: 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;
* 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;
* 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;
* 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;
* 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;
* 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;
"Content" field (variable length):
Roca, et al. Expires April 25, 2009 [Page 49]
Internet-Draft TESLA in ALC and NORM October 2008
This is the TESLA information carried in the header extension,
whose type is given by the "Type" field.
5.2. Use of Authentication Header Extensions
Each packet sent by the session's sender MUST contain exactly one
TESLA EXT_AUTH header extension.
All receivers MUST recognize EXT_AUTH but MAY not be able to parse
its content, for instance because they do not support TESLA. In that
case these receivers MUST ignore the TESLA EXT_AUTH extensions. In
case of NORM, the packets sent by receivers MAY contain a direct
synchronization request but MUST NOT contain any of the other five
TESLA EXT_AUTH header extensions.
5.2.1. EXT_AUTH Header Extension of Type Bootstrap Information
The "bootstrap information" TESLA EXT_AUTH (Type==0) MUST be sent in
a stand-alone control packet, rather than in a packet containing
application data. The reason for that is the large size of this
bootstrap information. By using stand-alone packets, the maximum
payload size of data packets is only affected by the (mandatory)
authentication information header extension.
With ALC, the "bootstrap information" TESLA EXT_AUTH MUST be sent in
a control packet, i.e., containing no encoding symbol.
With NORM, the "bootstrap information" TESLA EXT_AUTH MUST be sent in
a NORM_CMD(APPLICATION) message.
Roca, et al. Expires April 25, 2009 [Page 50]
Internet-Draft TESLA in ALC and NORM October 2008
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
| HET (=1) | HEL (=46) | ASID | 0 | 0 | 0 |0|1|0| ^
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| d | 1 | 1 | 1 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| 1 | 1 | 128 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| 0 (reserved) | T_int | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | |
+ T_0 (NTP timestamp format) + | 5
| | | 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| N (Key Chain Length) | | b
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | y
| Current Interval Index i | | t
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | e
| | | s
+ + |
| | |
+ Current Key Chain Commitment + |
| (20 bytes) | |
+ + |
| | |
+ + |
| | v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
| | ^ 1
+ + | 2
| | | 8
. . |
. Signature . | b
. (128 bytes) . | y
| | | t
+ + | e
| | v s
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
| Group MAC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: Example: Format of the bootstrap information message (Type
0), using SHA-1/1024 bit signatures, the default HMAC-SHA-1 and a
Group MAC.
For instance Figure 15 shows the bootstrap information message when
using the HMAC-SHA-1 transform for the PRF, MAC, and Group MAC
Roca, et al. Expires April 25, 2009 [Page 51]
Internet-Draft TESLA in ALC and NORM October 2008
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).
5.2.2. EXT_AUTH Header Extension of Type Authentication Tag
The eight "authentication tag" TESLA EXT_AUTH (Type 1, 2, 3, 4, 5, 6,
7 and 8) MUST be attached to the ALC or NORM packet (data or control
packet) that they protect.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET (=1) | HEL (=9) | ASID | 5 | i_LSB |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Disclosed Key K_{i-d} +
| (20 bytes) |
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ MAC(K'_i, M) +
| (10 bytes) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | i_NSB |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: Example: Format of the compact authentication tag (Type
5), using the default HMAC-SHA-1.
Roca, et al. Expires April 25, 2009 [Page 52]
Internet-Draft TESLA in ALC and NORM October 2008
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET (=1) | HEL (=4) | ASID | 6 | i_LSB |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ MAC(K'_i, M) +
| (10 bytes) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | i_NSB |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: Example: Format of the compact authentication tag without
key disclosure (Type 6), using the default HMAC-SHA-1.
For instance, Figure 16 and Figure 17 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 Group MAC feature is not
used.
5.2.3. EXT_AUTH Header Extension of Type Direct Time Synchronization
Request
With NORM, the "direct time synchronization request" TESLA EXT_AUTH
(Type==7) MUST be sent by a receiver in a NORM_CMD(APPLICATION) NORM
packet.
With ALC, the "direct time synchronization request" TESLA EXT_AUTH
cannot be included in an ALC packet, since ALC is restricted to
unidirectional transmissions, from the session's sender to the
receivers. An external mechanism must be used with ALC for carrying
direct time synchronization requests to the session's sender.
In case of direct time synchronization, it is RECOMMENDED that the
receivers spread the transmission of direct time synchronization
requests over the time (Section 2.3.1).
5.2.4. EXT_AUTH Header Extension of Type Direct Time Synchronization
Response
With NORM, the "direct time synchronization response" TESLA EXT_AUTH
(Type==8) MUST be sent by the sender in a NORM_CMD(APPLICATION)
message.
With ALC, the "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
Roca, et al. Expires April 25, 2009 [Page 53]
Internet-Draft TESLA in ALC and NORM October 2008
time synchronization request.
Roca, et al. Expires April 25, 2009 [Page 54]
Internet-Draft TESLA in ALC and NORM October 2008
6. Security Considerations
[RFC4082] discusses the security of TESLA in general. These
considerations apply to the present specification, namely:
o great care must be taken to the timing aspects. In particular the
D_t parameter is critical and must be correctly initialized;
o if the sender realizes that the key disclosure schedule are not
appropriate, then the current session MUST be closed and a new one
created. Indeed Section 3.1.3 requires that these parameters be
fixed during the whole session.
o 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.
The current specification discusses additional aspects with more
details.
6.1. Dealing With DoS Attacks
TESLA introduces new opportunities for an attacker to mount DoS
attacks. For instance an attacker can try to saturate the processing
capabilities of the receiver (faked packets are easy to create but
checking them requires to compute a MAC over the packet or sometimes
check a digital signature as with the bootstrap and direct time
synchronization response messages). An attacker can also try to
saturate the receiver's memory (since authentication is delayed and
non-authenticated packets will accumulate), or to make the receiver
believe that a congestion has happened (since congestion control MUST
be performed before authenticating incoming packets, Section 4.3).
In order to mitigate these attacks, it is RECOMMENDED to use the
Group MAC scheme (Section 3.3.3). No mitigation is possible if a
group member acts as an attacker with Group MAC.
Generally, it is RECOMMENDED that the amount of memory used to store
incoming packets waiting to be authenticated be limited to a
reasonable value.
Roca, et al. Expires April 25, 2009 [Page 55]
Internet-Draft TESLA in ALC and NORM October 2008
6.2. Dealing With Replay Attacks
Replay attacks, whereby an attacker stores a valid message and
replays it later on, can have significant impacts, depending on the
message type. Two levels of impacts must be distinguished:
o within the TESLA protocol, and
o within the ALC or NORM protocol.
6.2.1. Impacts of Replay Attacks on TESLA
Replay attacks can impact the TESLA component itself. We review here
the potential impacts of such an attack depending on the TESLA
message type:
o 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
(Section 4.2.1), which voids replay attacks, unless he missed all
the commitments to a new key chain (e.g., after a long
disconnection) (Section 3.2.1).
o direct time synchronization request: If the Group MAC scheme is
used, an attacker that is not a member of the group can replay a
packet and oblige the sender to respond, which requires to
digitally sign the response, a time-consuming process. If the
Group MAC scheme is not used, an attacker can anyway easily forge
a request. In both cases, the attack will not compromise the
TESLA component, but might create a DoS. If this is a concern, it
is RECOMMENDED, when the Group MAC scheme is used, that the sender
verify the "t_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 Group MAC scheme is not
used, this attack can be mitigated by limiting the number of
requests per second that will be processed.
o direct time synchronization response: Upon receiving a response, a
receiver who has no pending request MUST immediately drop the
packet. If this receiver has previously issued a request, he
first checks the 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.
Roca, et al. Expires April 25, 2009 [Page 56]
Internet-Draft TESLA in ALC and NORM October 2008
o 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).
To conclude, TESLA itself is robust in front of replay attacks.
6.2.2. Impacts of Replay Attacks on NORM
We review here the potential impacts of a replay attack on the NORM
component. Note that we do not consider here the protocols that
could be used along with NORM, for instance the congestion control
protocols.
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 [RMT-PI-NORM] 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. In both cases, checking this sequence field
SHOULD be done before TESLA processing of the packet: if the sequence
field has not been corrupted, the replay attack will immediately be
identified, and otherwise the packet will fail the TESLA
authentication test. This analysis shows that NORM itself is robust
in front of replay attacks within the same session.
Now let us consider replay attacks across several NORM sessions.
Since the key chain used in each session MUST differ, a packet
replayed in a subsequent session will be identified as unauthentic.
Therefore NORM is robust in front of replay attacks across different
sessions.
6.2.3. Impacts of Replay Attacks on ALC
We review here the potential impacts of a replay attack on the ALC
component. Note that we do not consider here the protocols that
could be used along with ALC, for instance the layered or wave based
congestion control protocols.
First, let us consider replay attacks within a given ALC session:
o 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
Roca, et al. Expires April 25, 2009 [Page 57]
Internet-Draft TESLA in ALC and NORM October 2008
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.
o 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:
* At the end of the session, a "close session" (A flag) packet is
sent. Replaying this packet has no impact since the receivers
already left.
* Similarly, replaying a packet containing a "close object" (B
flag) has no impact since this object is probably already
marked as closed by the receiver.
This analysis shows that ALC itself is robust in front of replay
attacks within the same session.
Now let us consider replay attacks across several ALC sessions.
Since the key chain used in each session MUST differ, a packet
replayed in a subsequent session will be identified as unauthentic.
Therefore ALC is robust in front of replay attacks across different
sessions.
Roca, et al. Expires April 25, 2009 [Page 58]
Internet-Draft TESLA in ALC and NORM October 2008
7. IANA Considerations
This document requires a IANA registration for the following
attributes:
Cryptographic Pseudo-Random Function, TESLA-PRF: All implementations
MUST support HMAC-SHA-256 (default).
+------------------------+-------+---------------------+
| PRF name | Value | n_p and n_f |
+------------------------+-------+---------------------+
| INVALID | 0 | N/A |
| | | |
| HMAC-SHA-1 | 1 | 160 bits (20 bytes) |
| | | |
| HMAC-SHA-224 | 2 | 224 bits (28 bytes) |
| | | |
| HMAC-SHA-256 (default) | 3 | 256 bits (32 bytes) |
| | | |
| HMAC-SHA-384 | 4 | 384 bits (48 bytes) |
| | | |
| HMAC-SHA-512 | 5 | 512 bits (64 bytes) |
+------------------------+-------+---------------------+
Cryptographic Message Authentication Code (MAC): All implementations
MUST support HMAC-SHA-256 (default). These MAC schemes are used both
for the computing of regular MAC and the Group MAC (if applicable).
+----------------------+-------+------------------+-----------------+
| MAC name | Value | n_m (regular | n_w (Group MAC) |
| | | MAC) | |
+----------------------+-------+------------------+-----------------+
| INVALID | 0 | N/A | N/A |
| | | | |
| HMAC-SHA-1 | 1 | 80 bits (10 | 32 bits (4 |
| | | bytes) | bytes) |
| | | | |
| HMAC-SHA-224 | 2 | 112 bits (14 | 32 bits (4 |
| | | bytes) | bytes) |
| | | | |
| HMAC-SHA-256 | 3 | 128 bits (16 | 32 bits (4 |
| (default) | | bytes) | bytes) |
| | | | |
| HMAC-SHA-384 | 4 | 192 bits (24 | 32 bits (4 |
| | | bytes) | bytes) |
| | | | |
Roca, et al. Expires April 25, 2009 [Page 59]
Internet-Draft TESLA in ALC and NORM October 2008
| HMAC-SHA-512 | 5 | 256 bits (32 | 32 bits (4 |
| | | bytes) | bytes) |
+----------------------+-------+------------------+-----------------+
Signature Encoding Algorithm: All implementations MUST support
RSASSA-PKCS1-v1_5 (default).
+-----------------------------+-------+
| Signature Algorithm Name | Value |
+-----------------------------+-------+
| INVALID | 0 |
| | |
| RSASSA-PKCS1-v1_5 (default) | 1 |
| | |
| RSASSA-PSS | 2 |
+-----------------------------+-------+
Signature Cryptographic Function: All implementations MUST support
SHA-256 (default).
+-----------------------------+-------+
| Cryptographic Function Name | Value |
+-----------------------------+-------+
| INVALID | 0 |
| | |
| SHA-1 | 1 |
| | |
| SHA-224 | 2 |
| | |
| SHA-256 (default) | 3 |
| | |
| SHA-384 | 4 |
| | |
| SHA-512 | 5 |
+-----------------------------+-------+
Roca, et al. Expires April 25, 2009 [Page 60]
Internet-Draft TESLA in ALC and NORM October 2008
8. Acknowledgments
The authors are grateful to Brian Weis, Ramu Panayappan, Ran Canetti,
David L. Mills and Lionel Giraud for their valuable comments while
preparing this document. The authors are also grateful to Brian Weis
for the digital signature details.
Roca, et al. Expires April 25, 2009 [Page 61]
Internet-Draft TESLA in ALC and NORM October 2008
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997.
[RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B.
Briscoe, "Timed Efficient Stream Loss-Tolerant
Authentication (TESLA): Multicast Source Authentication
Transform Introduction", RFC 4082, June 2005.
[RMT-BB-LCT]
Luby, M., Watson, M., and L. Vicisano, "Layered Coding
Transport (LCT) Building Block",
draft-ietf-rmt-bb-lct-revised-07.txt (work in progress),
July 2008.
[RMT-PI-ALC]
Luby, M., Watson, M., and L. Vicisano, "Asynchronous
Layered Coding (ALC) Protocol Instantiation",
draft-ietf-rmt-pi-alc-revised-05.txt (work in progress),
November 2007.
[RMT-PI-NORM]
Adamson, B., Bormann, C., Handley, M., and J. Macker,
"Negative-acknowledgment (NACK)-Oriented Reliable
Multicast (NORM) Protocol",
draft-ietf-rmt-pi-norm-revised-06.txt (work in progress),
January 2008.
9.2. Informative References
[NTP-NTPv4]
Burbank, J., Kasch, W., Martin, J., and D. Mills, "The
Network Time Protocol Version 4 Protocol Specification",
draft-ietf-ntp-ntpv4-proto-09.txt (work in progress),
February 2008.
[Perrig04]
Perrig, A. and J. Tygar, "Secure Broadcast Communication
in Wired and Wireless Networks", Kluwer Academic
Publishers ISBN 0-7923-7650-1, 2004.
[RFC1305] Mills, D., "Network Time Protocol (Version 3)
Specification, Implementation", RFC 1305, March 1992.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Roca, et al. Expires April 25, 2009 [Page 62]
Internet-Draft TESLA in ALC and NORM October 2008
Hashing for Message Authentication", RFC 2104,
February 1997.
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1", RFC 3447, February 2003.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
[RFC4330] Mills, D., "Simple Network Time Protocol (SNTP) Version 4
for IPv4, IPv6 and OSI", RFC 4330, January 2006.
[RFC4359] Weis, B., "The Use of RSA/SHA-1 Signatures within
Encapsulating Security Payload (ESP) and Authentication
Header (AH)", RFC 4359, January 2006.
[RFC4383] Baugher, M. and E. Carrara, "The Use of Timed Efficient
Stream Loss-Tolerant Authentication (TESLA) in the Secure
Real-time Transport Protocol (SRTP)", RFC 4383,
February 2006.
[RFC4442] Fries, S. and H. Tschofenig, "Bootstrapping Timed
Efficient Stream Loss-Tolerant Authentication (TESLA)",
RFC 4442, March 2006.
[RMT-FLUTE]
Paila, T., Walsh, R., Luby, M., Lehtonen, R., and V. Roca,
"FLUTE - File Delivery over Unidirectional Transport",
draft-ietf-rmt-flute-revised-05.txt (work in progress),
October 2007.
Roca, et al. Expires April 25, 2009 [Page 63]
Internet-Draft TESLA in ALC and NORM October 2008
Authors' Addresses
Vincent Roca
INRIA
655, av. de l'Europe
Inovallee; Montbonnot
ST ISMIER cedex 38334
France
Email: vincent.roca@inria.fr
URI: http://planete.inrialpes.fr/~roca/
Aurelien Francillon
INRIA
655, av. de l'Europe
Inovallee; Montbonnot
ST ISMIER cedex 38334
France
Email: aurelien.francillon@inria.fr
URI: http://planete.inrialpes.fr/~francill/
Sebastien Faurite
INRIA
655, av. de l'Europe
Inovallee; Montbonnot
ST ISMIER cedex 38334
France
Email: faurite@lcpc.fr
Roca, et al. Expires April 25, 2009 [Page 64]
Internet-Draft TESLA in ALC and NORM October 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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.
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, THE IETF TRUST 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.
Intellectual Property
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Roca, et al. Expires April 25, 2009 [Page 65]
| PAFTECH AB 2003-2026 | 2026-04-23 11:36:56 |