tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 5776

 Errata 
Experimental
Pages: 58
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: MSEC

Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols

Part 1 of 3, p. 1 to 16
None       Next RFC Part

 


Top       ToC       Page 1 
Internet Engineering Task Force (IETF)                           V. Roca
Request for Comments: 5776                                 A. Francillon
Category: Experimental                                        S. Faurite
ISSN: 2070-1721                                                    INRIA
                                                              April 2010

 Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in
               the Asynchronous Layered Coding (ALC) and
           NACK-Oriented Reliable Multicast (NORM) Protocols

Abstract

   This document details the Timed Efficient Stream Loss-Tolerant
   Authentication (TESLA) packet source authentication and packet
   integrity verification protocol and its integration within the
   Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable
   Multicast (NORM) content delivery protocols.  This document only
   considers the authentication/integrity verification of the packets
   generated by the session's sender.  The authentication and integrity
   verification of the packets sent by receivers, if any, is out of the
   scope of this document.

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for examination, experimental implementation, and
   evaluation.

   This document defines an Experimental Protocol for the Internet
   community.  This document is a product of the Internet Engineering
   Task Force (IETF).  It represents the consensus of the IETF
   community.  It has received public review and has been approved for
   publication by the Internet Engineering Steering Group (IESG).  Not
   all documents approved by the IESG are a candidate for any level of
   Internet Standard; see Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc5776.

Page 2 
Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Top       Page 3 
Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
     1.1.  Scope of This Document . . . . . . . . . . . . . . . . . .  6
     1.2.  Conventions Used in This Document  . . . . . . . . . . . .  7
     1.3.  Terminology and Notations  . . . . . . . . . . . . . . . .  7
       1.3.1.  Notations and Definitions Related to Cryptographic
               Functions  . . . . . . . . . . . . . . . . . . . . . .  7
       1.3.2.  Notations and Definitions Related to Time  . . . . . .  8
   2.  Using TESLA with ALC and NORM: General Operations  . . . . . .  9
     2.1.  ALC and NORM Specificities That Impact TESLA . . . . . . .  9
     2.2.  Bootstrapping TESLA  . . . . . . . . . . . . . . . . . . . 10
       2.2.1.  Bootstrapping TESLA with an Out-Of-Band Mechanism  . . 10
       2.2.2.  Bootstrapping TESLA with an In-Band Mechanism  . . . . 11
     2.3.  Setting Up a Secure Time Synchronization . . . . . . . . . 11
       2.3.1.  Direct Time Synchronization  . . . . . . . . . . . . . 12
       2.3.2.  Indirect Time Synchronization  . . . . . . . . . . . . 12
     2.4.  Determining the Delay Bounds . . . . . . . . . . . . . . . 13
       2.4.1.  Delay Bound Calculation in Direct Time
               Synchronization Mode . . . . . . . . . . . . . . . . . 14
       2.4.2.  Delay Bound Calculation in Indirect Time
               Synchronization Mode . . . . . . . . . . . . . . . . . 14
     2.5.  Cryptographic Parameter Values . . . . . . . . . . . . . . 15
   3.  Sender Operations  . . . . . . . . . . . . . . . . . . . . . . 16
     3.1.  TESLA Parameters . . . . . . . . . . . . . . . . . . . . . 16
       3.1.1.  Time Intervals . . . . . . . . . . . . . . . . . . . . 16
       3.1.2.  Key Chains . . . . . . . . . . . . . . . . . . . . . . 16
       3.1.3.  Time Interval Schedule . . . . . . . . . . . . . . . . 20
       3.1.4.  Timing Parameters  . . . . . . . . . . . . . . . . . . 20
     3.2.  TESLA Signaling Messages . . . . . . . . . . . . . . . . . 21
       3.2.1.  Bootstrap Information  . . . . . . . . . . . . . . . . 21
       3.2.2.  Direct Time Synchronization Response . . . . . . . . . 22
     3.3.  TESLA Authentication Information . . . . . . . . . . . . . 22
       3.3.1.  Authentication Tags  . . . . . . . . . . . . . . . . . 23
       3.3.2.  Digital Signatures . . . . . . . . . . . . . . . . . . 23
       3.3.3.  Group MAC Tags . . . . . . . . . . . . . . . . . . . . 24
     3.4.  Format of TESLA Messages and Authentication Tags . . . . . 25
       3.4.1.  Format of a Bootstrap Information Message  . . . . . . 26
       3.4.2.  Format of a Direct Time Synchronization Response . . . 31
       3.4.3.  Format of a Standard Authentication Tag  . . . . . . . 32
       3.4.4.  Format of an Authentication Tag without Key
               Disclosure . . . . . . . . . . . . . . . . . . . . . . 33
       3.4.5.  Format of an Authentication Tag with a "New Key
               Chain" Commitment  . . . . . . . . . . . . . . . . . . 34
       3.4.6.  Format of an Authentication Tag with a "Last Key
               of Old Chain" Disclosure . . . . . . . . . . . . . . . 35
   4.  Receiver Operations  . . . . . . . . . . . . . . . . . . . . . 36
     4.1.  Verification of the Authentication Information . . . . . . 36

