RMT                                                           S. Faurite
Internet-Draft                                             A. Francillon
Expires: January 9, 2006                                         V. Roca
                                                                   INRIA
                                                            July 8, 2005


       TESLA source authentication in the ALC and NORM protocols
              draft-faurite-rmt-tesla-for-alc-norm-00.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 January 9, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

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





Faurite, et al.          Expires January 9, 2006                [Page 1]


Internet-Draft            TESLA in ALC and NORM                July 2005


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1   Context  . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.2   Conventions Used in this Document  . . . . . . . . . . . .  4
     1.3   Terminology and Notations  . . . . . . . . . . . . . . . .  4
   2.  Time Synchronization . . . . . . . . . . . . . . . . . . . . .  6
     2.1   Direct Time Synchronization  . . . . . . . . . . . . . . .  6
     2.2   Indirect Time Synchronization  . . . . . . . . . . . . . .  6
       2.2.1   Delay Bound Calculation in Indirect time
               Synchronization  . . . . . . . . . . . . . . . . . . .  7
   3.  Sender Operations  . . . . . . . . . . . . . . . . . . . . . .  8
     3.1   TESLA Parameters . . . . . . . . . . . . . . . . . . . . .  8
       3.1.1   Time Interval Schedule . . . . . . . . . . . . . . . .  8
       3.1.2   Key Chain  . . . . . . . . . . . . . . . . . . . . . .  8
     3.2   TESLA Signaling  . . . . . . . . . . . . . . . . . . . . .  9
       3.2.1   Bootstrap Information  . . . . . . . . . . . . . . . .  9
       3.2.2   Authentication Tag . . . . . . . . . . . . . . . . . . 10
     3.3   Signaling Information Format . . . . . . . . . . . . . . . 10
       3.3.1   Bootstrap Information Format . . . . . . . . . . . . . 10
       3.3.2   Standard Authentication Tag Format . . . . . . . . . . 16
       3.3.3   Authentication Tag Format with a New key Chain
               Commitment . . . . . . . . . . . . . . . . . . . . . . 16
       3.3.4   Authentication Tag Format with an Old Key Chain
               Commitment . . . . . . . . . . . . . . . . . . . . . . 17
   4.  Receiver Operations  . . . . . . . . . . . . . . . . . . . . . 18
     4.1   Initialization of a Receiver . . . . . . . . . . . . . . . 18
       4.1.1   Processing the Bootstrap Information Message . . . . . 18
       4.1.2   Time Synchronization . . . . . . . . . . . . . . . . . 18
     4.2   Authentication of Received Packets . . . . . . . . . . . . 19
   5.  Integration in the ALC and NORM Protocols  . . . . . . . . . . 21
     5.1   Authentication Header Extension Format . . . . . . . . . . 21
     5.2   Use of Authentication Header Extensions  . . . . . . . . . 22
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 24
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
     7.1   Normative References . . . . . . . . . . . . . . . . . . . 25
     7.2   Informative References . . . . . . . . . . . . . . . . . . 25
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25
   A.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 27
     A.1   Cryptographic pseudo-random function (PRF) . . . . . . . . 27
     A.2   Cryptographic message authentication code (MAC)  . . . . . 27
     A.3   Signature type . . . . . . . . . . . . . . . . . . . . . . 27
     A.4   Certificate type . . . . . . . . . . . . . . . . . . . . . 28
       Intellectual Property and Copyright Statements . . . . . . . . 29







Faurite, et al.          Expires January 9, 2006                [Page 2]


Internet-Draft            TESLA in ALC and NORM                July 2005


1.  Introduction

