[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-faurite-rmt-tesla-for-alc-norm) 00 01 02 03 04 05 06 07 08 09 10 RFC 5776

MSEC                                                             V. Roca
Internet-Draft                                             A. Francillon
Intended status: Experimental                                 S. Faurite
Expires: August 21, 2008                                           INRIA
                                                       February 18, 2008


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

Status of this Memo

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

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

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

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

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

   This Internet-Draft will expire on August 21, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008).













Roca, et al.             Expires August 21, 2008                [Page 1]

Internet-Draft            TESLA in ALC and NORM            February 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.  Adding authentication/integrity
   verification to the packets sent by receivers, if any, is out of the
   scope of this document.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Conventions Used in this Document  . . . . . . . . . . . .  5
     1.2.  Terminology and Notations  . . . . . . . . . . . . . . . .  5
       1.2.1.  Notations and Definitions Related to Cryptographic
               Functions  . . . . . . . . . . . . . . . . . . . . . .  5
       1.2.2.  Notations and Definitions Related to Time  . . . . . .  6
   2.  Using TESLA with ALC and NORM: General Operations  . . . . . .  8
     2.1.  ALC and NORM Specificities that Impact TESLA . . . . . . .  8
     2.2.  Bootstrapping TESLA  . . . . . . . . . . . . . . . . . . .  9
       2.2.1.  Bootstrapping TESLA with an Out-Of-Band Mechanism  . .  9
       2.2.2.  Bootstrapping TESLA with an In-Band Mechanism  . . . .  9
     2.3.  Setting Up a Secure Time Synchronization . . . . . . . . . 10
       2.3.1.  Direct Time Synchronization  . . . . . . . . . . . . . 10
       2.3.2.  Indirect Time Synchronization  . . . . . . . . . . . . 11
     2.4.  Determining the Delay Bounds . . . . . . . . . . . . . . . 12
       2.4.1.  Delay Bound Calculation in Direct Time
               Synchronization Mode . . . . . . . . . . . . . . . . . 12
       2.4.2.  Delay Bound Calculation in Indirect time
               Synchronization Mode . . . . . . . . . . . . . . . . . 12
   3.  Sender Operations  . . . . . . . . . . . . . . . . . . . . . . 14
     3.1.  TESLA Parameters . . . . . . . . . . . . . . . . . . . . . 14
       3.1.1.  Time Intervals . . . . . . . . . . . . . . . . . . . . 14
       3.1.2.  Key Chains . . . . . . . . . . . . . . . . . . . . . . 14
       3.1.3.  Time Interval Schedule . . . . . . . . . . . . . . . . 17
       3.1.4.  Timing Parameters  . . . . . . . . . . . . . . . . . . 18
     3.2.  TESLA Messages and Authentication Tags . . . . . . . . . . 18
       3.2.1.  Bootstrap Information  . . . . . . . . . . . . . . . . 18
       3.2.2.  Direct Time Synchronization Response . . . . . . . . . 19
       3.2.3.  Authentication Tag . . . . . . . . . . . . . . . . . . 20
       3.2.4.  Weak Group MAC Tag . . . . . . . . . . . . . . . . . . 20
       3.2.5.  Use of Digital Signatures  . . . . . . . . . . . . . . 21
     3.3.  TESLA Messages and Authentication Tag Format . . . . . . . 22
       3.3.1.  Bootstrap Information Format . . . . . . . . . . . . . 22
       3.3.2.  Format of a Direct Time Synchronization Response . . . 27
       3.3.3.  Format of a Standard Authentication Tag  . . . . . . . 29



Roca, et al.             Expires August 21, 2008                [Page 2]

Internet-Draft            TESLA in ALC and NORM            February 2008


       3.3.4.  Format of a Standard Authentication Tag Without
               Key Disclosure . . . . . . . . . . . . . . . . . . . . 30
       3.3.5.  Format of an Authentication Tag with a New Key
               Chain Commitment . . . . . . . . . . . . . . . . . . . 31
       3.3.6.  Format of an Authentication Tag with a Last Key of
               Old Chain Disclosure . . . . . . . . . . . . . . . . . 32
       3.3.7.  Format of the Compact Authentication Tags  . . . . . . 32
   4.  Receiver Operations  . . . . . . . . . . . . . . . . . . . . . 36
     4.1.  Initialization of a Receiver . . . . . . . . . . . . . . . 36
       4.1.1.  Processing the Bootstrap Information Message . . . . . 36
       4.1.2.  Time Synchronization . . . . . . . . . . . . . . . . . 36
     4.2.  Authentication of Received Packets . . . . . . . . . . . . 38
     4.3.  Flushing the Non Authenticated Packets of a Previous
           Key Chain  . . . . . . . . . . . . . . . . . . . . . . . . 41
   5.  Integration in the ALC and NORM Protocols  . . . . . . . . . . 42
     5.1.  Authentication Header Extension Format . . . . . . . . . . 42
     5.2.  Use of Authentication Header Extensions  . . . . . . . . . 44
       5.2.1.  EXT_AUTH Header Extension of Type Bootstrap
               Information  . . . . . . . . . . . . . . . . . . . . . 44
       5.2.2.  EXT_AUTH Header Extension of Type Authentication
               Tag  . . . . . . . . . . . . . . . . . . . . . . . . . 46
       5.2.3.  EXT_AUTH Header Extension of Type Direct Time
               Synchronization Request  . . . . . . . . . . . . . . . 47
       5.2.4.  EXT_AUTH Header Extension of Type Direct Time
               Synchronization Response . . . . . . . . . . . . . . . 47
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 49
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 51
     7.1.  Dealing With DoS Attacks . . . . . . . . . . . . . . . . . 51
     7.2.  Dealing With Replay Attacks  . . . . . . . . . . . . . . . 52
       7.2.1.  Impacts of Replay Attacks on TESLA . . . . . . . . . . 52
       7.2.2.  Impacts of Replay Attacks on NORM  . . . . . . . . . . 53
       7.2.3.  Impacts of Replay Attacks on ALC . . . . . . . . . . . 53
   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 55
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 56
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 56
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 56
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 58
   Intellectual Property and Copyright Statements . . . . . . . . . . 59