Top      ToC       Page 4 
       4.1.1.  Processing the Group MAC Tag . . . . . . . . . . . . . 36
       4.1.2.  Processing the Digital Signature . . . . . . . . . . . 37
       4.1.3.  Processing the Authentication Tag  . . . . . . . . . . 37
     4.2.  Initialization of a Receiver . . . . . . . . . . . . . . . 38
       4.2.1.  Processing the Bootstrap Information Message . . . . . 38
       4.2.2.  Performing Time Synchronization  . . . . . . . . . . . 38
     4.3.  Authentication of Received Packets . . . . . . . . . . . . 40
       4.3.1.  Discarding Unnecessary Packets Earlier . . . . . . . . 43
     4.4.  Flushing the Non-Authenticated Packets of a Previous
           Key Chain  . . . . . . . . . . . . . . . . . . . . . . . . 43
   5.  Integration in the ALC and NORM Protocols  . . . . . . . . . . 44
     5.1.  Authentication Header Extension Format . . . . . . . . . . 44
     5.2.  Use of Authentication Header Extensions  . . . . . . . . . 45
       5.2.1.  EXT_AUTH Header Extension of Type Bootstrap
               Information  . . . . . . . . . . . . . . . . . . . . . 45
       5.2.2.  EXT_AUTH Header Extension of Type Authentication
               Tag  . . . . . . . . . . . . . . . . . . . . . . . . . 48
       5.2.3.  EXT_AUTH Header Extension of Type Direct Time
               Synchronization Request  . . . . . . . . . . . . . . . 49
       5.2.4.  EXT_AUTH Header Extension of Type Direct Time
               Synchronization Response . . . . . . . . . . . . . . . 49
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 50
     6.1.  Dealing with DoS Attacks . . . . . . . . . . . . . . . . . 50
     6.2.  Dealing With Replay Attacks  . . . . . . . . . . . . . . . 51
       6.2.1.  Impacts of Replay Attacks on TESLA . . . . . . . . . . 51
       6.2.2.  Impacts of Replay Attacks on NORM  . . . . . . . . . . 52
       6.2.3.  Impacts of Replay Attacks on ALC . . . . . . . . . . . 53
     6.3.  Security of the Back Channel . . . . . . . . . . . . . . . 53
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 54
   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 55
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 55
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 55
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 56