1.1  Context

   This document explains how to integrate the TESLA source
   authentication and packet integrity protocol to the ALC and NORM
   protocols.  The FLUTE content delivery application, built on top of
   ALC, can directly benefit from the services offered by TESLA at the
   transport layer.

   This draft only considers the authentication/integrity of the packets
   generated by the session's sender, not the feedback packets that may
   be generated by receivers with NORM for instance.  Because of the low
   rate and sporadic transmission of feedback packets, an authentication
   scheme different from TESLA may be more appropriate in that case.  Of
   course, this remark does not apply to ALC since transmissions are
   purely unidirectional.

   The security offered by TESLA heavily relies on time.  Therefore the
   sender and each receiver need to be time synchronized in a secure
   way.  Two methods exist: a direct one and an indirect one.  The
   present document explains how to achieve time synchronization in each
   case.

   When a broadcaster uses the TESLA with direct time synchronization,
   each receiver asks the sender for a time synchronization.  The source
   then directly answers to each request, signing the reply.  The
   security of this synchronization method is guaranteed, but the source
   MAY collapse it the rate of requests exceeds a certain threshold, and
   a bidirectional channel MUST exist between the source and each
   receiver.  If this may not be an issue with NORM sessions, it will be
   in case of ALC.

   When a broadcaster uses TESLA with indirect time synchronization, the
   source and each receiver must synchronize with another time reference
   (e.g. one or more NTP servers, or a GPS device) securely.  In that
   case, if the external time reference does not create a bottleneck,
   there is no scalability penalty.  Besides it works with
   unidirectional connections from the source to the receiver.
   Therefore this approach is well suited to ALC sessions.

   TESLA requires the transmission of key control information between
   the source and each receiver.  In particular it defines:

   o  a bootstrapping information message that carries control
      information needed by a receiver to initialize its TESLA
      component.  Depending on the time synchronization method, this
      message will be sent either directly to a receiver upon request or



Faurite, et al.          Expires January 9, 2006                [Page 3]


Internet-Draft            TESLA in ALC and NORM                July 2005


      broadcast periodically.  This latter possibility enables in
      particular late receivers to catch up, which is required with ALC
      sessions in ``on-demand'' mode;

   o  an authentication tag is associated to each packet in order to
      enable the authentication of previously sent packets, and possibly
      to announce a new or old key commitment;

   o  a direct synchronization request message;

   The present document explains how to carry this information in the
   ALC and NORM protocols, using a dedicated authentication protocol
   header extension, EXT_AUTH=1 (already mentioned in [RFC3451]).

   For more informations on the TESLA protocol and its principles,
   please refer to [RFC4082] and the references mentioned in that
   document.

1.2  Conventions Used in this Document

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

1.3  Terminology and Notations

   The following notations are used throughout this document:

   o  PRF is the Pseudo Random Function.

   o  MAC is the Message Authentication Code.

   o  HMAC is the Keyed-Hash Message Authentication Code.

   o  TN is the reference time at some point.

   o  T_s is the TESLA server local time corresponding to reference time
      TN.

   o  T_r is the TESLA receiver local time corresponding to reference
      time TN.

   o  N_tx_old_kcc is ...

   o  N_tx_new_kcc is ...

   o  N is the number of keys of a key chain.  When several chains are
      used, all chains have the same length.



Faurite, et al.          Expires January 9, 2006                [Page 4]


Internet-Draft            TESLA in ALC and NORM                July 2005


   o

   o  TODO: finish this list...
















































Faurite, et al.          Expires January 9, 2006                [Page 5]


Internet-Draft            TESLA in ALC and NORM                July 2005


2.  Time Synchronization

   The security of TESLA relies on time.  The sender uses a set of keys
   to compute the MAC of the messages and discloses these keys later.
   The receiver MUST ensure that each packet he received cannot have
   been sent after the disclosure of the corresponding key.

   To achieve this, the sender and the receiver MUST be synchronized.
   More precisely, the receiver must know an upper bound of the sender's
   local time.  There are two possibilities:

   o  Direct time synchronization: each receiver asks the sender for a
      time synchronization.

   o  Indirect time synchronization: each receiver and the sender use an
      other time reference, like a NTP server or GPS device.


2.1  Direct Time Synchronization

   The receiver sends a synchronization request, that includes a nonce,
   to the sender and remembers the local receiver time the message was
   sent, t_r.  The sender records its local time upon receiving the
   request, t_s.  The sender sends a reply (a bootstrapping information
   message, Section 3.2.1) that includes in particular t_s.  This
   answer, plus the nonce that is appended, is digitally signed.  The
   nonce is then removed, and the reply is sent to the receiver.  After
   authenticating the reply, the receiver can estimate an upper bound of
   the sender's time: D_t = t_s - t_r + S, where S is an estimated bound
   on the clock drift throughout the duration of the session.  See
   [RFC4082] for further details.

   Since a bidirectional channel is assumed, this method is well suited
   to NORM sessions.  Section 4.1.2 details the request message in case
   of NORM.  Section 3.2.1 details the bootstrapping information.

2.2  Indirect Time Synchronization

   Indirect time synchronization relies on a time reference, for
   instance a NTP time server or a GPS synchronized clock.  The sender
   and each receiver then synchronize directly and independently with
   this third party.  In the case of a synchronization through a NTP
   time server, several time servers SHOULD be available for scalability
   purpose.

   There are two drawbacks:





