[Docs] [txt|pdf] [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: Standards Track                              S. Faurite
Expires: September 3, 2007                                         INRIA
                                                           March 2, 2007


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

Status of this Memo

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

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

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

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

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

   This Internet-Draft will expire on September 3, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).













Roca, et al.            Expires September 3, 2007               [Page 1]

Internet-Draft            TESLA in ALC and NORM               March 2007


Abstract

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


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Conventions Used in this Document  . . . . . . . . . . . .  5
     1.2.  Terminology and Notations  . . . . . . . . . . . . . . . .  5
   2.  Using TESLA with ALC and NORM  . . . . . . . . . . . . . . . .  7
     2.1.  ALC and NORM Specificities that Impact TESLA . . . . . . .  7
     2.2.  The Need for Secure Time Synchronization . . . . . . . . .  8
       2.2.1.  Direct Time Synchronization  . . . . . . . . . . . . .  8
       2.2.2.  Indirect Time Synchronization  . . . . . . . . . . . .  8
   3.  Time Synchronization and Delay Bound Calculations  . . . . . . 10
     3.1.  Delay Bound Calculation in Direct Time Synchronization
           Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     3.2.  Delay Bound Calculation in Indirect time
           Synchronization Mode . . . . . . . . . . . . . . . . . . . 10
       3.2.1.  Single time reference  . . . . . . . . . . . . . . . . 10
       3.2.2.  Multiple time references . . . . . . . . . . . . . . . 11
   4.  Sender Operations  . . . . . . . . . . . . . . . . . . . . . . 12
     4.1.  TESLA Parameters . . . . . . . . . . . . . . . . . . . . . 12
       4.1.1.  Key Chains . . . . . . . . . . . . . . . . . . . . . . 12
       4.1.2.  Time Interval Schedule . . . . . . . . . . . . . . . . 13
     4.2.  TESLA Messages and Authentication Tags . . . . . . . . . . 13
       4.2.1.  Bootstrap Information  . . . . . . . . . . . . . . . . 14
       4.2.2.  Direct Time Synchronization Response . . . . . . . . . 15
       4.2.3.  Authentication Tag . . . . . . . . . . . . . . . . . . 15
     4.3.  TESLA Messages and Authentication Tag Format . . . . . . . 15
       4.3.1.  Bootstrap Information Format . . . . . . . . . . . . . 16
       4.3.2.  Format of a Direct Time Synchronization Response . . . 23
       4.3.3.  Format of a Standard Authentication Tag  . . . . . . . 25
       4.3.4.  Format of an Authentication Tag with a New Key
               Chain Commitment . . . . . . . . . . . . . . . . . . . 26
       4.3.5.  Format of an Authentication Tag with an Old Chain
               Last Key Disclosure  . . . . . . . . . . . . . . . . . 26
   5.  Receiver Operations  . . . . . . . . . . . . . . . . . . . . . 28
     5.1.  Initialization of a Receiver . . . . . . . . . . . . . . . 28
       5.1.1.  Processing the Bootstrap Information Message . . . . . 28
       5.1.2.  Time Synchronization . . . . . . . . . . . . . . . . . 28
       5.1.3.  Format of a Direct Time Synchronization Request  . . . 29
     5.2.  Authentication of Received Packets . . . . . . . . . . . . 30



Roca, et al.            Expires September 3, 2007               [Page 2]

Internet-Draft            TESLA in ALC and NORM               March 2007


   6.  Integration in the ALC and NORM Protocols  . . . . . . . . . . 31
     6.1.  Authentication Header Extension Format . . . . . . . . . . 31
     6.2.  Use of Authentication Header Extensions  . . . . . . . . . 33
       6.2.1.  EXT_AUTH Header Extension of Type Bootstrap
               Information  . . . . . . . . . . . . . . . . . . . . . 33
       6.2.2.  EXT_AUTH Header Extension of Type Bootstrap
               Information  . . . . . . . . . . . . . . . . . . . . . 33
       6.2.3.  EXT_AUTH Header Extension of Type Direct Time
               Synchronization Request  . . . . . . . . . . . . . . . 34
       6.2.4.  EXT_AUTH Header Extension of Type Direct Time
               Synchronization Response . . . . . . . . . . . . . . . 35
     6.3.  Managing Silent Periods  . . . . . . . . . . . . . . . . . 35
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 36
   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 37
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 38
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 38
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 38
   Appendix A.  IANA Considerations . . . . . . . . . . . . . . . . . 40
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41
   Intellectual Property and Copyright Statements . . . . . . . . . . 42































Roca, et al.            Expires September 3, 2007               [Page 3]

Internet-Draft            TESLA in ALC and NORM               March 2007