Roca, et al.             Expires August 21, 2008                [Page 3]

Internet-Draft            TESLA in ALC and NORM            February 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 [draft-ietf-rmt-pi-alc-revised] and NORM
   [draft-ietf-rmt-pi-norm-revised], two Content Delivery Protocols
   (CDP) designed to transfer reliably objects (e.g., files) between a
   session's sender and several receivers.  The NORM protocol is based
   on bidirectional transmissions.  Each receiver acknowledges data
   received or, in case of packet erasures, asks for retransmissions.
   On the opposite, the ALC protocol is based on purely unidirectional
   transmissions.  Reliability is achieved by means of the cyclic
   transmission of the content within a carousel and/or by the use of
   proactive Forward Error Correction codes (FEC).  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, in
   the latter case a simple solution to this problem exists: the sender
   and the receiver can share a secret key to compute a Message
   Authentication Code (MAC) of all messages exchanged.  This is no
   longer feasible in case of multicast and broadcast communications
   since sharing a group key between the sender and all receivers
   implies that any group member can impersonate the sender and send
   forged messages to other receivers.

   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 [draft-ietf-rmt-flute-revised].



Roca, et al.             Expires August 21, 2008                [Page 4]

Internet-Draft            TESLA in ALC and NORM            February 2008


   This specification only considers the authentication/integrity of the
   packets generated by the session's sender.  This specification does
   not consider the packets that may be sent by receivers, for instance
   NORM's feedback packets.  Adding authentication/integrity to the
   packets sent by receivers is outside the scope of this document.

   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 [draft-ietf-rmt-pi-alc-revised],
   [draft-ietf-rmt-bb-lct-revised] and [draft-ietf-rmt-pi-norm-revised]
   respectively.

1.1.  Conventions Used in this Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

1.2.  Terminology and Notations

   The following notations and definitions are used throughout this
   document.

1.2.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;

   o  F' is the one-way function used to derive the HMAC keys;

   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 of the truncated output of the MAC [RFC2104].
      Only the n_m left-most bits (most significant bits) of the MAC
      output are kept;




Roca, et al.             Expires August 21, 2008                [Page 5]

Internet-Draft            TESLA in ALC and NORM            February 2008


   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 intervals during which the last key
      of the old key chain SHOULD be sent, after switching to a new key
      chain and after waiting for the disclosure delay d.  These extra
      transmissions take place after the interval during which the last
      key is normally disclosed.  The n_tx_lastkey value is either 0 (no
      extra disclosure) or larger.  This parameter is sender specific
      and is not communicated to the receiver;

   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, before starting the session.  The mechanism by
      which this group key is shared by the group members is out of the
      scope of this document;

   o  n_w is the length of the truncated output of the MAC of the
      optional weak group authentication scheme: only the n_w most
      significant bits of the MAC output are kept. n_w is typically a
      small value (e.g., 32 bits), multiple of 32 bits;

1.2.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 might take place in long
      sessions.

   o  t_s is the sender local time value at some absolute time;

   o  t_r is the receiver local time value at the same absolute time;

   o  T_0, the start time corresponding to the beginning of the session
      (NTP timestamp);





Roca, et al.             Expires August 21, 2008                [Page 6]

Internet-Draft            TESLA in ALC and NORM            February 2008


   o  T_int, the interval duration (in milliseconds);

   o  d, the key disclosure delay (in number of intervals);

   o  D_t, the upper bound of the lag of the receiver's clock with
      respect to the clock of the sender;

   o  S_sr, an estimated bound of the clock drift between the sender and
      a receiver throughout the duration of the session;

   o  D^O_t, the upper bound of the lag of the sender's clock with
      respect to the time reference in indirect time synchronization
      mode;

   o  D^R_t, the upper bound of the lag of the receiver's clock with
      respect to the time reference in indirect time synchronization
      mode;

   o  D_err, an upper bound of the time error between all the time
      references, in indirect time synchronization mode;































Roca, et al.             Expires August 21, 2008                [Page 7]

Internet-Draft            TESLA in ALC and NORM            February 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 DVB-H/SH systems;

   o  ALC defines an on-demand content delivery model
      [draft-ietf-rmt-pi-alc-revised] where receivers can arrive at any
      time, at their own discretion, download the content and leave the
      session.  Other models (e.g., push or streaming) are also defined;

   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 August 21, 2008                [Page 8]

Internet-Draft            TESLA in ALC and NORM            February 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.3.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, the
   sender or a group controller:

   o  MUST either communicate his public key or a certificate (which
      also means that a PKI has been setup), for each receiver to be
      able to verify the signature of the bootstrap message and direct
      time synchronization response messages (when applicable).

   o  when time synchronization is performed with (S)NTP, MUST
      communicate the list of valid (S)NTP servers, for all group