Faurite, et al.          Expires January 9, 2006                [Page 6]


Internet-Draft            TESLA in ALC and NORM                July 2005


   o  The session's sender looses the control of the synchronization.
      Since it is vital to the whole security, this synchronization must
      be fully secured.

   o  When different NTP servers are used, these servers MUST be
      securely and reliably synchronized between each other.


2.2.1  Delay Bound Calculation in Indirect time Synchronization

   Let's assume the sender and each receiver synchronize with one or
   several reference time servers.  A direct time synchronization
   between the server and the reference time server results in ds = TN -
   Ts.  A direct time synchronization between a receiver and the same
   reference time server results in dr = TN - Tr.  So: D = ds - dr, is
   the offset between the TESLA server and the TESLA receiver (since D =
   (TN - Ts) - (TN - Tr) = Tr - Ts).  When a receiver receives packets,
   he is now able to compute the upper bound on the time server when it
   sends it.  If tr is the time when the receiver gets the packet and ts
   is the corresponding time of the server, we have tr = Tr + t and ts =
   Ts + t.  The receiver can compute the server time by doing tr - D =
   (Tr + t) - (Tr - Ts) = ts.

   For more security, we can substract to D two positive values:

   o  an upper bound on the maximum clock drift between the sender and
      the receiver during the session.

   o  when the server and the receiver use different NTP time servers :
      an upper bound on the NTP time error between two different NTP
      servers.

   Let Derr be the sum of these upper bounds.

   So: D = ds - dr - Derr, with Derr > 0.  When computing tr - D = ts +
   Derr, we now have a security margin when we do the TESLA security
   check, that is we must have received the packet before the disclosing
   of the key used to compute the MAC of this packet.

   In the bootstrapping information (see Section 3.3.1), the ds value
   (which can be negative) is sent.  This information does not depend on
   the receiver, so the bootstraping information can be broadcast to all
   receivers.








Faurite, et al.          Expires January 9, 2006                [Page 7]


Internet-Draft            TESLA in ALC and NORM                July 2005


3.  Sender Operations

3.1  TESLA Parameters

3.1.1  Time Interval Schedule

   The sender must choose a time interval schedule.  That is it must
   decide when the different keys needed by TESLA will be used and
   disclosed.  The different parameters are:

   o  T_int: the interval duration usually ranging from 100 milliseconds
      to 1 second.

   o  d: the key disclosure delay.  It is the time to wait (in a number
      of intervals) to disclose a key.  A key is part of a one-way key
      chain.

   o  N: the length of the key chain.  When a key chain is finished it
      is possible to switch to a new key chain.

   o  TI_0: the starting time of time interval 0.


3.1.2  Key Chain

   The TESLA sender must compute a one-way key chain of N keys.  It must
   first select a Primary Key, choose two PRF function F and F', and
   then compute all the previous keys using K_{i-1} = F(K_i).  The key
   for MAC calculation can then be derived from the corresponding K_i
   key by K'_i=F'(K_i).  The randomness of the Primary key is vital to
   the security since no one should be able to guess it.

   The key chain has a finite length, so the TESLA session must finish
   before the end of the key chain.  But the longer the key chain, the
   higher the memory and computation required to cope with it.  Another
   solution consists in switching to a new key chain when necessary.

   To do so, the sender must send a commitment to the new key chain
   before the end of the current key chain.  This commitment is simply
   F(K_{N+1}) and should be sent during N_tx_new_kcc intervals before
   the end of the key chain.  Generally, several packets are sent during
   a time interval, so it is possible to alternate between sending a
   disclosed key and a commitment to the new key chain, which offers the
   benefit of adding no overhead.  See Section 3.3.3 for more
   informations.

   The receiver will keep the commitment, until the key K_{N+1} (the
   first of the new key chain) is disclosed.  Then the receiver will be



Faurite, et al.          Expires January 9, 2006                [Page 8]


Internet-Draft            TESLA in ALC and NORM                July 2005


   able to test the validity of that key by computing F(K_{N+1}) and
   comparing it to the commitment.

   When a key chain is changed, it becomes impossible to recover a
   previous key from the old key chain.  This is a problem if the
   receiver lost the packets disclosing the last key of the old key
   chain.  A solution consists in re-sending the last key K_N of the old
   key chain.  This is done during N_tx_old_kcc intervals at the
   beginning of the new key chain.  See Section 3.3.4 for more
   informations.