Top      ToC       Page 5 
1.  Introduction

   Many applications using multicast and broadcast communications
   require that each receiver be able to authenticate the source of any
   packet it receives as well as the integrity of these packets.  This
   is the case with ALC [RFC5775] and NORM [RFC5740], two Content
   Delivery Protocols (CDPs) designed to transfer objects (e.g., files)
   reliably between a session's sender and several receivers.  The NORM
   protocol is based on bidirectional transmissions.  Each receiver
   acknowledges data received or, in case of packet erasures, asks for
   retransmissions.  On the opposite, the ALC protocol is based on
   purely unidirectional transmissions.  Reliability is achieved by
   means of the cyclic transmission of the content within a carousel
   and/or by the use of proactive Forward Error Correction (FEC) codes.
   Both protocols have in common the fact that they operate at the
   application level, on top of an erasure channel (e.g., the Internet)
   where packets can be lost (erased) during the transmission.

   The goal of this document is to counter attacks where an attacker
   impersonates the ALC or NORM session's sender and injects forged
   packets to the receivers, thereby corrupting the objects
   reconstructed by the receivers.

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

   The usual solution to provide the source authentication and message
   integrity services in the case of multicast and broadcast
   communications consists of 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 (TESLA) protocol is an
   alternative solution that provides the two required services, while
   being compatible with high-rate transmissions over lossy channels.

   This document explains how to integrate the TESLA source
   authentication and packet integrity protocol to the ALC and NORM CDP.
   Any application built on top of ALC and NORM will directly benefit
   from the services offered by TESLA at the transport layer.  In
   particular, this is the case of File Delivery over Unidirectional
   Transport (FLUTE).

Top      ToC       Page 6 
   For more information on the TESLA protocol and its principles, please
   refer to [RFC4082] and [Perrig04].  For more information on ALC and
   NORM, please refer to [RFC5775], [RFC5651], and [RFC5740],
   respectively.  For more information on FLUTE, please refer to
   [RMT-FLUTE].

1.1.  Scope of This Document

   This specification only considers the authentication and integrity
   verification of the packets generated by the session's sender.  This
   specification does not consider the packets that may be sent by
   receivers, for instance, NORM's feedback packets.  [RMT-SIMPLE-AUTH]
   describes several techniques that can be used to that purpose.  Since
   this is usually a low-rate flow (unlike the downstream flow), using
   computing intensive techniques like digital signatures, possibly
   combined with a Group MAC scheme, is often acceptable.  Finally,
   Section 5 explains how to use several authentication schemes in a
   given session thanks to the "ASID" (Authentication Scheme IDentifier)
   field.

   This specification relies on several external mechanisms, for
   instance:

   o  to communicate securely the public key or a certificate for the
      session's sender (Section 2.2.2);

   o  to communicate securely and confidentially the group key, K_g,
      used by the Group MAC feature, when applicable (Section 3.3.3).
      In some situations, this group key will have to be periodically
      refreshed;

   o  to perform secure time synchronization in indirect mode
      (Section 2.3.2) or in direct mode (Section 2.3.1) to carry the
      request/response messages with ALC, which is purely
      unidirectional;

   These mechanisms are required in order to bootstrap TESLA at a sender
   and at a receiver and must be deployed in parallel to TESLA.
   Besides, the randomness of the Primary Key of the key chain
   (Section 3.1.2) is vital to the security of TESLA.  Therefore, the
   sender needs an appropriate mechanism to generate this random key.

   Several technical details of TESLA, like the most appropriate way to
   alternate between the transmission of a key disclosure and a
   commitment to a new key chain, or the transmission of a key
   disclosure and the last key of the previous key chain, or the
   disclosure of a key and the compact flavor that does not disclose any
   key, are specific to the target use case (Section 3.1.2).  For

Top      ToC       Page 7 
   instance, it depends on the number of packets sent per time interval,
   on the desired robustness and the acceptable transmission overhead,
   which can only be optimized after taking into account the use-case
   specificities.

1.2.  Conventions Used in This Document

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

1.3.  Terminology and Notations

   The following notations and definitions are used throughout this
   document.