Roca, et al.             Expires August 21, 2008                [Page 9]

Internet-Draft            TESLA in ALC and NORM            February 2008


      members (including the server) to synchronize themselves on the
      same (S)NTP servers.

   o  when the Weak Group MAC feature is used, MUST communicate the K_g
      group key to the receivers.  This key might be periodically
      refreshed.

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

2.3.  Setting Up a Secure Time Synchronization

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

   o  direct time synchronization, and

   o  indirect time synchronization.

2.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.1.2.1).  The
   sender then directly answers to each request with a "Direct Time
   Synchronization Response" (Section 3.3.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,

   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
   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



Roca, et al.             Expires August 21, 2008               [Page 10]

Internet-Draft            TESLA in ALC and NORM            February 2008


   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) [draft-ietf-ntp-ntpv4-proto] hierarchy of servers.  The
      Autokey security protocol of NTPv4 MUST be used in order to
      authenticate each NTP message individually;

   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.  This time
      reference is in general trusted, yet 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
   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



Roca, et al.             Expires August 21, 2008               [Page 11]

Internet-Draft            TESLA in ALC and NORM            February 2008


   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.1.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.3.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.

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.





Roca, et al.             Expires August 21, 2008               [Page 12]

Internet-Draft            TESLA in ALC and NORM            February 2008


2.4.2.1.  Single time reference

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

   1.  The sender calculates D^O_t, the upper bound of the lag of the
       sender's clock with respect to the time reference.  This D^O_t
       value is then be communicated to the receivers (Section 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's now assume that there are several time references (e.g.,
   several (S)NTP servers).  The sender and receivers use the direct
   time synchronization scheme to synchronize with the various time
   references.  It results in D^O_t and D^R_t.  Let D_err be an upper
   bound of the time error between all the time references.  Then, the
   overall value of D_t within receiver R is set to the sum: D_t = D^O_t
   + D^R_t + D_err.

   In some cases, the D_t value is part of the time synchronization
   scheme specifications.  For instance NTPv3 [RFC1305] 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 August 21, 2008               [Page 13]

Internet-Draft            TESLA in ALC and NORM            February 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 in sequence.  Key
   numbering starts at 0 and is incremented consecutively, following the
   time interval numbering: K_0, K_1 ..  K_N.

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

   The key chain has a finite length, N, which corresponds to a maximum
   duration of (N + 1) * T_int.  The content delivery session has a
   duration T_delivery, which may either be known in advance, or not.  A
   first solution consists in having a single key chain of an
   appropriate length, so that the content delivery session finishes
   before the end of the key chain, i.e., T_delivery <= (N + 1) * T_int.
   But the longer the key chain, the higher the memory and computation
   required to cope with it.  Another solution consists in switching to
   a new key chain, of the same length, when necessary (see Figure 1)
   [Perrig04].

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



Roca, et al.             Expires August 21, 2008               [Page 14]

Internet-Draft            TESLA in ALC and NORM            February 2008


   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's say that the old key chain stops at K_N and
   the new key chain starts at K_{N+1} (i.e., F(K_{N+1}) and K_N are two
   different keys).  Then the sender includes the commitment F(K_{N+1})
   to the new key chain to packets authenticated with the old key chain
   (see Section 3.3.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.3.6).  This SHOULD be done during
   n_tx_lastkey additional time intervals after the end of the time
   interval where K_N is disclosed.  Since several packets 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



Roca, et al.             Expires August 21, 2008               [Page 15]

Internet-Draft            TESLA in ALC and NORM            February 2008


   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).

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.3.4
   or its compact flavor.  The following key chains, if any, are not



Roca, et al.             Expires August 21, 2008               [Page 16]

Internet-Draft            TESLA in ALC and NORM            February 2008


   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 packet for some time, for
   various reasons.  It can be the end of the session and all packets
   have already been sent, or the use-case may consist in a succession
   of busy periods (when fresh objects are available) followed by silent
   periods.  In both cases, this is an issue since the authentication of
   the packets sent during the last d intervals requires that the
   associated keys be disclosed, which will take place during d
   additional time intervals.

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

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 *
   d product that is too short prevents many receivers from verifying
   packets.  A N * T_int product that is too small will cause the sender
   to switch too often to new key chains.  A N that is too long with
   respect to the expected session duration, if this latter is known,
   will require the sender to compute too many keys without using them
   all.  [RFC4082] sections 3.2 and 3.6 give general guidelines for
   initializing these parameters.



Roca, et al.             Expires August 21, 2008               [Page 17]