3.2  TESLA Signaling

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

   o  The bootstrap information, which is a digitally signed packet
      containing all the information required to bootstrap TESLA at a
      receiver.

   o  The authentication tag, which is sent in all packets (see
      Section 5 for exceptions) and contains the MAC of the packet.


3.2.1  Bootstrap Information

   In order to initialize the TESLA component at a receiver, the sender
   must communicate some key information.  This TESLA bootstrap
   information MUST be securely transmitted, in particular a receiver
   must be able to check the packet source and the packet integrity
   using standard protocols.  Any digital signature will do.

   The bootstrap information can be either sent in point to point, after
   a direct synchronization request from a receiver, or broadcast to all
   receivers, for instance periodically, when indirect time
   synchronization is used.

   The periodic transmission of the bootstrap information message will
   be required in indirect time synchronization mode when:

   o  the ALC session uses an ``on-demand'' mode, clients arriving at
      their own discretion,

   o  the packet containing the bootstrap information has been lost by
      some clients,

   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 1 second for the



Faurite, et al.          Expires January 9, 2006                [Page 9]


Internet-Draft            TESLA in ALC and NORM                July 2005


   transmission of this bootstrap information is often a reasonable
   value.

   The bootstrap information message MAY be sent only once in other
   cases, in particular with sessions in ``push'' mode, when all clients
   will receive with a very high probability the corresponding packet.

   In some cases, a change in the key chain can lead a receiver having
   experienced a very long disconnection to loose the commitment of the
   new chain, and therefore be unable to authenticate any packet related
   to the new chain and all the following ones.  To solve this issue,
   the sender can extend the T_tx_new_kcc value, but this will remain a
   partial solution (a receiver may be disconnected during the whole key
   chain period), or decide to periodically send the bootstrap
   information message, even in direct time synchronization mode.

3.2.2  Authentication Tag

   Every authenticated packet must have an authentication tag,
   containing the MAC of the message and a disclosed key.

   The computation of the MAC, MAC(K_i, M), includes the ALC or NORM
   header, including the various header extensions, plus the payload
   when applicable.  The UDP/IP/MAC headers are not included.  During
   this computation, the MAC(K_i, M) field of the authentication tag
   (see Section 3.3.2 Section 3.3.3 Section 3.3.4) MUST be set to 0.

3.3  Signaling Information Format

   This section specifies the format of the various kinds of TESLA
   signaling information sent by the sender.

3.3.1  Bootstrap Information Format

      ----- Editor's note: This bootstrap information format is based on
      the expired draft [tesla/spec], modified.  The present format is
      not fully satisfying and will probably be changed in new versions
      of this I-D. -----













Faurite, et al.          Expires January 9, 2006               [Page 10]


Internet-Draft            TESLA in ALC and NORM                July 2005


   The format of the bootstrap information:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  KC PRF type  | MAC PRF type  | HMAC func type| Signature type|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |# cert |rsvd |P| d (intervals) |      T_int (milliseconds)     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      K_j Key length           |      Signature length         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                               N                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          Id j of K_j                          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    ~                              K_j              +-+-+-+-+-+-+-+-+
    |                                               |   Padding     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                     TI_0 (NTP timestamp)                      +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                     ds or t_s (NTP timedif)                   +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    ~                     Signature extension                       ~
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    ~                   NTP informations (Optional)                 ~
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 1

   The reference numbers are described in Appendix A

   o  The key chain PRF type is the reference number of the F function
      used to calculate the key chain.

   o  The MAC PRF type is the reference number of the F' function used
      to derive the MAC key from the key chain.

   o  The HMAC function type is the reference number of the function
      used to compute the HMAC of the packets.



Faurite, et al.          Expires January 9, 2006               [Page 11]


Internet-Draft            TESLA in ALC and NORM                July 2005


   o  Signature type is the reference number of the digital signature
      used to authenticate this bootstrap information.

   o  # of certs is the number of certificates present in the signature
      extension.

   o  P ("Positive") is a boolean used in the indirect time
      synchronization.  It indicates whether the D time difference is
      positive (P=1) or negative (P=0).

   o  d is an unsigned integer that defines the number of intervals
      before key disclosure (e.g. if a key is used in interval i, this
      key will be disclosed in interval i+d). d MUST be greater or equal
      to 2.

   o  T_int is an unsigned integer corresponding to the number of
      milliseconds of one interval.

   o  K_j Key length is the length in bits of key K_j.

   o  Signature length is the number of bytes of the signature included
      in the signature extension.

   o  N is the number of keys of the key chain.

   o  Id j of K_j is an unsigned integer corresponding to the index of
      the interval of the key released in this bootstrap information.
      For performance reasons, the sender SHOULD always send a bootstrap
      information with the highest Id j possible since this will reduce
      the number of computation for the receivers that join later.

   o  K_j is the key corresponding to the interval j.  If i is the
      current interval we MUST have: j < i - d.

   o  TI_0 is the time of the beginning of interval 0.  It is a NTP
      timestamp, composed of two 32 bits word: one for the seconds
      elapsed since 01/01/1900 at 00:00 and the other one for the
      fraction of seconds.

   o  ds or t_s (NTP timedif) depends on the time synchronization mode.
      In direct mode, this field contains t_s, which is the sender's
      local time when he received the request (Section 2.1).  In
      indirect mode, this field contains ds, the offset between the
      server and an NTP server or an other time reference (Section 2.2).

   o  The format of the signature extension is described below, and
      depends on the "# of certs" field.