1.3.1.  Notations and Definitions Related to Cryptographic Functions

   Notations and definitions related to cryptographic functions
   [RFC4082][RFC4383]:

   o  PRF is the Pseudo Random Function;

   o  MAC is the Message Authentication Code;

   o  HMAC is the keyed-Hash Message Authentication Code;

   o  F is the one-way function used to create the key chain
      (Section 3.1.2.1);

   o  F' is the one-way function used to derive the HMAC keys
      (Section 3.1.2.1);

   o  n_p is the length, in bits, of the F function's output.  This is
      therefore the length of the keys in the key chain;

   o  n_f is the length, in bits, of the F' function's output.  This is
      therefore the length of the HMAC keys;

   o  n_m is the length, in bits, of the truncated output of the MAC
      [RFC2104].  Only the n_m most significant bits of the MAC output
      are kept;

   o  N is the length of a key chain.  There are N+1 keys in a key
      chain: K_0, K_1, ..., K_N.  When several chains are used, all the
      chains MUST have the same length and keys are numbered
      consecutively, following the time interval numbering;

Top      ToC       Page 8 
   o  n_c is the number of keys in a key chain.  Therefore, n_c = N+1;

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

   o  n_tx_newkcc is the number of intervals during which the commitment
      to a new key chain SHOULD be sent, before switching to the new key
      chain.  The n_tx_newkcc value is either 0 (no commitment sent
      within authentication tags) or larger.  This parameter is sender
      specific and is not communicated to the receiver;

   o  K_g is a shared group key, communicated to all group members,
      confidentially, during the TESLA bootstrapping (Section 2.2);

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

1.3.2.  Notations and Definitions Related to Time

   Notations and definitions related to time:

   o  i is the time interval index.  Interval numbering starts at 0 and
      increases consecutively.  Since the interval index is stored as a
      32-bit unsigned integer, wrapping to 0 might take place in long
      sessions.

   o  t_s is the sender local time value at some absolute time (in NTP
      timestamp format);

   o  t_r is the receiver local time value at the same absolute time (in
      NTP timestamp format);

   o  T_0 is the start time corresponding to the beginning of the
      session, i.e., the beginning of time interval 0 (in NTP timestamp
      format);

   o  T_int is the interval duration (in milliseconds);

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

Top      ToC       Page 9 
   o  D_t is the upper bound of the lag of the receiver's clock with
      respect to the clock of the sender;

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

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

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

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

   o  NTP timestamp format consists in a 64-bit unsigned fixed-point
      number, in seconds relative to 0h on 1 January 1900.  The integer
      part is in the first 32 bits, and the fraction part in the last 32
      bits [RFC1305].

2.  Using TESLA with ALC and NORM: General Operations

2.1.  ALC and NORM Specificities That Impact TESLA

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

   In the case of ALC:

   o  ALC is massively scalable: nothing in the protocol specification
      limits the number of receivers that join a session.  Therefore, an
      ALC session potentially includes a huge number (e.g., millions or
      more) of receivers;

   o  ALC can work on top of purely unidirectional transport channels:
      this is one of the assets of ALC, and examples of unidirectional
      channels include satellite (even if a back channel might exist in
      some use cases) and broadcasting networks like Digital Video
      Broadcasting - Handhelds / Satellite services to Handhelds (DVB-
      H/SH);

   o  ALC defines an on-demand content delivery model [RFC5775] 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;

Top      ToC       Page 10 
   o  ALC sessions are potentially very long: a session can last several
      days or months during which the content is continuously
      transmitted within a carousel.  The content can be either static
      (e.g., a software update) or dynamic (e.g., a web site).

   Depending on the use case, some of the above features may not apply.
   For instance, ALC can also be used over a bidirectional channel or
   with a limited number of receivers.

   In the case of NORM:

   o  NORM has been designed for medium-size sessions: indeed, NORM
      relies on feedback messages and the sender may collapse if the
      feedback message rate is too high;

   o  NORM requires a bidirectional transport channel: the back channel
      is not necessarily a high-data rate channel since the control
      traffic sent over it by a single receiver is an order of magnitude
      lower than the downstream traffic.  Networks with an asymmetric
      connectivity (e.g., a high-rate satellite downlink and a low-rate
      return channel) are appropriate.