Internet-Draft            TESLA in ALC and NORM            February 2008


   The T_0, T_int, d and N parameters MUST NOT be changed during the
   lifetime of the session.  This restriction is meant to prevent
   introducing vulnerabilities (e.g., if a sender was authorized to
   change the key disclosure schedule, a receiver that did not receive
   the change notification would still believe in the old key disclosure
   schedule, thereby creating vulnerabilities [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 Messages and Authentication Tags

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

   o  The bootstrap information.  This information can be either sent
      out-of-band or in-band.  In the latter case, a digitally signed
      packet contains all the information required to bootstrap TESLA at
      a receiver;

   o  The time synchronization response, which enables a receiver to
      finish a direct time synchronization;

   o  The authentication tag, which is sent in all data packets and
      contains the MAC of the packet;

   o  Additionally, an optional weak group authentication tag can be
      added to packets to mitigate attacks coming from outside of the
      group.

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.  Choosing between an in-band and out-of-band scheme is
   left to the implementer, depending on the target use-case.  In this
   section we only consider the in-band scheme.

   The TESLA bootstrap information message MUST be digitally signed
   (Section 3.2.5).  The goal is to enable a receiver to check the



Roca, et al.             Expires August 21, 2008               [Page 18]

Internet-Draft            TESLA in ALC and NORM            February 2008


   packet source and packet integrity.  Then, the bootstrap information
   can be:

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

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

   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 receivers lose all
      the commitments to the new key chain.

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

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.2.5).  The receiver MUST also be able the associate this
   response and his request, which is the reason why t_r is included in
   the message.




Roca, et al.             Expires August 21, 2008               [Page 19]

Internet-Draft            TESLA in ALC and NORM            February 2008


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

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

3.2.3.  Authentication Tag

   Every packet MUST have an authentication tag containing:

   o  the interval index, which is also the index of the key used for
      computing the MAC of this packet: i.  This interval index is
      optional when ;

   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;

   o  and the MAC of the message: MAC(K'_i, M), where K'_i=F'(K_i);

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

3.2.4.  Weak Group MAC Tag

   An optional Weak Group MAC can be used to mitigate DoS attacks coming
   from attackers that are not group member [RFC4082].  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 packets identified as unauthentic,
      without having to wait for the disclosure delay, d;

   o  a sender can immediately drop faked direct time synchronization
      requests, and in particular avoid to compute the digital
      signature, a computation intensive task;




Roca, et al.             Expires August 21, 2008               [Page 20]

Internet-Draft            TESLA in ALC and NORM            February 2008


   o  a receiver can immediately drop faked direct time synchronization
      response message, without having to verify the digital signature,
      a computation intensive task;

   More specifically, before sending a message, the sender computes the
   group MAC MAC(K_g, M), which includes the ALC or NORM header (with
   the various header extensions), plus the payload when applicable.
   During this computation, the Weak Group MAC field MUST be set to 0.
   However the digital signature and MAC fields, when present, MUST have
   been calculated and are included in the Weak Group MAC calculation
   itself.  Then the sender truncates the MAC output to keep the n_w
   most significant bits and stores the result in the TESLA
   Authentication header.  Upon receiving this packet, the receiver
   recomputes the group MAC and compares it to the value carried in the
   packet.  If the check fails, the packet MUST be immediately dropped.

   This scheme features a few limits:

   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 packet be
      successfully forged is one in 2^32).  Since the weak group MAC
      check is only a pre-check that will be followed by the standard
      TESLA authentication check, this is not considered to be an issue.

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

   Note that the Weak Group MAC function can be different from the TESLA
   MAC function (e.g., it can use a weaker but faster MAC function).
   Note also that the mechanism by which the group key, K_g, is
   communicated to all group members, and perhaps periodically updated,
   is out of the scope of this document.

3.2.5.  Use of Digital Signatures

   The Bootstrap Information message (with the in-band bootstrap scheme)
   and Direct Time Synchronization Response message (with the indirect
   time synchronization scheme, either with in-band or out-of-band
   bootstrap) both need to be signed by the sender.  Within these two



Roca, et al.             Expires August 21, 2008               [Page 21]

Internet-Draft            TESLA in ALC and NORM            February 2008


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

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

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

   With RSASSA-PKCS1-v1_5 (default) and RSASSA-PSS signatures
   (Section 6), 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.

3.3.  TESLA Messages and Authentication Tag Format

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

3.3.1.  Bootstrap Information Format

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








Roca, et al.             Expires August 21, 2008               [Page 22]

Internet-Draft            TESLA in ALC and NORM            February 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 |S|W|A|  ^
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  | f
  |       d       |    PRF Type   | MAC Func Type |WG MAC Fun Type|  | i
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  | f
  | Signature Type| CryptoFunType |       Signature Length        |  | i
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  | x
  |            Reserved           |             T_int             |  | e
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  | d
  |                                                               |  |
  +                      T_0 (NTP timestamp)                      +  | l
  |                                                               |  | e
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  | n
  |                      N (Key Chain Length)                     |  | g
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  | t
  |                    Current Interval Index i                   |  v h
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  ---
  |                                                               |
  ~                 Current Key Chain Commitment  +-+-+-+-+-+-+-+-+
  |                                               |   Padding     |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  +                                                               +
  ~                           Signature                           ~
  +                                               +-+-+-+-+-+-+-+-+
  |                                               |    Padding    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |P|                                                             |
  +-+       D^O_t Extension (optional, present if A==1)           +
  |    (NTP timestamp diff, positive if P==1, negative if P==0)   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  ~                   Weak Group MAC (optional)                   ~
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 2: Bootstrap information format.

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

   "Reserved" fields (5 bits):

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

   "S" (Single Key Chain) flag (1 bits):




Roca, et al.             Expires August 21, 2008               [Page 23]

Internet-Draft            TESLA in ALC and NORM            February 2008


      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).

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

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

   "A" flag (1 bit):

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

   "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):

      "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 6).

   "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 6).

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

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

   "Signature Type" field (8 bits):

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

   "Signature Cryptographic Function Type" field (8 bits):



Roca, et al.             Expires August 21, 2008               [Page 24]

Internet-Draft            TESLA in ALC and NORM            February 2008


      The "Signature Cryptographic Function Type" is the reference
      number (Section 6) 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 an NTP timestamp 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):

      "Key Chain Commitment" is the commitment to the current key chain,
      i.e., the key chain corresponding to interval i.  For instance,
      with the first key chain, this commitment is equal to F(K_0), with
      the second key chain, this commitment is equal to F(K_{N+1}),
      etc.).  If need be, this field is padded (with 0) up to a multiple
      of 32 bits.

   "Signature" field (variable size):

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