Faurite, et al.          Expires January 9, 2006               [Page 12]


Internet-Draft            TESLA in ALC and NORM                July 2005


   o  The NTP information is optional and is described below.  Its
      presence can be detected by the total length of the signature.

   The signature extension format when the "# of certs" field is
   strictly greater than 0 (2 in this example) is:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | cert 1 type   | cert 1 length |                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
    |                                                               |
    ~                         Certificate 1         +-+-+-+-+-+-+-+-+
    |                                               |   Padding     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | cert 2 type   | cert 2 length |                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
    |                                                               |
    ~                         Certificate 2         +-+-+-+-+-+-+-+-+
    |                                               |    Padding    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    ~                           Signature           +-+-+-+-+-+-+-+-+
    |                                               |    Padding    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 2

   In Figure 2:

   o  Type of certificate identifies the algorithm used for the
      certificate (see Appendix A).

   o  The certificate length is the length in bytes of the certificate.

   o  The certificate field contains a certificate signed by an external
      authority and that certifies the sender's public key.  This field
      is padded (with 0) up to a multiple of 32 bits.

   o  The signature is a digital signature using the type and length
      specified in the main part of the bootstrap information message.
      This field is padded (with 0) up to a multiple of 32 bits.









Faurite, et al.          Expires January 9, 2006               [Page 13]


Internet-Draft            TESLA in ALC and NORM                July 2005


   The signature extension format when the "# of certs" field is zero
   (i.e. when no certificate is provided) is:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    ~                           Signature           +-+-+-+-+-+-+-+-+
    |                                               |    Padding    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 3

   In Figure 3:

   o  The signature is a digital signature using the type and length
      specified in the main part of the bootstrap information message.
      This field is padded (with 0) up to a multiple of 32 bits.

































Faurite, et al.          Expires January 9, 2006               [Page 14]


Internet-Draft            TESLA in ALC and NORM                July 2005


   The optional NTP information format, when two NTP servers are
   specified, is:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | total length  | # of entries  |  reserved (0) |   cert type   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | FQDN 1 length | cert 1 length |                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
    |                                                               |
    ~                  NTP Server 1 FQDN            +-+-+-+-+-+-+-+-+
    |                                               |   Padding     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    ~                 NTP Certificate (optional)    +-+-+-+-+-+-+-+-+
    |                                               |   Padding     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | FQDN 2 length | cert 2 length |                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
    |                                                               |
    ~                  NTP Server 2 FQDN            +-+-+-+-+-+-+-+-+
    |                                               |   Padding     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    ~                 NTP Certificate (optional)    +-+-+-+-+-+-+-+-+
    |                                               |   Padding     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 4

   In Figure 4:

   o  The total length is the total length in units of 32 bit words of
      this NTP information extension;

   o  The # of entries is the number of NTP entries;

   o  Type of certificates identifies the algorithm used for all the
      certificates that may be provided (see Appendix A).

   o  The FQDN length is the number of bytes of the NTP server fully
      qualified domain name;

   o  The NTP server FQDN is a string containing the NTP server Fully
      Qualified Domain Name (e.g. "ntp.foo.bar.").  This field is padded
      (with 0) up to a multiple of 32 bits;




Faurite, et al.          Expires January 9, 2006               [Page 15]


Internet-Draft            TESLA in ALC and NORM                July 2005


   o  The NTP Certificate is optional.  The content delivery server can
      use it to self-certify the NTP public key.  The certificate length
      indicates whether this field is present or not.  This field is
      padded (with 0) up to a multiple of 32 bits.