2.2.  Bootstrapping TESLA

   In order to initialize the TESLA component at a receiver, the sender
   MUST communicate some key information in a secure way, so that the
   receiver can check the source of the information and its integrity.
   Two general methods are possible:

   o  by using an out-of-band mechanism, or

   o  by using an in-band mechanism.

   The current specification does not recommend any mechanism to
   bootstrap TESLA.  Choosing between an in-band and out-of-band scheme
   is left to the implementer, depending on the target use case.
   However, it is RECOMMENDED that TESLA implementations support the use
   of the in-band mechanism for interoperability purposes.

2.2.1.  Bootstrapping TESLA with an Out-Of-Band Mechanism

   For instance, [RFC4442] describes the use of the MIKEY (Multimedia
   Internet Keying) protocol to bootstrap TESLA.  As a side effect,
   MIKEY also provides a loose time synchronization feature from which
   TESLA can benefit.  Other solutions, for instance, based on an
   extended session description, are possible, on the condition that
   these solutions provide the required security level.

Top      ToC       Page 11 
2.2.2.  Bootstrapping TESLA with an In-Band Mechanism

   This specification describes an in-band mechanism.  In some use
   cases, it might be desired that bootstrapping take place without
   requiring the use of an additional external mechanism.  For instance,
   each device may feature a clock with a known time-drift that is
   negligible in front of the time accuracy required by TESLA, and each
   device may embed the public key of the sender.  It is also possible
   that the use case does not feature a bidirectional channel that
   prevents the use of out-of-band protocols like MIKEY.  For these two
   examples, the exchange of a bootstrap information message (described
   in Section 3.4.1) and the knowledge of a few additional parameters
   (listed below) are sufficient to bootstrap TESLA at a receiver.

   Some parameters cannot be communicated in-band.  In particular:

   o  the sender or group controller MUST either communicate the public
      key of the sender or a certificate (which also means that a PKI
      has been set up) to all receivers, so that each receiver be able
      to verify the signature of the bootstrap message and direct time
      synchronization response messages (when applicable).

   o  when time synchronization is performed with NTP/SNTP (Simple
      Network Time Protocol), the sender or group controller MUST
      communicate the list of valid NTP/SNTP servers to all the session
      members (sender included), so that they are all able to
      synchronize themselves on the same NTP/SNTP servers.

   o  when the Group MAC feature is used, the sender or group controller
      MUST communicate the K_g group key to all the session members
      (sender included).  This group key may be periodically refreshed.

   The way these parameters are communicated is out of the scope of this
   document.

2.3.  Setting Up a Secure Time Synchronization

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

   o  direct time synchronization, and

   o  indirect time synchronization.

   It is also possible that a given session includes receivers that use
   the direct time synchronization mode while others use the indirect
   time synchronization mode.

Top      ToC       Page 12 
2.3.1.  Direct Time Synchronization

   When direct time synchronization is used, each receiver asks the
   sender for a time synchronization.  To that purpose, a receiver sends
   a direct time synchronization request (Section 4.2.2.1).  The sender
   then directly answers each request with a direct time synchronization
   response (Section 3.4.2), signing this reply.  Upon receiving this
   response, a receiver first verifies the signature, and then
   calculates an upper bound of the lag of his clock with respect to the
   clock of the sender, D_t.  The details on how to calculate D_t are
   given in Section 2.4.1.

   This synchronization method is both simple and secure.  Yet, there
   are two potential issues:

   o  a bidirectional channel must exist between the sender and each
      receiver, and

   o  the sender may collapse if the incoming request rate is too high.

   Relying on direct time synchronization is not expected to be an issue
   with NORM since (1) bidirectional communications already take place,
   and (2) NORM scalability is anyway limited.  Yet, it can be required
   that a mechanism, that is out of the scope of this document, be used
   to spread the transmission of direct time synchronization request
   messages over time if there is a risk that the sender may collapse.

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