1.  Introduction

   Many applications using multicast and broadcast communications
   require that each receiver be able to authenticate the source of any
   packet it receives as well as its integrity.  For instance, ALC
   [draft-ietf-rmt-pi-alc-revised] and NORM
   [draft-ietf-rmt-pi-norm-revised] are two Content Delivery Protocols
   (CDP) designed to transfer reliably objects (e.g. files) between a
   session's sender and several receivers.

   The NORM protocol is based on bidirectional transmissions.  Each
   receiver acknowledges data received or, in case of packet erasures,
   asks for retransmissions.  The ALC protocol defines unidirectional
   transmissions.  Reliability can be achieved by means of cyclic
   transmissions of the content within a carousel, or by the use of
   proactive Forward Error Correction codes (FEC), or by the joint use
   of these mechanisms.  Being purely unidirectional, ALC is massively
   scalable, while NORM is intrinsically limited in terms of the number
   of receivers that can be handled in a session.  Both protocols have
   in common the fact that they operate at application level, on top of
   an erasure channel (e.g. the Internet) where packets can be lost
   (erased) during the transmission.  With some use case, an attacker
   might impersonate the the ALC or NORM session's sender and inject
   forged packets to the receivers, thereby corrupting the objects
   reconstructed by the receivers.

   The situation is much more complex in case of group communications
   than it is with unicast communications.  Indeed, in the latter case a
   simple solution exist: the sender and receiver can share a secret key
   to compute a Message Authentication Code (MAC) of all messages
   exchanged.  This is no longer feasible in case of a multicast and
   broadcast communications since sharing a group key between the sender
   and all receivers and using the same MAC scheme means that any group
   member can impersonate the sender and send forged messages to other
   receivers.

   The usual solution to provide the source authentication and message
   integrity services in case of multicast and broadcast communications
   consists in relying on asymmetric cryptography and using digital
   signatures.  Yet this solution is limited by high computational costs
   and high transmission overheads.  The Timed Efficient Stream Loss-
   tolerant Authentication protocol (TESLA) is an alternative solution
   that provides the two required services, while being compatible with
   high rate transmissions over lossy channels.

   This document explains how to integrate the TESLA source
   authentication and packet integrity protocol to the ALC and NORM
   content delivery protocols.  Since the FLUTE application [RFC3926] is



Roca, et al.            Expires September 3, 2007               [Page 4]

Internet-Draft            TESLA in ALC and NORM               March 2007


   built on top of ALC, it will directly benefit from the services
   offered by TESLA at the transport layer.

   This specification only considers the authentication/integrity of the
   packets generated by the session's sender.  This specification does
   not consider the packets that will be generated by receivers, for
   instance the feedback packets of NORM.  Adding authentication/
   integrity to the packets sent by receivers is outside the scope of
   this document.  Of course, this remark does not apply to ALC where
   transmissions are purely unidirectional.

   For more information on the TESLA protocol and its principles, please
   refer to [RFC4082][Perrig04].  For more information on ALC, NORM and
   FLUTE, please refer to [draft-ietf-rmt-pi-alc-revised],
   [draft-ietf-rmt-bb-lct-revised], [draft-ietf-rmt-pi-norm-revised] and
   [RFC3926].

1.1.  Conventions Used in this Document

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

1.2.  Terminology and Notations

   The following notations and definitions are used throughout this
   document:

   o  PRF is the Pseudo Random Function;

   o  MAC is the Message Authentication Code;

   o  HMAC is the Keyed-Hash Message Authentication Code;

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

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

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

   o  T_int, the interval duration (in milliseconds);

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

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




Roca, et al.            Expires September 3, 2007               [Page 5]

Internet-Draft            TESLA in ALC and NORM               March 2007


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

   o  D^0_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'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;

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

   o  N_tx_old_kck is the number of intervals during which the last key
      of the old key chain SHOULD be sent, after switching to a new key
      chain and waiting for the disclosure delay d;

   o  N_tx_new_kcc is the number of intervals during which the
      commitment to a new key chain SHOULD be sent, before switching to
      the new key chain;



























Roca, et al.            Expires September 3, 2007               [Page 6]

Internet-Draft            TESLA in ALC and NORM               March 2007


2.  Using TESLA with ALC and NORM

2.1.  ALC and NORM Specificities that Impact TESLA

   The ALC and NORM protocols have features and requirements that
   largely impact the way TESLA can be used.

   In case of ALC:

   o  ALC is massively scalable: nothing in the protocol specification
      limits the number of receivers that join 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 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: with some use cases a
      session can last several 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
   ALC can be used for small groups.

   In case of NORM:

   o  NORM has been designed for limited or 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 rate channel since only low to medium
      rate control traffic will flow on it.  Networks with an asymmetric
      connectivity (e.g. a high rate satellite downlink and a low-rate
      RTC based return channel) are appropriate;






Roca, et al.            Expires September 3, 2007               [Page 7]

Internet-Draft            TESLA in ALC and NORM               March 2007


2.2.  The Need for Secure Time Synchronization

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

   o  direct time synchronization, and

   o  indirect time synchronization.

2.2.1.  Direct Time Synchronization

   When direct time synchronization is used, each receiver asks the
   sender for a time synchronization.  To that purpose, a receiver sends
   a "Direct Time Synchronization Request" (Section 5.1.3).  The sender
   then directly answers to each request with a "Direct Time
   Synchronization Response" (Section 4.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 3.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.

   Direct time synchronization is not be an issue with NORM since (1)
   bidirectional communications already take place, and (2) NORM
   scalability is anyway limited.

   But direct time synchronization is potentially incompatible with ALC
   since (1) there might not be a back channel to the session's sender,
   and (2) there are potentially a huge number of receivers and
   therefore a risk that the sender collapses.

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