3.3.2  Standard Authentication Tag Format

   Here is the format of the authentication tag:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Id i of K_i                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    ~                    Disclosed Key K_{i-d}      +-+-+-+-+-+-+-+-+
    |                                               |   Padding     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    ~                        MAC(K_i, M)            +-+-+-+-+-+-+-+-+
    |                                               |   Padding     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 5

   In Figure 5:

   o  The Id i is the index of the key used for computing the MAC of
      this packet.

   o  The disclosed key MUST be the key used for interval i-d.

   o  MAC(K_i, M) is the message authentication code of the current
      packet, including the ALC or NORM header (including the header
      extensions), plus the payload when applicable.


3.3.3  Authentication Tag Format with a New key Chain Commitment

   During the last N_tx_new_kcc intervals of the current key chain, the
   sender MUST send a commitment to the next key chain.  This is done by
   replacing the disclosed key of the authentication tag with the new
   key commitment, F(K_{N+1})







Faurite, et al.          Expires January 9, 2006               [Page 16]


Internet-Draft            TESLA in ALC and NORM                July 2005


   Here is the format of the authentication tag with an new key
   commitment tag:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Id i of K_i                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    ~              New Key Commitment F(K_{N+1})    +-+-+-+-+-+-+-+-+
    |                                               |   Padding     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    ~                        MAC(K_i, M)            +-+-+-+-+-+-+-+-+
    |                                               |   Padding     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 6


3.3.4  Authentication Tag Format with an Old Key Chain Commitment

   During the first N_tx_old_kcc intervals of the new key chain after
   the disclosing interval, d, the sender must send a commitment to the
   old key chain.  This is done by replacing the disclosed key of the
   authentication tag with the old key commitment, K_N

   Here is the format of the authentication tag with an old key
   commitment tag:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Id i of K_i                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    ~                   Old Key Commitment K_N      +-+-+-+-+-+-+-+-+
    |                                               |   Padding     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    ~                        MAC(K_i, M)            +-+-+-+-+-+-+-+-+
    |                                               |   Padding     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 7






Faurite, et al.          Expires January 9, 2006               [Page 17]


Internet-Draft            TESLA in ALC and NORM                July 2005


4.  Receiver Operations

4.1  Initialization of a Receiver

   A receiver must be initialized before being able to authenticate the
   source of incoming packets.  Two actions must be performed:

   o  receive and process a bootstrap information message, and

   o  calculate an  upper bound of the sender's local time, and to that
      purpose, he must perform time synchronization.


4.1.1  Processing the Bootstrap Information Message

   A receiver must receive a packet containing the bootstrap
   information, digitally signed by the sender, and verify its
   signature.  Because the packet is signed, the receiver also needs to
   know the public key of the sender.  The present document does not
   specify how the public key of the sender is communicated reliably and
   in a secure way to all possible receivers.  Once the bootstrap
   information has been proved to be safe, the receiver can initialize
   its TESLA component.  Time synchronization is detailed in
   Section 4.1.2.  The receiver stores the parameters related to the
   time interval schedule and key chain.  The receiver can then ignore
   next bootstrap information messages, except if he is in a new key
   chain and missed all the commitments for 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
   buffer incoming packets, recording the reception time of each packet,
   and proceed with delayed authentication later, once the receiver will
   be fully initialized.  In that case, the buffer must be carefully
   sized.

4.1.2  Time Synchronization

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

   In case of a direct time synchronization, a receiver MUST first
   synchronize with the sender.  To that purpose, the receiver sends
   direct time synchronization request message.  This message includes a
   nonce, i.e. a random number chosen independently by the receiver,
   that will be integrated when the sender calculates the digital
   signature of his reply.



Faurite, et al.          Expires January 9, 2006               [Page 18]


Internet-Draft            TESLA in ALC and NORM                July 2005


   The request for a direct time synchronization contains the following
   information:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    ~                                                               ~
    |                          Nr (nonce)                           |
    ~                                                               ~
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 8

   With the indirect time synchronization method, the sender MAY provide
   in its bootstrap information, the URL of the NTP servers he trusts
   along with an OPTIONAL certificate for each NTP server.  When NTP
   servers are specified, a receiver SHOULD choose one of the NTP
   servers provided.  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
   secured, either using the certificate provided by the content
   delivery server, or another certificate the client may obtain for
   this NTP server.

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

   Since the offset between the server and the time reference is
   indicated in the bootstrap information message, the receiver can now
   calculate an upper bound of the sender's local time Section 2.2.