2.3.2.  Indirect Time Synchronization

   When indirect time synchronization is used, the sender and each
   receiver must synchronize securely via an external time reference.
   Several possibilities exist:

   o  sender and receivers can synchronize through an NTPv3 (Network
      Time Protocol version 3) [RFC1305] hierarchy of servers.  The
      authentication mechanism of NTPv3 MUST be used in order to
      authenticate each NTP message individually.  It prevents, for
      instance, an attacker from impersonating an NTP server;

   o  they can synchronize through an NTPv4 (Network Time Protocol
      version 4) [NTP-NTPv4] hierarchy of servers.  The Autokey security
      protocol of NTPv4 MUST be used in order to authenticate each NTP
      message individually;

Top      ToC       Page 13 
   o  they can synchronize through an SNTPv4 (Simple Network Time
      Protocol version 4) [RFC4330] hierarchy of servers.  The
      authentication features of SNTPv4 must then be used.  Note that
      TESLA only needs a loose (but secure) time synchronization, which
      is in line with the time synchronization service offered by SNTP;

   o  they can synchronize through a GPS or Galileo (or similar) device
      that also provides a high precision time reference.  Spoofing
      attacks on the GPS system have recently been reported.  Depending
      on the use case, the security achieved will or will not be
      acceptable;

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

   A bidirectional channel is required by the NTP/SNTP schemes.  On the
   opposite, with the GPS/Galileo and high precision clock schemes, no
   such assumption is made.  In situations where ALC is used on purely
   unidirectional transport channels (Section 2.1), using the NTP/SNTP
   schemes is not possible.  Another aspect is the scalability
   requirement of ALC, and to a lesser extent of NORM.  From this point
   of view, the above mechanisms usually do not raise any problem,
   unlike the direct time synchronization schemes.  Therefore, using
   indirect time synchronization can be a good choice.  It should be
   noted that the NTP/SNTP schemes assume that each client trusts the
   sender and accepts aligning its NTP/SNTP configuration to that of the
   sender.  If this assumption does not hold, the sender SHOULD offer an
   alternative solution.

   The details on how to calculate an upper bound of the lag of a
   receiver's clock with respect to the clock of the sender, D_t, are
   given in Section 2.4.2.

2.4.  Determining the Delay Bounds

   Let us assume that a secure time synchronization has been set up.
   This section explains how to define the various timing parameters
   that are used during the authentication of received packets.

Top      ToC       Page 14 
2.4.1.  Delay Bound Calculation in Direct Time Synchronization Mode

   In direct time synchronization mode, synchronization between a
   receiver and the sender follows the following protocol [RFC4082]:

   o  The receiver sends a direct time synchronization request message
      to the sender, that includes t_r, the receiver local time at the
      moment of sending (Section 4.2.2.1).

   o  Upon receipt of this message, the sender records its local time,
      t_s, and sends to the receiver a direct time synchronization
      response that includes t_r (taken from the request) and t_s,
      signing this reply (Section 3.4.2).

   o  Upon receiving this response, the receiver first verifies that he
      actually sent a request with t_r and then checks the signature.
      Then he calculates D_t = t_s - t_r + S_sr, where S_sr is an
      estimated bound of the clock drift between the sender and the
      receiver throughout the duration of the session.  This document
      does not specify how S_sr is estimated.

   After this initial synchronization, at any point throughout the
   session, the receiver knows that: T_s < T_r + D_t, where T_s is the
   current time at the sender and T_r is the current time at the
   receiver.