Roca, et al.            Expires September 3, 2007               [Page 8]

Internet-Draft            TESLA in ALC and NORM               March 2007


      authenticate each NTP message individually.  It prevents for
      instance an attacker to impersonate a NTP server;

   o  similarly sender and receivers can synchronize through a NTPv4
      (Network Time Protocol version 4) [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  similarly, 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 provide a high precision time reference.  This time
      reference is in general trusted, yet depending on the use case,
      this trust will or not be acceptable;

   o  they can synchronize thanks to a dedicated hardware, embedded on
      each sender and receiver, that offers a clock with a time-drift
      that is negligible in front of the TESLA time accuracy
      requirements.  This feature enables a device to synchronize its
      embedded clock with the official time reference from time to time,
      when feasible (in an extreme case once, at manufacturing time),
      and then to remain autonomous for some time, depending on the
      known maximum clock drift.

   A bidirectional channel is required by the NTP/SNTP schemes.  On the
   opposite, with the GPS/Galileo and high precision clock schemes, no
   such assumption is made.  In situations where ALC is used on purely
   unidirectional transport channels (Section 2.1), using the NTP/SNTP
   schemes is not possible.  Another aspect is the scalability
   requirement of ALC, and to a lesser extent 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 is a good candidate, in particular with
   ALC.

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









Roca, et al.            Expires September 3, 2007               [Page 9]

Internet-Draft            TESLA in ALC and NORM               March 2007


3.  Time Synchronization and Delay Bound Calculations

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

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

   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.

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

3.2.1.  Single time reference

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

   o  The sender uses a direct time synchronization scheme (but not
      necessarily the one specified in Section 3.1, see below) to
      calculate D^0_t, the upper bound of the lag of the sender's clock
      with respect to the time reference.  This D^0_t value is
      communicated to receivers within the Bootstrap Information
      (Section 4.3.1).

   o  Similarly, a receiver R uses a direct time synchronization scheme
      (same remark) to calculate D^R_t, the upper bound of the lag of
      the receiver's clock with respect to the time reference.





Roca, et al.            Expires September 3, 2007              [Page 10]

Internet-Draft            TESLA in ALC and NORM               March 2007


   o  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^0_t + D^R_t.

   The way to calculate D^0_t and D^R_t depends on the time
   synchronization mechanism used (Section 2.2.2).  In some cases, it is
   part of the time synchronization scheme specifications.  In other
   cases, it can be achieved by using the direct time synchronization
   scheme of Section 3.1, for instance in case synchronization is
   achieved via a group controller [RFC4082].

3.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^0_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^0_t
   + D^R_t + D_err.

   In some cases, the D_t value is 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.

      ----- Editor's note: is this D_t = security_factor * (1ms + 1ms)
      rule of thumb acceptable? -----


















Roca, et al.            Expires September 3, 2007              [Page 11]

Internet-Draft            TESLA in ALC and NORM               March 2007


4.  Sender Operations

4.1.  TESLA Parameters

4.1.1.  Key Chains

   The sender divides the time into uniform intervals of duration T_int.
   The sender then computes a one-way key chain of N keys, and assigns
   one key from the chain to each interval in sequence.  In order to
   compute this chain, he must first select a Primary Key, K_N, and a
   PRF function, f.  The functions F and F' are then 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, 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 [Perrig04].

   To do so, the sender commits the new key chain with the old key
   chain.  Let's say that the old key chain stops at K_N and the new key
   chain starts at K_{N+1}.  Then the sender includes the commitment
   F(K_{N+1}) to the new key chain to packets authenticated with the old
   key chain.  This commitment SHOULD be sent during N_tx_new_kcc
   intervals before the end of the old key chain.  Since several packets
   are usually sent during a interval, the sender should alternate
   between sending a disclosed key of the old key chain, and the
   commitment to the new key chain.

   The receiver will keep the commitment, until the key K_{N+1} is
   disclosed, at interval N+1+d.  Then the receiver will be able to test
   the validity of that key by computing F(K_{N+1}) and comparing it to
   the commitment.

   When the key chain is changed, it becomes impossible to recover a
   previous key from the old key chain.  This is a problem if the
   receiver lost the packets disclosing the last key of the old key
   chain.  A solution consists in re-sending the last key, K_N, of the
   old key chain.  This SHOULD be done during N_tx_old_kck intervals at
   the beginning of the new key chain, after the disclosure delay d.
   Since several packets are usually sent during a interval, the sender
   should alternate between sending a disclosed key of the new key
   chain, and the last key of the old key chain.




Roca, et al.            Expires September 3, 2007              [Page 12]

Internet-Draft            TESLA in ALC and NORM               March 2007


   In some cases a receiver having experienced a very long disconnection
   might have lost the commitment of the new chain.  Therefore this
   receiver will be unable to authenticate any packet related to the new
   chain and all the following ones.  The solution for this receiver to
   catch up consists in receiving the bootstrap information.  This can
   happen by waiting for the next periodic transmission (indirect time
   synchronization), by requesting it (direct time synchronization), or
   through an external mechanism (Section 4.2.1).

4.1.2.  Time Interval Schedule

   The sender must determine the following parameters:

   o  T_0, the start time corresponding to the beginning of the session;

   o  T_int, the interval duration, usually ranging from 100
      milliseconds to 1 second;

   o  d, the key disclosure delay (in number of intervals).  It is the
      time to wait before disclosing a key;

   o  N, the number of keys in a key chain;

   The correct choice of T_int, d, and N is crucial for the usability of
   the scheme.  For instance, a T_int * d product that is too long will
   cause excessive delay in the authentication process.  A T_int * d
   product that is is too short will cause too many packets to be
   unverifiable by some receivers.  A N * T_int product that is too
   small will cause the sender to switch too often to new key chains.  A
   N that is too long with respect to the expected session duration, if
   this latter is known, will require the sender to compute too many
   keys without using them all.  [RFC4082] (sections 3.2 and 3.6) gives
   general guidelines for initializing these parameters.

4.2.  TESLA Messages and Authentication Tags

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

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

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







Roca, et al.            Expires September 3, 2007              [Page 13]

Internet-Draft            TESLA in ALC and NORM               March 2007


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

   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.

   Afterwards, 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 true when several key chains are used in an ALC or
      NORM session, since there is a risk that some 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.

   In some use cases, the bootstrapping information MAY be sent to
   receivers through an external mechanism, for instance in a way
   similar to [RFC4442].  How to do that is outside the scope of this
   document.




Roca, et al.            Expires September 3, 2007              [Page 14]

Internet-Draft            TESLA in ALC and NORM               March 2007


4.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 3.1).  This message
   is unicast to the receiver.  This Direct Time Synchronization
   Response message MUST be securely transmitted, in particular the
   receiver must be able to check the packet source and the packet
   integrity using standard protocols.  Any digital signature will do.
   The receiver MUST also be able the associate this response and his
   request, which is the reason why t_r is included in the message.

   The Direct Time Synchronization Response messages are distinct from
   the Bootstrap Information message.  Therefore, if a large number of
   receivers try to initialize their TESLA component at the same time (a
   reasonable assumption in "push" mode), a single Bootstrap Information
   message can be broadcast to all of them.  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
   after 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 indirect mode.