4.2  Authentication of Received Packets

   The receiver can now authenticate incoming packets.  To that purpose,
   he must follows different steps:

   1.  The receiver parses the different packet headers.  If the TESLA
       authentication tag is not present, the receiver MUST reject the
       packet.

   2.  Then proceed with the TESLA safe test: (1) check that the key
       used to compute the MAC of this packet has not already been
       disclosed, and (2) check the disclosed key by computing the



Faurite, et al.          Expires January 9, 2006               [Page 19]


Internet-Draft            TESLA in ALC and NORM                July 2005


       necessary number of PRF functions to obtain a previously safe
       disclosed key.  If any of these two tests fail, the receiver MUST
       reject the packet.

   3.  Then, according to the [RFC3451], when applicable, perform
       congestion control even if the packet has not yet been
       authenticated.  If this feature leads to a potential DoS attack,
       it does not compromise the security features offered by TESLA and
       enables a rapid reaction in front of congestion problems.

   4.  Then buffer the packet for a later authentication, once the
       corresponding key will be received or deduced from another  key.

   5.  If the disclosed key is a new one, then the receiver can
       authenticate previously stored packets using this key or any key
       derived from this one.

   6.  If a packet fails to be authenticated, then this packet MUST be
       rejected.

   7.  If a packet is successfully authenticated, then the receiver
       continues processing it.

      ----- Editor's note: [RFC4082] explains that unauthenticated
      packets SHOULD be destroyed, and if not this is at the own risk of
      the receiver.  We choose the other strategy, requiring that unsafe
      packets be destroyed when the client decides to use TESLA.  But
      the client can at any time choose to continue an ALC or NORM
      session in unsafe mode, ignoring TESLA extensions. -----






















Faurite, et al.          Expires January 9, 2006               [Page 20]


Internet-Draft            TESLA in ALC and NORM                July 2005


5.  Integration in the ALC and NORM Protocols

5.1  Authentication Header Extension Format

   The integration of TESLA in ALC or NORM is similar and relies on the
   header extension mechanism defined in both protocols.  More precisely
   we further specify the EXT_AUTH=1 header extension [RFC3451].
   Several fields are added in addition to the HET (Header Extension
   Type) and HEL (Header Extension Length) fields (Figure 9).

   Here is the format of the LCT or NORM extension header:

     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      | Prot  |Version| resvd | Type  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    ~                                                               ~
    |                       Extension content                       |
    ~                                                               ~
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 9

   The following fields are defined:

   o  the Prot (Authentication Protocol) field (4 bits) identifies the
      source authentication protocol in use.  We use 1 for TESLA.

   o  the Version field (4 bits) identifies the version number of the
      authentication scheme.

   o  the  resvd (Reserved) field (4 bits) is not used and must be
      zero'ed.

   o  the Type field(4 bits) identifies the type of message:

      *  1: bootstrap information, sent by the sender periodically
         (Section 3.3.2);

      *  2: authentication information for the on-going key chain, sent
         by the sender along with each packet;

      *  3: authentication information along with a new key chain
         commitment, sent by the sender when approaching the end of a
         key chain;



Faurite, et al.          Expires January 9, 2006               [Page 21]


Internet-Draft            TESLA in ALC and NORM                July 2005


      *  4: authentication information along with an old key chain
         commitment, sent by the sender some time after moving to a new
         key chain;

      *  5: direct synchronization request, sent by a NORM receiver;

   Each packet sent by the sender MUST contain exactly one of these
   header extensions when TESLA is used in an ALC or NORM session.  All
   receivers MUST recognize EXT_AUTH but MAY NOT be able to parse its
   content, for instance because they do not use the TESLA building
   block, and in that case they SHOULD ignore the EXT_AUTH extensions.
   In case of NORM, the packets sent by receivers MAY contain a direct
   synchronization request but MUST NOT contain any of the other four
   authentication header extensions.

      ----- Editor's note: this document defines a "Scheme" field that
      further identifies the authentication protocol.  By doing so, all
      the documents specifying another authentication protocol and
      relying on the header extension mechanism MUST reserve the same 4
      bit "Scheme" field.  One advantage is that several authentication
      protocols can be used in a session (perhaps with a NORM session
      for the feedback messages).  This possibility must be discussed.
      The other solution is to say that there's a single authentication
      protocol per session, communicated out of band, and therefore the
      authentication header extension is fully defined (same approach as
      that of the CCI ALC/LCT congestion control field). -----