Roca, et al.             Expires August 21, 2008               [Page 25]

Internet-Draft            TESLA in ALC and NORM            February 2008


      multiple of 32 bits.

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

      The "P" flag is optional.  It is only used in indirect time
      synchronization mode when the A flag is 1.  This flag indicates
      whether the D^O_t NTP timestamp difference is positive (P==1) or
      negative (P==0).

   "D^O_t" field (optional, 63 bits if present):

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

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

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

   Note that the first byte and the following seven 32-bit words are
   mandatory fixed length fields.  The Current Key Chain Commitment and
   Signature fields are mandatory but variable length fields.  The
   remaining D^O_t and Weak Group MAC fields are optional.

   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 August 21, 2008               [Page 26]

Internet-Draft            TESLA in ALC and NORM            February 2008


   +--------------------------+----------------------------------------+
   |         Parameter        |                 Status                 |
   +--------------------------+----------------------------------------+
   |             S            |      static (during whole session)     |
   |                          |                                        |
   |             W            |      static (during whole session)     |
   |                          |                                        |
   |             A            |      static (during whole session)     |
   |                          |                                        |
   |            T_O           |      static (during whole session)     |
   |                          |                                        |
   |           T_int          |      static (during whole session)     |
   |                          |                                        |
   |             d            |      static (during whole session)     |
   |                          |                                        |
   |             N            |      static (during whole session)     |
   |                          |                                        |
   |    D^O_t (if present)    |      static (during whole session)     |
   |                          |                                        |
   |         PRF Type         |      static (during whole session)     |
   |                          |                                        |
   |     MAC Function Type    |      static (during whole session)     |
   |                          |                                        |
   |      Signature Type      |      static (during whole session)     |
   |                          |                                        |
   |     Signature Crypto.    |      static (during whole session)     |
   |       Function Type      |                                        |
   |                          |                                        |
   |     Signature Length     |      static (during whole session)     |
   |                          |                                        |
   |   Weak Group MAC Func.   |      static (during whole session)     |
   |           Type           |                                        |
   |                          |                                        |
   |             i            | dynamic (related to current key chain) |
   |                          |                                        |
   |            K_i           | dynamic (related to current key chain) |
   |                          |                                        |
   |         signature        |        dynamic, packet dependent       |
   |                          |                                        |
   |    Weak Group MAC (if    |        dynamic, packet dependent       |
   |         present)         |                                        |
   +--------------------------+----------------------------------------+

3.3.2.  Format of a Direct Time Synchronization Response







Roca, et al.             Expires August 21, 2008               [Page 27]

Internet-Draft            TESLA in ALC and NORM            February 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   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                     t_s (NTP timestamp)                       +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                     t_r (NTP timestamp)                       +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                                                               +
    ~                           Signature                           ~
    +                                               +-+-+-+-+-+-+-+-+
    |                                               |    Padding    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                   Weak Group MAC (optional)                   ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Figure 3: Format of a Direct Time Synchronization Response

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

   "Reserved" fields (8 bits):

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

   "t_s" (NTP timestamp, 64 bits):

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

   "t_r" (NTP timestamp, 64 bits):

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

   "Signature" field (variable size):

      The "Signature" field is MANDATORY.  The "Signature" field
      contains a digital signature using the type specified either in
      the "Signature Type" field of the bootstrap information message



Roca, et al.             Expires August 21, 2008               [Page 28]

Internet-Draft            TESLA in ALC and NORM            February 2008


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

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

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