4.2.3.  Authentication Tag

   Every authenticated packet must have an authentication tag
   containing:

   o  the index of the interval (which is also the index of the key used
      for computing the MAC of this packet: i;

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

   o  and either a disclosed key or a commitment to a new key chain.

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

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




Roca, et al.            Expires September 3, 2007              [Page 15]

Internet-Draft            TESLA in ALC and NORM               March 2007


4.3.1.  Bootstrap Information 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     |A|B| # Cert|             T_int             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       d       |    PRF Type   | HMAC Func Type| Signature Type|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          Key length           |      Signature Length         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                              T_0                              +
    |                         (NTP timestamp)                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                  N (Number of Keys in chain)                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                   i (Interval Index of K_i)                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    ~                              K_i              +-+-+-+-+-+-+-+-+
    |                                               |   Padding     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    ~                     Signature Extension                       ~
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |P|                                                             |
    +-+       D^0_t Extension (optional, present if A==1)           +
    |    (NTP timestamp diff, positive if P==1, negative if p==0)   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    ~          NTP Extension (optional, present if B==1)            ~
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 1: Bootstrap information format.

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

   "Reserved" field (10 bits):

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

   "A" flag (1 bit):



Roca, et al.            Expires September 3, 2007              [Page 16]

Internet-Draft            TESLA in ALC and NORM               March 2007


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

   "B" flag (1 bit):

      B==0 indicates that the NTP extension is not present.  B==1
      indicates that the NTP extension is present.

   "# Cert."  (Number of Certificates) field (8 bits):

      The "Number of Certificates" indicates the number of certificates
      present in the signature extension.

   "T_int" field (8 bits):

      T_int is an unsigned integer that defines the interval duration
      (in milliseconds).

   "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
      (Appendix A).

   "HMAC Function Type" field (8 bits):

      The "HMAC Function Type" is the reference number of the function
      used to compute the HMAC of the packets (Appendix A).

   "Signature Type" field (8 bits):

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

   "Key Length" field (16 bits):

      The "Key length" is an unsigned integer that indicates the length
      in bits of key K_i.

   "Signature Length" field (16 bits):




Roca, et al.            Expires September 3, 2007              [Page 17]

Internet-Draft            TESLA in ALC and NORM               March 2007


      The "Signature Length" is an unsigned integer that indicates the
      signature field size in bytes in the "Signature Extension" field.
      This is NOT the total length of the "Signature Extension" field.

   "T_0" field (8 bits):

      "T_0" is an NTP timestamp that indicates the time when this
      session begun.

   "N" field (8 bits):

      "N" is an unsigned integer that indicates the number of keys in
      the current key chain.

   "i" (Interval Index of K_i) field (8 bits):

      "i" is an unsigned integer that indicates the interval index
      associated to the key disclosed in this bootstrap information,
      K_i.  For performance reasons, the sender SHOULD always send a
      bootstrap information with the highest possible index i since this
      will reduce the required computation needed to validate key K_j
      with j > i.  But using interval O and K_0 remains valid.  In any
      case, if j is the current interval index, then it is REQUIRED that
      i < j - d.

   "K_i" field (variable size):

      "K_i" is the key corresponding to interval i.  If j is the current
      interval index, then it is REQUIRED that i < j - d.

   "Signature Extension" (variable size):

      The "Signature Extension" is mandatory.  It is described in
      Section 4.3.1.1.  It's format depends on the "# of certificates"
      field, and the total length of this extension is given by
      "Signature length".

   "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^0_t NTP timestamp difference is positive (P==1) or
      negative (P==0).

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






Roca, et al.            Expires September 3, 2007              [Page 18]

Internet-Draft            TESLA in ALC and NORM               March 2007


      The "D^0_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^0_t is the maximum upper bound of the
      lag with each time reference.  D^0_t is composed of two unsigned
      integers, as with NTP timestamps: the first 31 bits give the time
      difference in seconds (the MSB is used by the P flag), and the
      remaining 32 bits give the sub-second time difference.

         ----- Editor's note: a first alternative would be to use
         floating point arithmetic, IEEE754 for carrying D^0_t.  NTP
         timestamp difference is usually performed with double floating
         point arithmetic internally (at least in TESLA and NTPv4), so
         it makes sense.  A second alternative would be to use a signed
         integer representing the difference in sub-second units (e.g.
         in milliseconds).  This is simple but it requires NTP
         timestamp/ms conversions on both sides.  The use of the "P"
         flag seems simpler... -----

   "NTP Extension" (optional, variable size):

      The "NTP extension" is optional (controlled by the B flag).  It is
      only used in indirect time synchronization mode with (S)NTP
      synchronization.  This extension is described in Section 4.3.1.2.

   Note that the first seven 32-bit words are mandatory fixed length
   fields.  The K_i and Signature Extension fields are mandatory but
   variable length fields.  The remaining D^0_t and NTP Extension fields
   are only present in indirect synchronization mode.

4.3.1.1.  Signature Extension Format

   The Signature Extension format can be deduced from the "# Cert" and
   "Signature Length" field of the Bootstrapping Information generic
   part.  Note that "Signature Length" only refers to the "Signature"
   field and DOES NOT include the various certificates.














Roca, et al.            Expires September 3, 2007              [Page 19]

Internet-Draft            TESLA in ALC and NORM               March 2007


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

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

            Figure 2: Signature extension format when #cert==2.

   In Figure 2:

   "Cert Type" (8 bits):

      The type of certificate identifies the algorithm used for the
      certificate (see Appendix A).

   "Cert Length" (8 bits):

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

   "Certificate" field (variable size):

      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.

   "Signature" field (variable size):

      The signature field contains 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.



Roca, et al.            Expires September 3, 2007              [Page 20]

Internet-Draft            TESLA in ALC and NORM               March 2007


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

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

            Figure 3: Signature extension format when #cert==0.

4.3.1.2.  NTP Extension Format

   In some use cases, when NTP or SNTP is used in indirect time
   synchronization mode, the session's sender must have a way to
   indicate to receivers one or more NTP server that will act as time
   reference (Section 5.1.2).
































Roca, et al.            Expires September 3, 2007              [Page 21]

Internet-Draft            TESLA in ALC and NORM               March 2007


     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Total Length  | # of Entries  |  Reserved (0) |   Cert Type   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | FQDN 1 Length | Cert 1 Length |                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
    |                                                               |
    ~                  NTP Server 1 FQDN            +-+-+-+-+-+-+-+-+
    |                                               |   Padding     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    ~               NTP Certificate 1 (optional)    +-+-+-+-+-+-+-+-+
    |                                               |   Padding     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | FQDN 2 Length | Cert 2 Length |                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
    |                                                               |
    ~                  NTP Server 2 FQDN            +-+-+-+-+-+-+-+-+
    |                                               |   Padding     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    ~               NTP Certificate 2 (optional)    +-+-+-+-+-+-+-+-+
    |                                               |   Padding     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Figure 4: Optional NTP information format, when two NTP servers are
                                 specified

   Figure 4 shows the optional NTP information format, when two NTP
   servers are specified:

   "Total Length" field (8 bits):

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

   "# of Entries" field (8 bits):

      The number of entries is the number of NTP entries.

   "Cert Type" field (8 bits):

      The type of certificates identifies the algorithm used for all the
      certificates that are provided in this NTP Extension (see
      Appendix A).

   "FQDN Length" field (8 bits):



Roca, et al.            Expires September 3, 2007              [Page 22]

Internet-Draft            TESLA in ALC and NORM               March 2007


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

   "Cert Length" field (8 bits):

      The certificate length is the length in bytes of the (optional)
      NTP certificate field.

   "NTP Server FQDN" field (variable length):

      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.

   "NTP Certificate" field (optional, variable size):

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

      ----- Editor's note: Providing only NTP Server FQDN is perhaps too
      limitative.  It should be possible to use either a FQDN or an
      IPv4/IPv6 address. -----

4.3.2.  Format of a Direct Time Synchronization Response

























Roca, et al.            Expires September 3, 2007              [Page 23]

Internet-Draft            TESLA in ALC and NORM               March 2007


     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                     t_s (NTP timestamp)                       +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                     t_r (NTP timestamp)                       +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Rsvd  | # Cert| Signature Type|       Signature Length        |
    +-------+-------------------------------------------------------+
    |                                                               |
    ~                     Signature extension                       ~
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Figure 5: Format of a Direct Time Synchronization Response

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

   "Rsvd" (Reserved) field (4 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;

   "# Cert."  (Number of Certificates) field (8 bits):

      The Number of Certificates indicates the number of certificates
      present in the signature extension.

   "Signature Type" field (8 bits):






Roca, et al.            Expires September 3, 2007              [Page 24]

Internet-Draft            TESLA in ALC and NORM               March 2007


      The Signature Type is the reference number (Appendix A) of the
      digital signature used to authenticate this message and included
      in the "Signature Extension" field.

   "Signature Length" field (16 bits):

      Signature length is an unsigned integer that indicates the
      signature field size in bytes in the "Signature Extension" field.
      This is NOT the total length of the "Signature Extension" field.

   "Signature Extension" (variable size):

      The signature extension is described in Section 4.3.1.1.  It's
      format depends on the "# of certificates" field, and the total
      length of this extension is given by "Signature length".

4.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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |             i (Interval Index of K'_i)  (optional)            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    ~                    Disclosed Key K_{i-d}      +-+-+-+-+-+-+-+-+
    |                                               |   Padding     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    ~                       MAC(K'_i, M)            +-+-+-+-+-+-+-+-+
    |                                               |   Padding     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 6: Format of the authentication tag

   Figure 6 shows the format of the authentication tag:

   "i" optional field (32 bits):

      i is the interval index associated to the key (K'_i) used to
      compute the MAC of this packet.  This field is optional.  It is
      included if the "I" field within the TESLA EXT_AUTH header
      extension is 1, and not included if the "I" field is 0.

   "Disclosed Key" (variable size):






Roca, et al.            Expires September 3, 2007              [Page 25]

Internet-Draft            TESLA in ALC and NORM               March 2007


      The "Disclosed Key" is the key used for interval i-d: K_{i-d};

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

      MAC(K'_i, M) is the message authentication code of the current
      packet, including the ALC or NORM header (with the header
      extensions if any) and the payload (when applicable).

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

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


     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 (Interval Index of K'_i)  (optional)            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    ~              New Key Commitment F(K_{N+1})    +-+-+-+-+-+-+-+-+
    |                                               |   Padding     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    ~                       MAC(K'_i, M)            +-+-+-+-+-+-+-+-+
    |                                               |   Padding     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

4.3.5.  Format of an Authentication Tag with an Old Chain Last Key
        Disclosure

   During the first N_tx_old_kck intervals of the new key chain after
   the disclosing interval, d, the sender MUST send a commitment to the
   old key chain.  This is done by replacing the disclosed key of the
   authentication tag with the last key of the old chain.  Figure 8
   shows the corresponding format.









Roca, et al.            Expires September 3, 2007              [Page 26]

Internet-Draft            TESLA in ALC and NORM               March 2007


     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 (Interval Index of K'_i)  (optional)            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    ~                  Last Key of Old Chain, K_N   +-+-+-+-+-+-+-+-+
    |                                               |   Padding     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    ~                       MAC(K'_i, M)            +-+-+-+-+-+-+-+-+
    |                                               |   Padding     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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



































Roca, et al.            Expires September 3, 2007              [Page 27]

Internet-Draft            TESLA in ALC and NORM               March 2007


5.  Receiver Operations

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

5.1.1.  Processing the Bootstrap Information Message

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

   Before TESLA has been initialized, a receiver MUST ignore all packets
   other than the bootstrap information message.  Yet, a receiver MAY
   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).

5.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 acceptable in the same
   session.






Roca, et al.            Expires September 3, 2007              [Page 28]

Internet-Draft            TESLA in ALC and NORM               March 2007


5.1.2.1.  Direct Time Synchronization

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

5.1.2.2.  Indirect Time Synchronization

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

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

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

5.1.3.  Format of a Direct Time Synchronization Request


     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                     t_r (NTP timestamp)                       +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         Figure 9: Format of a Direct Time Synchronization Request

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




Roca, et al.            Expires September 3, 2007              [Page 29]

Internet-Draft            TESLA in ALC and NORM               March 2007


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

5.2.  Authentication of Received Packets

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

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

   2.  Then proceed with the TESLA safe test: (1) check that the key
       used to compute the MAC of this packet has not already been
       disclosed, and (2) check the disclosed key by computing the
       necessary number of PRF functions to obtain a previously safe
       disclosed key.  If any of these two tests fail, the receiver MUST
       reject the packet.

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

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

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

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

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

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



Roca, et al.            Expires September 3, 2007              [Page 30]

Internet-Draft            TESLA in ALC and NORM               March 2007


6.  Integration in the ALC and NORM Protocols

6.1.  Authentication Header Extension Format

   The integration of TESLA in ALC or NORM is similar and relies on the
   header extension mechanism defined in both protocols.  More precisely
   we further specify the EXT_AUTH=1 header extension defined in
   [draft-ietf-rmt-bb-lct-revised].

      ----- Editor's note: All authentication schemes using the EXT_AUTH
      header extension MUST reserve the same 4 bit "Scheme" field after
      the HET/HEL fields.  This way, several authentication schemes can
      be used in the same ALC or NORM session.  For instance, in case of
      NORM, TESLA can be used for the downstream traffic while another
      scheme is used for the upstream traffic. -----

   Several fields are added in addition to the HET (Header Extension
   Type) and HEL (Header Extension Length) fields (Figure 10).


     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   HET (=1)    |      HEL      |Scheme |   V   |I| Resvd |Type |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    ~                                                               ~
    |                            Content                            |
    ~                                                               ~
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         Figure 10: Format of the TESLA EXT_AUTH header extension.

   The fields of the TESLA EXT_AUTH header extension are:

   "Scheme ID" (Authentication Scheme Identifier) field (4 bits):

      The "Scheme ID" identifies the source authentication scheme or
      protocol in use.  The value 0 is reserved for TESLA.

   "V" (Version) field (4 bits):

      "Version" identifies the version number of the TESLA
      authentication scheme.  The value 0 is reserved for the current
      specification of TESLA.

   "Resvd" (Reserved) field (5 bits):



Roca, et al.            Expires September 3, 2007              [Page 31]

Internet-Draft            TESLA in ALC and NORM               March 2007


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

   "I" (Interval Index Present) field (1 bit):

      The "Interval Index Present" field indicates whether the "Interval
      Index" field is present (I=1) or not (I=0) in the three
      authentication information messages (see Section 4.3.3 for Type=1,
      see Section 4.3.4 for Type=2, see Section 4.3.5> for Type=3).
      This "I" field MUST be set to zero in all other types.

   "Type" field (3 bits):

      The "Type" field identifies the type of TESLA information carried
      in this header extension.  This specification defines the
      following types:

      *  0: bootstrap information, sent by the sender periodically or
         after a direct time synchronization request;

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

      *  2: authentication tag with a new key chain commitment, sent by
         the sender when approaching the end of a key chain;

      *  3: authentication tag with an old chain last key disclosure,
         sent by the sender some time after moving to a new key chain;

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

      *  5: 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, multiple of 32 bits):

      This is the TESLA information carried in the header extension,
      whose type is given by the "Type" field.




Roca, et al.            Expires September 3, 2007              [Page 32]

Internet-Draft            TESLA in ALC and NORM               March 2007


   All receivers MUST recognize EXT_AUTH but MAY NOT be able to parse
   its content, for instance because they do not include the TESLA
   building block.  In that case these receivers MUST ignore the
   EXT_AUTH extensions.  In case of NORM, the packets sent by receivers
   MAY contain a direct synchronization request but MUST NOT contain any
   of the other four TESLA EXT_AUTH header extensions.

6.2.  Use of Authentication Header Extensions

   Each packet sent by the session's sender MUST contain exactly one
   TESLA EXT_AUTH header extension.

6.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 NORM, the "bootstrap information" TESLA EXT_AUTH MUST be sent in
   a NORM_INFO message.

   With ALC, the "bootstrap information" TESLA EXT_AUTH MUST be sent in
   a control packet, i.e. containing no encoding symbol.

6.2.2.  EXT_AUTH Header Extension of Type Bootstrap Information

   The three "authentication information" TESLA EXT_AUTH (Type=1, 2, or
   3) MUST be attached to the ALC or NORM packet (data or control
   packet) that they protect.  Depending on the "I" field, two
   possibilities exist for each of these three messages.


















Roca, et al.            Expires September 3, 2007              [Page 33]

Internet-Draft            TESLA in ALC and NORM               March 2007


     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   HET (=1)    |      HEL      |Scheme |   V   |1|   0   |  1  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |             i (Interval Index of K'_i)                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    ~                    Disclosed Key K_{i-d}      +-+-+-+-+-+-+-+-+
    |                                               |   Padding     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    ~                       MAC(K'_i, M)            +-+-+-+-+-+-+-+-+
    |                                               |   Padding     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 11: Format of the authentication information with the Interval
                            Index field (I=1).


     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   HET (=1)    |      HEL      |Scheme |   V   |0|   0   |  1  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    ~                    Disclosed Key K_{i-d}      +-+-+-+-+-+-+-+-+
    |                                               |   Padding     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    ~                       MAC(K'_i, M)            +-+-+-+-+-+-+-+-+
    |                                               |   Padding     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 12: Format of the authentication information without the
                        Interval Index field (I=0).

   Figure 11 and Figure 12 show the format of the authentication tag
   respectively with(without) the Interval Index field.

6.2.3.  EXT_AUTH Header Extension of Type Direct Time Synchronization
        Request

   With NORM, the direct time synchronization request TESLA EXT_AUTH
   (Type=4) is sent by a receiver in a (TBD) NORM packet (see editor's
   note below).  There is no authentication information header extension
   in this case since this draft only considers the authentication/
   integrity of the packets generated by the session's sender.



Roca, et al.            Expires September 3, 2007              [Page 34]

Internet-Draft            TESLA in ALC and NORM               March 2007


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

   With ALC, the direct time synchronization request information cannot
   be included in an ALC packet, since ALC is restricted to
   unidirectional transmissions, from the session's sender to the
   receivers.  An external mechanism, out of the scope of this document,
   must be used with ALC for carrying direct time synchronization
   requests to the session's sender.

6.2.4.  EXT_AUTH Header Extension of Type Direct Time Synchronization
        Response

   With NORM, the "direct time synchronization response" TESLA EXT_AUTH
   MUST be sent in a NORM_INFO message.

   With ALC, the "direct time synchronization response" TESLA EXT_AUTH
   MUST be sent in a control packet, i.e. containing no encoding symbol.

6.3.  Managing Silent Periods

   An ALC or NORM sender may stop transmitting packet for some time, for
   various reasons.  It can be the end of the session and all packets
   have already been sent, 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 revealed, which can only take place after d
   additional intervals.

   To resolve this boundary problem, the session's sender MUST sent null
   packets containing the TESLA EXT_AUTH header extension along with the
   authentication information (Type=1) for at least d intervals after
   the end of the regular ALC or NORM packet transmissions.  The
   transmission frequency of these null packets must be sufficient to
   guaranty that each receiver receives at least that containing the
   last key with a sufficiently high probability.














Roca, et al.            Expires September 3, 2007              [Page 35]

Internet-Draft            TESLA in ALC and NORM               March 2007


7.  Security Considerations

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














































Roca, et al.            Expires September 3, 2007              [Page 36]

Internet-Draft            TESLA in ALC and NORM               March 2007


8.  Acknowledgments

   The authors are grateful to Ran Canetti and David L. Mills for their
   valuable comments when preparing this document.















































Roca, et al.            Expires September 3, 2007              [Page 37]

Internet-Draft            TESLA in ALC and NORM               March 2007


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.

   [RFC3926]  Paila, T., Luby, M., Lehtonen, R., Roca, V., and R. Walsh,
              "FLUTE - File Delivery over Unidirectional Transport",
              RFC 3926, October 2004.

   [RFC4082]  Perrig, A., Song, D., Canetti, R., Tygar, J., and B.
              Briscoe, "Timed Efficient Stream Loss-Tolerant
              Authentication (TESLA): Multicast Source Authentication
              Transform Introduction", RFC 4082, June 2005.

   [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-05.txt (work in progress),
              February 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-04.txt (work in progress),
              February 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-03.txt (work in progress),
              September 2006.

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.

   [RFC4330]  Mills, D., "Simple Network Time Protocol (SNTP) Version 4
              for IPv4, IPv6 and OSI", RFC 4330, January 2006.




Roca, et al.            Expires September 3, 2007              [Page 38]

Internet-Draft            TESLA in ALC and NORM               March 2007


   [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., "The Network Time Protocol Version 4 Protocol
              Specification", draft-ietf-ntp-ntpv4-proto-01.txt (work in
              progress), October 2005.











































Roca, et al.            Expires September 3, 2007              [Page 39]

Internet-Draft            TESLA in ALC and NORM               March 2007


Appendix A.  IANA Considerations

   This document requires an IANA registration for the following
   attributes:

   Cryptographic pseudo-random function, TESLA-PRF:

                     The currently defined values are:

                         +--------------+-------+
                         | PRF function | Value |
                         +--------------+-------+
                         |   HMAC-SHA1  |   0   |
                         |              |       |
                         |  HMAC-SHA256 |   1   |
                         +--------------+-------+

   Cryptographic message authentication code (MAC):

                     The currently defined values are:

                         +--------------+-------+
                         | MAC function | Value |
                         +--------------+-------+
                         |   HMAC-SHA1  |   0   |
                         |              |       |
                         |  HMAC-SHA256 |   1   |
                         +--------------+-------+

   Signature type:

                     The currently defined values are:

              +------------------------------------+-------+
              |           Signature type           | Value |
              +------------------------------------+-------+
              | PKCS #1: RSA Cryptography Standard |   0   |
              +------------------------------------+-------+

   Certificate type:

                     The currently defined values are:

              +------------------------------------+-------+
              |          Certificate type          | Value |
              +------------------------------------+-------+
              | PKCS #1: RSA Cryptography Standard |   0   |
              +------------------------------------+-------+



Roca, et al.            Expires September 3, 2007              [Page 40]

Internet-Draft            TESLA in ALC and NORM               March 2007


Authors' Addresses

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

   Email: vincent.roca@inrialpes.fr
   URI:   http://planete.inrialpes.fr/~roca/


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

   Email: aurelien.francillon@inrialpes.fr
   URI:   http://planete.inrialpes.fr/~francill/


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

   Email: faurite@lcpc.fr



















Roca, et al.            Expires September 3, 2007              [Page 41]

Internet-Draft            TESLA in ALC and NORM               March 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   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 September 3, 2007              [Page 42]


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