5.2  Use of Authentication Header Extensions

   The bootstrap information (Type=1) SHOULD be sent in a stand-alone
   control packet rather than in data packets.  The reason is the large
   size of this bootstrap information which largely increases the
   maximum ALC/LCT or NORM header size.  By having the bootstrap
   information header extension in stand-alone packets, the maximum
   payload of data packets is only affected by the unavoidable
   authentication tag, not by an additional large header extension sent
   at a low frequency.

   The three authentication information extension headers (Type=2, 3, or
   4) are attached to the corresponding packet (data or control packet).
   There is no authentication information header extension in case of a
   control packet containing only the bootstrap information.

   In case of NORM, the direct synchronization request extension header
   (Type=5) is sent by a receiver in a XXX NORM packet (see editor's
   note below).  There is no authentication information header extension
   in this case since this draft only considers the authentication/



Faurite, et al.          Expires January 9, 2006               [Page 22]


Internet-Draft            TESLA in ALC and NORM                July 2005


   integrity of the packets generated by the session's sender.

      ----- Editor's note: what type of NORM packet should be used to
      that purpose?  NORM_REPORT is one possibility.  TBD... -----















































Faurite, et al.          Expires January 9, 2006               [Page 23]


Internet-Draft            TESLA in ALC and NORM                July 2005


6.  Security Considerations

   The security of the TESLA protocol is discussed in [RFC4082].
   Security considerations specific to its use in ALC and NORM remain
   TBD...














































Faurite, et al.          Expires January 9, 2006               [Page 24]


Internet-Draft            TESLA in ALC and NORM                July 2005


7.  References

7.1  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", RFC 2119, BCP 14, March 1997.

   [RFC3450]  Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., and J.
              Crowcroft, "Asynchronous Layered Coding (ALC) Protocol
              Instantiation", RFC 3450, December 2002.

   [RFC3451]  Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., Handley,
              M., and J. Crowcroft, "Layered Coding Transport (LCT)
              Building Block", RFC 3451, December 2002.

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

7.2  Informative References

   [tesla/spec]
              Perrig, A., Canetti, R., and B. Whillock, "TESLA:
              Multicast Source Authentication Transform Specification
              (draft-ietf-msec-tesla-spec-00.txt)", October 2002.


Authors' Addresses

   Sebastien Faurite
   INRIA
   655, av. de l'Europe
   Zirst; Montbonnot
   ST ISMIER cedex  38334
   France

   Phone:
   Email: sebastien.faurite@inrialpes.fr
   URI:











Faurite, et al.          Expires January 9, 2006               [Page 25]


Internet-Draft            TESLA in ALC and NORM                July 2005


   Aurelien Francillon
   INRIA
   655, av. de l'Europe
   Zirst; Montbonnot
   ST ISMIER cedex  38334
   France

   Phone:
   Email: aurelien.francillon@inrialpes.fr
   URI:


   Vincent Roca
   INRIA
   655, av. de l'Europe
   Zirst; Montbonnot
   ST ISMIER cedex  38334
   France

   Phone:
   Email: vincent.roca@inrialpes.fr
   URI:





























Faurite, et al.          Expires January 9, 2006               [Page 26]


Internet-Draft            TESLA in ALC and NORM                July 2005


Appendix A.  IANA Considerations

   This document requires an IANA registration for the following
   attributes:

A.1  Cryptographic pseudo-random function (PRF)

   We use :

                           +---+-----------+
                           |   | algorithm |
                           +---+-----------+
                           | 1 |    MD5    |
                           +---+-----------+


A.2  Cryptographic message authentication code (MAC)

   We use :

                     +---+-----------+------------+
                     |   | algorithm | key length |
                     +---+-----------+------------+
                     | 1 |    MD5    |     64     |
                     |   |           |            |
                     | 2 |    MD5    |     96     |
                     |   |           |            |
                     | 3 |    MD5    |     128    |
                     +---+-----------+------------+


A.3  Signature type

   We use :

               +---+------------------------------------+
               |   |              algorithm             |
               +---+------------------------------------+
               | 1 | PKCS #1: RSA Cryptography Standard |
               +---+------------------------------------+











Faurite, et al.          Expires January 9, 2006               [Page 27]


Internet-Draft            TESLA in ALC and NORM                July 2005


A.4  Certificate type

   We use :

               +---+------------------------------------+
               |   |              algorithm             |
               +---+------------------------------------+
               | 1 | PKCS #1: RSA Cryptography Standard |
               +---+------------------------------------+










































Faurite, et al.          Expires January 9, 2006               [Page 28]


Internet-Draft            TESLA in ALC and NORM                July 2005


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Faurite, et al.          Expires January 9, 2006               [Page 29]