2.4.2.  Delay Bound Calculation in Indirect Time Synchronization Mode

   In indirect time synchronization, the sender and the receivers must
   synchronize indirectly using one or several time references.

2.4.2.1.  Single Time Reference

   Let us assume that there is a single time reference.

   1.  The sender calculates D^O_t, the upper bound of the lag of the
       sender's clock with respect to the time reference.  This D^O_t
       value is then communicated to the receivers (Section 3.2.1).

   2.  Similarly, a receiver R calculates D^R_t, the upper bound of the
       lag of the receiver's clock with respect to the time reference.

   3.  Then, for receiver R, the overall upper bound of the lag of the
       receiver's clock with respect to the clock of the sender, D_t, is
       the sum: D_t = D^O_t + D^R_t.

Top      ToC       Page 15 
   The D^O_t and D^R_t calculation depends on the time synchronization
   mechanism used (Section 2.3.2).  In some cases, the synchronization
   scheme specifications provide these values.  In other cases, these
   parameters can be calculated by means of a scheme similar to the one
   specified in Section 2.4.1, for instance, when synchronization is
   achieved via a group controller [RFC4082].

2.4.2.2.  Multiple Time References

   Let us now assume that there are several time references (e.g.,
   several NTP/SNTP servers).  The sender and receivers first
   synchronize with the various time references, independently.  It
   results in D^O_t and D^R_t.  Let D_err be an upper bound of the time
   error between all of the time references.  Then, the overall value of
   D_t within receiver R is set to the sum: D_t = D^O_t + D^R_t + D_err.

   In some cases, the D_t value is part of the time synchronization
   scheme specifications.  For instance, NTPv3 [RFC1305] defines
   algorithms that are "capable of accuracies in the order of a
   millisecond, even after extended periods when synchronization to
   primary reference sources has been lost".  In practice, depending on
   the NTP server stratum, the accuracy might be a little bit worse.  In
   that case, D_t = security_factor * (1ms + 1ms), where the
   security_factor is meant to compensate several sources of inaccuracy
   in NTP.  The choice of the security_factor value is left to the
   implementer, depending on the target use case.

2.5.  Cryptographic Parameter Values

   The F (resp. F') function output length is given by the n_p (resp.
   n_f) parameter.  The n_p and n_f values depend on the PRF function
   chosen, as specified below:

             +------------------------+---------------------+
             |        PRF name        |     n_p and n_f     |
             +------------------------+---------------------+
             |       HMAC-SHA-1       | 160 bits (20 bytes) |
             |      HMAC-SHA-224      | 224 bits (28 bytes) |
             | HMAC-SHA-256 (default) | 256 bits (32 bytes) |
             |      HMAC-SHA-384      | 384 bits (48 bytes) |
             |      HMAC-SHA-512      | 512 bits (64 bytes) |
             +------------------------+---------------------+

   The computing of regular MAC (resp. Group MAC) makes use of the n_m
   (resp. n_w) parameter, i.e., the length of the truncated output of
   the function.  The n_m and n_w values depend on the MAC function
   chosen, as specified below:

Top      ToC       Page 16 
   +------------------------+---------------------+-------------------+
   |        MAC name        |  n_m (regular MAC)  |  n_w (Group MAC)  |
   +------------------------+---------------------+-------------------+
   |       HMAC-SHA-1       |  80 bits (10 bytes) | 32 bits (4 bytes) |
   |      HMAC-SHA-224      | 112 bits (14 bytes) | 32 bits (4 bytes) |
   | HMAC-SHA-256 (default) | 128 bits (16 bytes) | 32 bits (4 bytes) |
   |      HMAC-SHA-384      | 192 bits (24 bytes) | 32 bits (4 bytes) |
   |      HMAC-SHA-512      | 256 bits (32 bytes) | 32 bits (4 bytes) |
   +------------------------+---------------------+-------------------+



(page 16 continued on part 2)

Next RFC Part