3.3.3.  Format of a Standard Authentication Tag


     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                                    +-+-+-+-+-+-+-+-+
                                                    |   Reserved    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                i (Interval Index of K'_i)                     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    ~                    Disclosed Key K_{i-d}                      ~
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    ~                       MAC(K'_i, M)            +-+-+-+-+-+-+-+-+
    |                                               |   Padding     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                   Weak Group MAC (optional)                   ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 4: Format of the authentication tag

   Figure 4 shows the format of the authentication tag:

   "Reserved" field (8 bits):

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

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

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




Roca, et al.             Expires August 21, 2008               [Page 29]

Internet-Draft            TESLA in ALC and NORM            February 2008


   "Disclosed Key" (variable size):

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

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

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

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

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

   Note that because a key cannot be disclosed before the disclosure
   delay, d, the sender MUST NOT use this tag during the first d
   intervals: {0 .. d-1} (inclusive).  Instead the sender MUST use
   Standard or Compact Authentication Tag Without Key Disclosure.

3.3.4.  Format of a Standard Authentication Tag Without Key Disclosure

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














Roca, et al.             Expires August 21, 2008               [Page 30]

Internet-Draft            TESLA in ALC and NORM            February 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     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                   Weak Group MAC (optional)                   ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Figure 5: Format of the authentication tag without key disclosure

3.3.5.  Format of an Authentication Tag with a New Key Chain Commitment

   During the last n_tx_newkcc intervals of the current key chain, the
   sender SHOULD send a commitment to the next key chain.  This is done
   by replacing the disclosed key of the authentication tag with the new
   key chain commitment, F(K_{N+1}) (or F(K_{2N+2}) in case of a switch
   between the second and third key chains, etc.).  Figure 6 shows the
   corresponding format.


     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                                    +-+-+-+-+-+-+-+-+
                                                    |   Reserved    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                i (Interval Index of K'_i)                     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    ~              New Key Commitment F(K_{N+1})                    ~
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    ~                       MAC(K'_i, M)            +-+-+-+-+-+-+-+-+
    |                                               |   Padding     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                   Weak Group MAC (optional)                   ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 6: Format of the authentication tag with a new key chain
                                commitment





Roca, et al.             Expires August 21, 2008               [Page 31]

Internet-Draft            TESLA in ALC and NORM            February 2008


3.3.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 MUST send a commitment to the
   old key chain.  This is done by replacing the disclosed key of the
   authentication tag with the last key of the old chain, K_N (or
   K_{2N+1} in case of a switch between the second and third key chains,
   etc.).  Figure 7 shows the corresponding format.  There is no padding
   between the "K_N" and "MAC(K'_i, M)" fields, and this latter MAY not
   be aligned on 32 bit boundaries, depending on the n_p parameter.


     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                                    +-+-+-+-+-+-+-+-+
                                                    |   Reserved    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                i (Interval Index of K'_i)                     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    ~                  Last Key of Old Chain, K_N                   ~
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    ~                       MAC(K'_i, M)            +-+-+-+-+-+-+-+-+
    |                                               |   Padding     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                   Weak Group MAC (optional)                   ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 7: Format of the authentication tag with an old chain last key
                                disclosure

3.3.7.  Format of the Compact Authentication Tags

   The four compact flavors of the Authentication tags follow.














Roca, et al.             Expires August 21, 2008               [Page 32]

Internet-Draft            TESLA in ALC and NORM            February 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     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    ~                    Disclosed Key K_{i-d}                      ~
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    ~                       MAC(K'_i, M)            +-+-+-+-+-+-+-+-+
    |                                               |  i_NSB (opt)  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                   Weak Group MAC (optional)                   ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 8: Format of the compact authentication tag


     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                                    +-+-+-+-+-+-+-+-+
                                                    |     i_LSB     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    ~                       MAC(K'_i, M)            +-+-+-+-+-+-+-+-+
    |                                               |  i_NSB (opt)  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                   Weak Group MAC (optional)                   ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 9: Format of the compact authentication tag without key
                                disclosure


















Roca, et al.             Expires August 21, 2008               [Page 33]

Internet-Draft            TESLA in ALC and NORM            February 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     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    ~              New Key Commitment F(K_{N+1})                    ~
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    ~                       MAC(K'_i, M)            +-+-+-+-+-+-+-+-+
    |                                               |  i_NSB (opt)  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                   Weak Group MAC (optional)                   ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Figure 10: Format of the compact authentication tag with a new key
                             chain commitment


     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                                    +-+-+-+-+-+-+-+-+
                                                    |     i_LSB     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    ~                  Last Key of Old Chain, K_N                   ~
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    ~                       MAC(K'_i, M)            +-+-+-+-+-+-+-+-+
    |                                               |  i_NSB (opt)  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                   Weak Group MAC (optional)                   ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Figure 11: Format of the compact authentication tag with 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



Roca, et al.             Expires August 21, 2008               [Page 34]

Internet-Draft            TESLA in ALC and NORM            February 2008


   length, depending on the MAC type):

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

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

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




























Roca, et al.             Expires August 21, 2008               [Page 35]

Internet-Draft            TESLA in ALC and NORM            February 2008


4.  Receiver Operations

4.1.  Initialization of a Receiver

   A receiver must be initialized before being able to authenticate the
   source of incoming packets.  This can be done by an out-of-band
   mechanism, out of the scope of the present document, or an in-band
   mechanism (Section 2.2).  Let's 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.1.1.  Processing the Bootstrap Information Message

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

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

4.1.2.  Time Synchronization

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



Roca, et al.             Expires August 21, 2008               [Page 36]

Internet-Draft            TESLA in ALC and NORM            February 2008


4.1.2.1.  Direct Time Synchronization

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

   The direct time synchronization request message format is the
   following:


     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                     t_r (NTP timestamp)                       +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                   Weak Group MAC (optional)                   ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Figure 12: Format of a Direct Time Synchronization Request

   The direct time synchronization request (Figure 12) contains the
   following information:

   "t_r" (NTP timestamp, 64 bits):

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

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

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

   Section 3.3.2 specifies the direct time synchronization response
   message format.

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





Roca, et al.             Expires August 21, 2008               [Page 37]

Internet-Draft            TESLA in ALC and NORM            February 2008


4.1.2.2.  Indirect Time Synchronization

   With the indirect time synchronization method, the sender MAY provide
   out-of-band the URL or IP address of the NTP server(s) he trusts
   along with an OPTIONAL certificate for each NTP server.  When several
   NTP servers are specified, a receiver MUST choose one of them.  This
   document does not specify how the choice is made, but for the sake of
   scalability, the clients SHOULD NOT use the same server if several
   possibilities are offered.  The NTP synchronization between the NTP
   server and the receiver MUST be authenticated, either using the
   certificate provided by the content delivery server, or another
   certificate the client may obtain for this NTP server.

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

   Since the offset between the server and the time reference, D^O_t, is
   indicated in the bootstrap information message (or communicated out-
   of-band), the receiver can now calculate an upper bound of the
   sender's local time (Section 2.4.2).

4.2.  Authentication of Received Packets

   The receiver can now authenticate incoming packets.  To that purpose,
   he MUST follow different steps (see [RFC4082] section 3.5):

   1.  The receiver parses the different packet headers.  If none of the
       eight TESLA authentication tags is present, the receiver MUST
       discard the packet.  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.





Roca, et al.             Expires August 21, 2008               [Page 38]

Internet-Draft            TESLA in ALC and NORM            February 2008


       *  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
       not necessarily authentic).  If the test fails, the packet is
       unsafe, and the receiver MUST discard the packet.

   3.  Weak Group MAC test: The receiver checks the optional Weak Group
       Tag, if present.  To that purpose, the receiver recomputes the
       group MAC and compares it to the value stored in the "Weak Group
       MAC" field.  If the check fails, the packet is immediately
       dropped.

   4.  Disclosed Key processing: When the packet discloses a key (i.e.,
       with a standard or compact authentication tag, or with a standard
       or compact authentication tag with 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), or with an
          index strictly superior (i.e., with an index > i-d).  If such
          a legitimate key exists, the receiver ignores the current
          disclosed key and skips the "Key verification test".



Roca, et al.             Expires August 21, 2008               [Page 39]

Internet-Draft            TESLA in ALC and NORM            February 2008


       *  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.

   5.  When applicable, the receiver performs congestion control, even
       if the packet has not yet been authenticated
       [draft-ietf-rmt-bb-lct-revised].  If this feature leads to a
       potential DoS attack (the attacker can send a high data rate
       stream of faked packets), it does not compromise the security
       features offered by TESLA and enables a rapid reaction in front
       of actual congestion problems.

   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
       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.3).




Roca, et al.             Expires August 21, 2008               [Page 40]

Internet-Draft            TESLA in ALC and NORM            February 2008


   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.  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.

   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 August 21, 2008               [Page 41]

Internet-Draft            TESLA in ALC and NORM            February 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
   [draft-ietf-rmt-bb-lct-revised].

      ----- 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 August 21, 2008               [Page 42]

Internet-Draft            TESLA in ALC and NORM            February 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.  How this is done is
         out of the scope of this document;

      *  10: direct time synchronization response, sent by a NORM
         sender.  This type of message is invalid in case of an ALC
         session since ALC is restricted to unidirectional
         transmissions.  Yet an external mechanism may provide the
         direct time synchronization functionality.  How this is done is
         out of the scope of this document;

   "Content" field (variable length):




Roca, et al.             Expires August 21, 2008               [Page 43]

Internet-Draft            TESLA in ALC and NORM            February 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 August 21, 2008               [Page 44]

Internet-Draft            TESLA in ALC and NORM            February 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|1|0|  ^
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
  |       d       |       1       |       1       |       1       |  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
  |       1       |       1       |              128              |  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
  |         0 (reserved)          |             T_int             |  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
  |                                                               |  |
  +                      T_0 (NTP timestamp)                      +  | 5
  |                                                               |  | 2
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
  |                      N (Key Chain Length)                     |  | b
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  | y
  |                    Current Interval Index i                   |  | t
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  | e
  |                                                               |  | s
  +                                                               +  |
  |                                                               |  |
  +                 Current Key Chain Commitment                  +  |
  |                          (20 bytes)                           |  |
  +                                                               +  |
  |                                                               |  |
  +                                                               +  |
  |                                                               |  v
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  ---
  |                                                               |  ^ 1
  +                                                               +  | 2
  |                                                               |  | 8
  .                                                               .  |
  .                           Signature                           .  | b
  .                          (128 bytes)                          .  | y
  |                                                               |  | t
  +                                                               +  | e
  |                                                               |  v s
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  ---
  |                        Weak Group MAC                         |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 15: Example: Format of the bootstrap information message (Type
     0), using SHA-1/1024 bit signatures, the default HMAC-SHA-1 and a
                              Weak Group MAC.

   For instance Figure 15 shows the bootstrap information message when
   using the HMAC-SHA-1 transform for the PRF, MAC, and Weak Group MAC



Roca, et al.             Expires August 21, 2008               [Page 45]

Internet-Draft            TESLA in ALC and NORM            February 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 standard authentication tag (Type
                     5), using the default HMAC-SHA-1.















Roca, et al.             Expires August 21, 2008               [Page 46]

Internet-Draft            TESLA in ALC and NORM            February 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 Weak 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, out of the scope of this document,
   must be used with ALC for carrying direct time synchronization
   requests to the session's sender.

   In case of direct time synchronization, it is RECOMMENDED that the
   receivers spread the transmission of direct time synchronization
   requests over the time (Section 2.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



Roca, et al.             Expires August 21, 2008               [Page 47]

Internet-Draft            TESLA in ALC and NORM            February 2008


   symbol) or through the external mechanism use to carry the direct
   time synchronization request.

















































Roca, et al.             Expires August 21, 2008               [Page 48]

Internet-Draft            TESLA in ALC and NORM            February 2008


6.  IANA Considerations

   This document requires a IANA registration for the following
   attributes:

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

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

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

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




Roca, et al.             Expires August 21, 2008               [Page 49]

Internet-Draft            TESLA in ALC and NORM            February 2008


   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-1 (default).

                  +-----------------------------+-------+
                  | Cryptographic Function Name | Value |
                  +-----------------------------+-------+
                  |           INVALID           |   0   |
                  |                             |       |
                  |       SHA-1 (default)       |   1   |
                  +-----------------------------+-------+




























Roca, et al.             Expires August 21, 2008               [Page 50]

Internet-Draft            TESLA in ALC and NORM            February 2008


7.  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 initialized correctly,
      depending on the use-case;

   o  if the key disclosure schedule is to be changed (e.g., because the
      sender realizes that the parameters do not meet the receiver
      requirements), then this change MUST NOT be announced in-line,
      within the session.  Indeed, a receiver that missed the
      announcement would be vulnerable to attacks.  Note that in the
      current specification, the parameters that define the key
      disclosure schedule MUST be fixed during the whole session
      (Section 3.1.3).

   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.

7.1.  Dealing With DoS Attacks

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

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

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



Roca, et al.             Expires August 21, 2008               [Page 51]

Internet-Draft            TESLA in ALC and NORM            February 2008


   reasonable value.

7.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.

7.2.1.  Impacts of Replay Attacks on TESLA

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

   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.1.1), which voids replay attacks.

   o  direct time synchronization request: If the Weak Group MAC scheme
      is used, an attacker that is not member of the group can replay a
      packet and oblige the sender to to respond, which requires to
      digitally sign the response, a time-consuming process.  If the
      Weak Group MAC scheme is not used, an attack can anyway easily
      forge a request.  In both cases, the attack will not compromise
      TESLA component, but might create a DoS.  If this is a concern, it
      is RECOMMENDED, when the Weak Group MAC scheme is used, that the
      sender verify the "t_r" NTP timestamp contained in the request and
      respond only if this value is strictly larger than the previous
      one received from this receiver.  When the Weak Group MAC scheme
      is not used, this attack can be mitigated by limiting the number
      of requests per second that will be processed.

   o  direct time synchronization response: Upon receiving a response, a
      receiver who has no pending request MUST immediately drop the
      packet.  If this receiver that previously issued a request, he
      first checks the Weak Group MAC (if applicable), then the "t_r"
      field, to be sure it is a response to his request, and finally the
      digital signature.  A replayed packet will be dropped during these
      verifications, without compromising the TESLA component.



Roca, et al.             Expires August 21, 2008               [Page 52]

Internet-Draft            TESLA in ALC and NORM            February 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.

7.2.2.  Impacts of Replay Attacks on NORM

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

   First, let us consider replay attacks within a given NORM session.
   NORM defines a "sequence" field that can be used to protect against
   replay attacks [draft-ietf-rmt-pi-norm-revised] within a given NORM
   session.  This "sequence" field is a 16-bit value that is set by the
   message originator (sender or receiver) as a monotonically increasing
   number incremented with each NORM message transmitted.  It is
   RECOMMENDED that a receiver check this sequence field and drop
   messages considered as replayed.  Similarly, it is RECOMMENDED that a
   sender check this sequence, for each known receiver, and drop
   messages considered as replayed.  This analysis shows that NORM
   itself is robust in front of replay attacks within the same session.

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

7.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
      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



Roca, et al.             Expires August 21, 2008               [Page 53]

Internet-Draft            TESLA in ALC and NORM            February 2008


      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" packet is sent.
         Replaying this packet has no impact since the receivers already
         left.

      *  The same remark can be done for the "close object" packets.

   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 August 21, 2008               [Page 54]

Internet-Draft            TESLA in ALC and NORM            February 2008


8.  Acknowledgments

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















































Roca, et al.             Expires August 21, 2008               [Page 55]

Internet-Draft            TESLA in ALC and NORM            February 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.

   [draft-ietf-rmt-bb-lct-revised]
              Luby, M., Watson, M., and L. Vicisano, "Layered Coding
              Transport (LCT) Building Block",
               draft-ietf-rmt-bb-lct-revised-06.txt (work in progress),
              November 2007.

   [draft-ietf-rmt-pi-alc-revised]
              Luby, M., Watson, M., and L. Vicisano, "Asynchronous
              Layered Coding (ALC) Protocol Instantiation",
               draft-ietf-rmt-pi-alc-revised-05.txt (work in progress),
              November 2007.

   [draft-ietf-rmt-pi-norm-revised]
              Adamson, B., Bormann, C., Handley, M., and J. Macker,
              "Negative-acknowledgment (NACK)-Oriented Reliable
              Multicast (NORM) Protocol",
               draft-ietf-rmt-pi-norm-revised-05.txt (work in progress),
              March 2007.

9.2.  Informative References

   [Perrig04]
              Perrig, A. and J. Tygar, "Secure Broadcast Communication
              in Wired and Wireless Networks", Kluwer Academic
              Publishers ISBN 0-7923-7650-1, 2004.

   [RFC1305]  Mills, D., "Network Time Protocol (Version 3)
              Specification, Implementation", RFC 1305, March 1992.

   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
              Hashing for Message Authentication", RFC 2104,
              February 1997.

   [RFC3711]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
              Norrman, "The Secure Real-time Transport Protocol (SRTP)",
              RFC 3711, March 2004.



Roca, et al.             Expires August 21, 2008               [Page 56]

Internet-Draft            TESLA in ALC and NORM            February 2008


   [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.

   [draft-ietf-ntp-ntpv4-proto]
              Burbank, J., Kasch, W., Martin, J., and D. Mills, "The
              Network Time Protocol Version 4 Protocol Specification",
              draft-ietf-ntp-ntpv4-proto-07.txt (work in progress),
              May 2007.

   [draft-ietf-rmt-flute-revised]
              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 August 21, 2008               [Page 57]

Internet-Draft            TESLA in ALC and NORM            February 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 August 21, 2008               [Page 58]

Internet-Draft            TESLA in ALC and NORM            February 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 August 21, 2008               [Page 59]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/