tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 5776

 
 
 

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

Part 3 of 3, p. 36 to 58
Prev RFC Part

 


prevText      Top      Up      ToC       Page 36 
4.  Receiver Operations

   This section describes the TESLA operations at a receiver.

4.1.  Verification of the Authentication Information

   This section details the computation steps required to verify each of
   the three possible authentication information of an incoming packet.
   The verification MUST follow a strict order:

   o  first of all, if the Group MAC is present and if the session uses
      this feature (e.g., if the G bit is set in the bootstrap
      information message), then verify the Group MAC.  A packet that
      does not contain a Group MAC tag, whereas the session uses this
      feature, MUST be dropped immediately.  On the opposite, if a
      packet contains a Group MAC tag whereas the session does not use
      this feature, this tag MUST be ignored;

   o  then, verify the digital signature (with TESLA signaling packets)
      or enter the TESLA authentication process (with data packets).

4.1.1.  Processing the Group MAC Tag

   Upon receiving a packet containing a Group MAC tag, the receiver
   recomputes the Group MAC and compares it to the value carried in the
   packet.  If the check fails, the packet MUST be dropped immediately.

Top      Up      ToC       Page 37 
   More specifically, recomputing the Group MAC requires saving the
   value of the "Group MAC" field, setting this field to 0, and doing
   the same computation as a sender does (see Section 3.3.3).

4.1.2.  Processing the Digital Signature

   Upon receiving a packet containing a digital signature, the receiver
   verifies the signature as follows.

   The computation of the signature MUST include the ALC or NORM header
   (with the various header extensions) and the payload when applicable.
   The UDP/IP headers MUST NOT be included.  During this computation,
   the "Signature" field MUST be set to 0 as well as the optional Group
   MAC, when present.

   From [RFC4359]: Digital signature verification is performed as
   described in [RFC3447], Section 8.2.2 (RSASSA-PKCS1-v1_5) and
   [RFC3447], Section 8.1.2 (RSASSA-PSS).  Upon receipt, the digital
   signature is passed to the verification function as S.  The
   authenticated portion of the packet is used as the message M, and the
   RSA public key is passed as (n, e).  In summary (when SHA-256 is
   used), the verification function computes a SHA-256 hash of the
   authenticated packet bytes, decrypts the SHA-256 hash in the packet,
   and validates that the appropriate encoding was applied.  The two
   SHA-256 hashes are compared, and if they are identical the validation
   is successful.

   It is assumed that the receivers have the possibility to retrieve the
   sender's public key required to check this digital signature
   (Section 2.2).  This document does not specify how the public key of
   the sender is communicated reliably and in a secure way to all
   possible receivers.

4.1.3.  Processing the Authentication Tag

   When a receiver wants to authenticate a packet using an
   authentication tag and when he has the key for the associated time
   interval (i.e., after the disclosing delay, d), the receiver
   recomputes the MAC and compares it to the value carried in the
   packet.  If the check fails, the packet MUST be immediately dropped.

   More specifically, recomputing the MAC requires saving the value of
   the "MAC" field, setting this field to 0, and doing the same
   computation as a sender does (see Section 3.3.1).

Top      Up      ToC       Page 38 
4.2.  Initialization of a Receiver

   A receiver MUST be initialized before being able to authenticate the
   source of incoming packets.  This can be done by an out-of-band
   mechanism or an in-band mechanism (Section 2.2).  Let us focus on the
   in-band mechanism.  Two actions must be performed:

   o  receive and process a bootstrap information message, and

   o  calculate an upper bound of the sender's local time.  To that
      purpose, the receiver must perform time synchronization.

4.2.1.  Processing the Bootstrap Information Message

   A receiver must first receive a packet containing the bootstrap
   information, digitally signed by the sender.  Once the bootstrap
   information has been authenticated (see Section 4.1), the receiver
   can initialize its TESLA component.  The receiver MUST then ignore
   the following bootstrap information messages, if any.  There is an
   exception though: when a new key chain is used and if a receiver
   missed all the commitments for this new key chain, then this receiver
   MUST process one of the future bootstrap information messages (if
   any) in order to be able to authenticate the incoming packets
   associated to this new key chain.

   Before TESLA has been initialized, a receiver MUST discard incoming
   packets other than the bootstrap information message and direct time
   synchronization response.

4.2.2.  Performing Time Synchronization

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

4.2.2.1.  Direct Time Synchronization

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

Top      Up      ToC       Page 39 
   The direct time synchronization request message format is the
   following:

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

         Figure 8: Format of a Direct Time Synchronization Request

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

   "t_r" (NTP timestamp, 64 bits):

      "t_r" is a timestamp in NTP timestamp format that contains the
      receiver local time value when sending this direct time
      synchronization request message;

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

      This field contains the Group MAC, calculated with the group key,
      K_g, shared by all group members.  The field length, in bits, is
      given by n_w, which is known once the Group MAC function type is
      known (Section 7).

   The receiver then awaits a response message (Section 3.4.2).  Upon
   receiving this message, the receiver:

      checks that this response relates to the request, by comparing the
      "t_r" fields;

      checks the Group MAC if present;

      checks the signature;

      retrieves the t_s value and calculates D_t (Section 2.4.1).

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

Top      Up      ToC       Page 40 
4.2.2.2.  Indirect Time Synchronization

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

   Then the receiver computes the time offset between itself and the NTP
   server chosen.  Note that the receiver does not need to update the
   local time, (which often requires root privileges), computing the
   time offset is sufficient.

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

   Note that this scenario assumes that each client trusts the sender
   and accepts aligning its NTP configuration to that of the sender,
   using one of the NTP server(s) suggested.  If this assumption does
   not hold, the client MUST NOT use the NTP indirect time
   synchronization method (Section 2.3.2).

4.3.  Authentication of Received Packets

   The receiver can now authenticate incoming packets (other than
   bootstrap information and direct time synchronization response
   packets).  To that purpose, he MUST follow different steps (see
   [RFC4082], Section 3.5):

   1.  The receiver parses the different packet headers.  If none of the
       four TESLA authentication tags are present, the receiver MUST
       discard the packet.  If the session is in "Single Key Chain" mode
       (e.g., when the "S" flag is set in the bootstrap information
       message), then the receiver MUST discard any packet containing an
       Authentication Tag with a New Key Chain Commitment or an
       Authentication Tag with a Last Key of Old Chain Disclosure.

   2.  Safe packet test: When the receiver receives packet P_j, it first
       records the local time T at which the packet arrived.  The
       receiver then computes an upper bound t_j on the sender's clock
       at the time when the packet arrived: t_j = T + D_t.  The receiver

Top      Up      ToC       Page 41 
       then computes the highest interval the sender could possibly be
       in: highest_i = floor((t_j - T_0) / T_int).  He also retrieves
       the "i" interval index from the authentication tag.  The receiver
       can now proceed with the "safe packet" test.  If highest_i < i +
       d, then the sender is not yet in the interval during which it
       discloses the key K_i.  The packet is safe (but not necessarily
       authentic).  If the test fails, the packet is unsafe, and the
       receiver MUST discard the packet.

   3.  Group MAC test: if the optional Group MAC tag is present and if
       the session uses this feature, then verify the Group MAC
       (Section 4.1.1).  If the verification fails, the packet MUST be
       immediately dropped.  A packet that does not contain a Group MAC
       tag whereas the session uses this feature MUST be immediately
       dropped.  On the opposite, if a packet contains a Group MAC tag
       whereas the session does not use this feature, this tag MUST be
       ignored.

   4.  Disclosed Key processing: When the packet discloses a key (i.e.,
       with a Standard Authentication Tag, or with an Authentication Tag
       with a Last Key of Old Chain Disclosure), the following tests are
       performed:

       *  New key index test: the receiver checks whether a legitimate
          key already exists with the same index (i.e., i-d).  If such a
          legitimate key exists, the receiver compares its value with
          the current disclosed key and if they are identical, skips the
          "Unverifiable key test" and "Key verification test".  If such
          a legitimate key exists but the values differ, the receiver
          MUST discard the packet.

       *  Unverifiable key test: when the disclosed key index is new, it
          is possible that no earlier disclosed and legitimate key
          exists for this key chain, thereby preventing the verification
          of the disclosed key.  This happens when the disclosed key
          belongs to the old key chain and no commitment to this old key
          chain has ever been received (e.g., because the first
          bootstrap packet received by a latecomer is for the current
          key chain, and therefore includes a commitment to the current
          key chain, not the previous one).  When this happens, the
          receiver MUST ignore the disclosed key (anyway useless) and
          skip the Key verification test.

       *  Key verification test: If the disclosed key index is new and
          the key can be verified, the receiver checks the legitimacy of
          K_{i-d} by verifying, for some earlier disclosed and
          legitimate key K_v (with v < i-d), that K_v and F^{i-d-
          v}(K_{i-d}) are identical.  In other words, the receiver

Top      Up      ToC       Page 42 
          checks the disclosed key by computing the necessary number of
          PRF functions to obtain a previously disclosed and legitimate
          (i.e., verified) key.  If the key verification fails, the
          receiver MUST discard the packet.  If the key verification
          succeeds, this key is said to be legitimate and is stored by
          the receiver, as well as all the keys between indexes v and
          i-d.

   5.  When applicable, the receiver performs any congestion control
       related action (i.e., the ALC or NORM headers are used by the
       associated congestion control building block, if any), even if
       the packet has not yet been authenticated [RFC5651].  If this
       feature leads to a potential DoS attack (the attacker can send a
       faked packet with a wrong sequence number to simulate packet
       losses), it does not compromise the security features offered by
       TESLA and enables a rapid reaction in front of actual congestion
       problems.

   6.  The receiver then buffers the packet for a later authentication,
       once the corresponding key will be disclosed (after d time
       intervals) or deduced from another key (if all packets disclosing
       this key are lost).  In some situations, this packet might also
       be discarded later, if it turns out that the receiver will never
       be able to deduce the associated key.

   7.  Authentication test: Let v be the smallest index of the
       legitimate keys known by the receiver so far.  For all the new
       keys K_w, with v < w <= i-d, that have been either disclosed by
       this packet (i.e., K_{i-d}) or derived by K_{i-d} (i.e., keys in
       interval {v+1,.. i-d-1}), the receiver verifies the authenticity
       of the safe packets buffered for the corresponding interval w.
       To authenticate one of the buffered packets P_h containing
       message M_h protected with a MAC that used key index w, the
       receiver will compute K'_w = F'(K_w) from which it can compute
       MAC( K'_w, M_h).  If this MAC does not equal the MAC stored in
       the packet, the receiver MUST discard the packet.  If the two
       MACs are equal, the packet is successfully authenticated and the
       receiver continues processing it.

   8.  Authenticated new key chain commitment processing: If the
       authenticated packet contains a new key chain commitment and if
       no verified commitment already exists, then the receiver stores
       the commitment to the new key chain.  Then, if there are non-
       authenticated packets for a previous chain (i.e., the key chain
       before the current one), all these packets can be discarded
       (Section 4.4).

Top      Up      ToC       Page 43 
   9.  The receiver continues the ALC or NORM processing of all the
       packets authenticated during the authentication test.

   In this specification, a receiver using TESLA MUST immediately drop
   unsafe packets.  But the receiver MAY also decide, at any time, to
   continue an ALC or NORM session in unsafe (insecure) mode, ignoring
   TESLA extensions.  There SHOULD be an explicit user action to that
   purpose.

4.3.1.  Discarding Unnecessary Packets Earlier

   Following strictly the above steps can lead to excessive processing
   overhead in certain situations.  This is the case when a receiver
   receives packets for an unwanted object with the ALC or NORM
   protocols, i.e., an object in which the application (or the end user)
   explicitly mentioned it is not interested.  This is also the case
   when a receiver receives packets for an already decoded object, or
   when this object has been partitioned in several blocks, for an
   already decoded block.  When such a packet is received, which is
   easily identified by looking at the receiver's status for the
   incoming ALC or NORM packet, the receiver MUST also check that the
   packet is a pure data packet that does not contain any signaling
   information of importance for the session.

   With ALC, a packet containing an "A" flag ("Close Session") or a "B"
   flag ("Close Object") MUST NOT be discarded before having been
   authenticated and processed normally.  Otherwise, the receiver can
   safely discard the incoming packet for instance just after step 1 of
   Section 4.3.  This optimization can dramatically reduce the
   processing overhead by avoiding many useless authentication checks.

4.4.  Flushing the Non-Authenticated Packets of a Previous Key Chain

   In some cases, a receiver having experienced a very long
   disconnection might have lost all the disclosures of the last key(s)
   of a previous key chain.  Let j be the index of this key chain for
   which there remains non-authenticated packets.  This receiver can
   flush all the packets of the key chain j if he determines that:

   o  he has just switched to a chain of index j+2 (inclusive) or
      higher;

   o  the sender has sent a commitment to the new key chain of index j+2
      (Section 3.1.2.3).  This situation requires that the receiver has
      received a packet containing such a commitment and that he has
      been able to check its integrity.  In some cases, it might require
      receiving a bootstrap information message for the current key
      chain.

Top      Up      ToC       Page 44 
   If one of the above two tests succeeds, the sender can discard all
   the awaiting packets since there is no way to authenticate them.

5.  Integration in the ALC and NORM Protocols

5.1.  Authentication Header Extension Format

   The integration of TESLA in ALC or NORM is similar and relies on the
   header extension mechanism defined in both protocols.  More
   precisely, this document details the EXT_AUTH==1 header extension
   defined in [RFC5651].

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

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

          Figure 9: Format of the TESLA EXT_AUTH Header Extension

   The fields of the TESLA EXT_AUTH Header Extension are:

   "ASID" (Authentication Scheme IDentifier) field (4 bits):

      The "ASID" identifies the source authentication scheme or protocol
      in use.  The association between the "ASID" value and the actual
      authentication scheme is defined out-of-band, at session startup.

   "Type" field (4 bits):

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

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

      *  1: Standard Authentication Tag for the ongoing key chain, sent
         by the sender along with a packet;

Top      Up      ToC       Page 45 
      *  2: Authentication Tag without Key Disclosure, sent by the
         sender along with a packet;

      *  3: Authentication Tag with a New Key Chain Commitment, sent by
         the sender when approaching the end of a key chain;

      *  4: Authentication Tag with a Last Key of Old Chain Disclosure,
         sent by the sender some time after moving to a new key chain;

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

      *  6: Direct time synchronization response, sent by a NORM sender.
         This type of message is invalid in the case of an ALC session
         since ALC is restricted to unidirectional transmissions.  Yet,
         an external mechanism may provide the direct time
         synchronization functionality.

   "Content" field (variable length):

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

5.2.  Use of Authentication Header Extensions

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

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

5.2.1.  EXT_AUTH Header Extension of Type Bootstrap Information

   The "bootstrap information" TESLA EXT_AUTH (Type==0) MUST be sent in
   a stand-alone control packet, rather than in a packet containing
   application data.  The reason for that is the large size of this
   bootstrap information.  By using stand-alone packets, the maximum
   payload size of data packets is only affected by the (mandatory)
   authentication information header extension.

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

   With NORM, the "bootstrap information" TESLA EXT_AUTH MUST be sent in
   a NORM_CMD(APPLICATION) message.

Top      Up      ToC       Page 47 
   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  ---
  |   HET (=1)    |    HEL (=46)  |  ASID |   0   | 0 |  0  |0|1|0|  ^
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
  |       d       |       2       |       2       |       2       |  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
  |       1       |       3       |              128              |  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
  |         0 (reserved)          |             T_int             |  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
  |                                                               |  |
  +                  T_0 (NTP timestamp format)                   +  | 5
  |                                                               |  | 2
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
  |                      N (Key Chain Length)                     |  | b
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  | y
  |                    Current Interval Index i                   |  | t
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  | e
  |                                                               |  | s
  +                                                               +  |
  |                                                               |  |
  +                 Current Key Chain Commitment                  +  |
  |                          (20 bytes)                           |  |
  +                                                               +  |
  |                                                               |  |
  +                                                               +  |
  |                                                               |  v
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  ---
  |                                                               |  ^ 1
  +                                                               +  | 2
  |                                                               |  | 8
  .                                                               .  |
  .                           Signature                           .  | b
  .                          (128 bytes)                          .  | y
  |                                                               |  | t
  +                                                               +  | e
  |                                                               |  v s
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  ---
  |                           Group MAC                           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 10: Example: Format of the Bootstrap Information Message
                (Type 0) Using SHA-256/1024-Bit Signatures,
                 the Default HMAC-SHA-256, and a Group MAC

Top      Up      ToC       Page 48 
   For instance, Figure 10 shows the bootstrap information message when
   using the HMAC-SHA-256 transform for the PRF, MAC, and Group MAC
   functions, along with SHA-256/128 byte (1024 bit) key digital
   signatures (which also means that the "Signature" field is 128 bytes
   long).  The TESLA EXT_AUTH Header Extension is then 184 bytes long
   (i.e., 46 words of 32 bits).

5.2.2.  EXT_AUTH Header Extension of Type Authentication Tag

   The four "authentication tag" TESLA EXT_AUTH Header Extensions (Type
   1, 2, 3, and 4) MUST be attached to the ALC or NORM packet (data or
   control packet) that they protect.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   HET (=1)    |   HEL (=10)   |  ASID |   1   |   Reserved    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                i (Interval Index of K'_i)                     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                                                               +
    |                                                               |
    +                     Disclosed Key K_{i-d}                     +
    |                          (20 bytes)                           |
    +                                                               +
    |                                                               |
    +                                                               +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                                                               +
    |                         MAC(K'_i, M)                          |
    +                          (16 bytes)                           +
    |                                                               |
    +                                                               +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Figure 11: Example: Format of the Standard Authentication Tag
                  (Type 1) Using the Default HMAC-SHA-256

Top      Up      ToC       Page 49 
     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 (=5)    |  ASID |   2   |   Reserved    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                i (Interval Index of K'_i)                     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                                                               +
    |                         MAC(K'_i, M)                          |
    +                          (16 bytes)                           +
    |                                                               |
    +                                                               +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Figure 12: Example: Format of the Authentication Tag without
          Key Disclosure (Type 2) Using the Default HMAC-SHA-256

   For instance, Figures 11 and 12 show the format of the authentication
   tags, respectively with and without the K_{i-d} key disclosure, when
   using the (default) HMAC-SHA-256 transform for the PRF and MAC
   functions.  In these examples, the Group MAC feature is not used.

5.2.3.  EXT_AUTH Header Extension of Type Direct Time Synchronization
        Request

   With NORM, the "direct time synchronization request" TESLA EXT_AUTH
   (Type==7) MUST be sent by a receiver in a NORM_CMD(APPLICATION) NORM
   packet.

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

   In the case of direct time synchronization, it is RECOMMENDED that
   the receivers spread the transmission of direct time synchronization
   requests over the time (Section 2.3.1).

5.2.4.  EXT_AUTH Header Extension of Type Direct Time Synchronization
        Response

   With NORM, the "direct time synchronization response" TESLA EXT_AUTH
   (Type==8) MUST be sent by the sender in a NORM_CMD(APPLICATION)
   message.

Top      Up      ToC       Page 50 
   With ALC, the "direct time synchronization response" TESLA EXT_AUTH
   can be sent in an ALC control packet (i.e., containing no encoding
   symbol) or through the external mechanism used to carry the direct
   time synchronization request.

6.  Security Considerations

   [RFC4082] discusses the security of TESLA in general.  These
   considerations apply to the present specification, namely:

   o  great care must be taken in the timing aspects.  In particular,
      the D_t parameter is critical and must be correctly initialized;

   o  if the sender realizes that the key disclosure schedule is not
      appropriate, then the current session MUST be closed and a new one
      created.  Indeed, Section 3.1.3 requires that these parameters be
      fixed during the whole session.

   o  when the verifier that authenticates the incoming packets and the
      application that uses the data are two different components, there
      is a risk that an attacker located between these components inject
      faked data.  Similarly, when the verifier and the secure timing
      system are two different components, there is a risk that an
      attacker located between these components inject faked timing
      information.  For instance, when the verifier reads the local time
      by means of a dedicated system call (e.g., gettimeofday()), if an
      attacker controls the host, he may catch the system call and
      return a faked time information.

   The current specification discusses additional aspects with more
   details.

6.1.  Dealing with DoS Attacks

   TESLA introduces new opportunities for an attacker to mount DoS
   attacks.  For instance, an attacker can try to saturate the
   processing capabilities of the receiver (faked packets are easy to
   create but checking them requires computing a MAC over the packet or
   sometimes checking a digital signature as with the bootstrap and
   direct time synchronization response messages).  An attacker can also
   try to saturate the receiver's memory (since authentication is
   delayed and non-authenticated packets will accumulate), or to make
   the receiver believe that a congestion has happened (since congestion
   control MUST be performed before authenticating incoming packets,
   Section 4.3).

Top      Up      ToC       Page 51 
   In order to mitigate these attacks, it is RECOMMENDED to use the
   Group MAC scheme (Section 3.3.3).  No mitigation is possible if a
   group member acts as an attacker with Group MAC.

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

6.2.  Dealing With Replay Attacks

   Replay attacks, whereby an attacker stores a valid message and
   replays it later, can have significant impacts, depending on the
   message type.  Two levels of impacts must be distinguished:

   o  within the TESLA protocol, and

   o  within the ALC or NORM protocol.

6.2.1.  Impacts of Replay Attacks on TESLA

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

   o  bootstrap information: Since most parameters contained in a
      bootstrap information message are static, replay attacks have no
      consequences.  The fact that the "i" and "K_i" fields can be
      updated in subsequent bootstrap information messages does not
      create a problem either, since all "i" and "K_i" fields sent
      remain valid.  Finally, a receiver that successfully initialized
      its TESLA component MUST ignore the following messages (see
      Section 4.2.1 for an exception to this rule), which voids replay
      attacks, unless he missed all the commitments to a new key chain
      (e.g., after a long disconnection) (Section 3.2.1).

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

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

   o  other messages, containing an authentication tag: Replaying a
      packet containing a TESLA authentication tag will never compromise
      the TESLA component itself (but perhaps the underlying ALC or NORM
      component, see below).

   To conclude, TESLA itself is robust in front of replay attacks.

6.2.2.  Impacts of Replay Attacks on NORM

   We review here the potential impacts of a replay attack on the NORM
   component.  Note that we do not consider here the protocols that
   could be used along with NORM, for instance, the congestion control
   protocols.

   First, let us consider replay attacks within a given NORM session.
   NORM defines a "sequence" field that can be used to protect against
   replay attacks [RFC5740] within a given NORM session.  This
   "sequence" field is a 16-bit value that is set by the message
   originator (sender or receiver) as a monotonically increasing number
   incremented with each NORM message transmitted.  It is RECOMMENDED
   that a receiver check this "sequence" field and drop messages
   considered as replayed.  Similarly, it is RECOMMENDED that a sender
   check this sequence, for each known receiver, and drop messages
   considered as replayed.  In both cases, checking this "sequence"
   field SHOULD be done before TESLA processing of the packet: if the
   "sequence" field has not been corrupted, the replay attack will
   immediately be identified; otherwise, the packet will fail the TESLA
   authentication test.  This analysis shows that NORM itself is robust
   in front of replay attacks within the same session.

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

Top      Up      ToC       Page 53 
6.2.3.  Impacts of Replay Attacks on ALC

   We review here the potential impacts of a replay attack on the ALC
   component.  Note that we do not consider here the protocols that
   could be used along with ALC, for instance, the layered or wave-based
   congestion control protocols.

   First, let us consider replay attacks within a given ALC session:

   o  Regular packets containing an authentication tag: a replayed
      message containing an encoding symbol will be detected once
      authenticated, thanks to the object/block/symbol identifiers, and
      will be silently discarded.  This kind of replay attack is only
      penalizing in terms of memory and processing load, but does not
      compromise the ALC behavior.

   o  Control packets containing an authentication tag: ALC control
      packets, by definition, do not include any encoding symbol and
      therefore do not include any object/block/symbol identifier that
      would enable a receiver to identify duplicates.  However, a sender
      has a very limited number of reasons to send control packets.
      More precisely:

      *  At the end of the session, a "Close Session" ("A" flag) packet
         is sent.  Replaying this packet has no impact since the
         receivers already left.

      *  Similarly, replaying a packet containing a "Close Object" ("B"
         flag) has no impact since this object is probably already
         marked as closed by the receiver.

   This analysis shows that ALC itself is robust in front of replay
   attacks within the same session.

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

6.3.  Security of the Back Channel

   As specified in Section 1.1, this specification does not consider the
   packets that may be sent by receivers, for instance, NORM's feedback
   packets.  When a back channel is used, its security is critical to
   the global security, and an appropriate security mechanism MUST be
   used.  [RMT-SIMPLE-AUTH] describes several techniques that can be
   used to that purpose.  However, the authentication and integrity

Top      Up      ToC       Page 54 
   verification of the packets sent by receivers on the back channel, if
   any, is out of the scope of this document.

7.  IANA Considerations

   IANA has registered the following attributes according to this
   document.  The registries are provided by [RFC4442] under the "Timed
   Efficient Stream Loss-tolerant Authentication (TESLA) Parameters"
   registry [TESLA-REG].  Following the policies outlined in [RFC4442],
   the values in the range up to 240 (including 240) for the following
   attributes are assigned after expert review by the MSEC working group
   or its designated successor.  The values in the range from 241 to 255
   are reserved for private use.

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

                    +------------------------+-------+
                    |        PRF name        | Value |
                    +------------------------+-------+
                    |        HMAC-SHA1       |   0   |
                    |      HMAC-SHA-224      |   1   |
                    | HMAC-SHA-256 (default) |   2   |
                    |      HMAC-SHA-384      |   3   |
                    |      HMAC-SHA-512      |   4   |
                    +------------------------+-------+

   Cryptographic Message Authentication Code (MAC) Function, TESLA-MAC:
   All implementations MUST support HMAC-SHA-256 (default).  These MAC
   schemes are used both for the computing of regular MAC and the Group
   MAC (if applicable).

                    +------------------------+-------+
                    |        MAC name        | Value |
                    +------------------------+-------+
                    |        HMAC-SHA1       |   0   |
                    |      HMAC-SHA-224      |   1   |
                    | HMAC-SHA-256 (default) |   2   |
                    |      HMAC-SHA-384      |   3   |
                    |      HMAC-SHA-512      |   4   |
                    +------------------------+-------+

   Furthermore, IANA has created two new registries.  Here also, the
   values in the range up to 240 (including 240) for the following
   attributes are assigned after expert review by the MSEC working group
   or its designated successor.  The values in the range from 241 to 255
   are reserved for private use.

Top      Up      ToC       Page 55 
   Signature Encoding Algorithm, TESLA-SIG-ALGO: All implementations
   MUST support RSASSA-PKCS1-v1_5 (default).

                  +-----------------------------+-------+
                  |   Signature Algorithm Name  | Value |
                  +-----------------------------+-------+
                  |           INVALID           |   0   |
                  | RSASSA-PKCS1-v1_5 (default) |   1   |
                  |          RSASSA-PSS         |   2   |
                  +-----------------------------+-------+

   Signature Cryptographic Function, TESLA-SIG-CRYPTO-FUNC: All
   implementations MUST support SHA-256 (default).

                  +-----------------------------+-------+
                  | Cryptographic Function Name | Value |
                  +-----------------------------+-------+
                  |           INVALID           |   0   |
                  |            SHA-1            |   1   |
                  |           SHA-224           |   2   |
                  |      SHA-256 (default)      |   3   |
                  |           SHA-384           |   4   |
                  |           SHA-512           |   5   |
                  +-----------------------------+-------+

8.  Acknowledgments

   The authors are grateful to Yaron Sheffer, Brian Weis, Ramu
   Panayappan, Ran Canetti, David L. Mills, Brian Adamson, and Lionel
   Giraud for their valuable comments while preparing this document.
   The authors are also grateful to Brian Weis for the digital signature
   details.

9.  References

9.1.  Normative References

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

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

Top      Up      ToC       Page 56 
   [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.

   [RFC5651]          Luby, M., Watson, M., and L. Vicisano, "Layered
                      Coding Transport (LCT) Building Block", RFC 5651,
                      October 2009.

   [RFC5740]          Adamson, B., Bormann, C., Handley, M., and J.
                      Macker, "NACK-Oriented Reliable Multicast (NORM)
                      Transport Protocol", RFC 5740, November 2009.

   [RFC5775]          Luby, M., Watson, M., and L. Vicisano,
                      "Asynchronous Layered Coding (ALC) Protocol
                      Instantiation", RFC 5775, April 2010.

   [TESLA-REG]        "TESLA Parameters IANA Registry",
                       http://www.iana.org.

9.2.  Informative References

   [NTP-NTPv4]        Burbank, J., Kasch, W., Martin, J., Ed., and D.
                      Mills, "The Network Time Protocol Version 4
                      Protocol And Algorithm Specification", Work
                      in Progress, October 2009.

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

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

   [RFC3447]          Jonsson, J. and B. Kaliski, "Public-Key
                      Cryptography Standards (PKCS) #1: RSA Cryptography
                      Specifications Version 2.1", RFC 3447,
                      February 2003.

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

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

   [RFC4359]          Weis, B., "The Use of RSA/SHA-1 Signatures within
                      Encapsulating Security Payload (ESP) and
                      Authentication Header (AH)", RFC 4359,
                      January 2006.

   [RFC4383]          Baugher, M. and E. Carrara, "The Use of Timed
                      Efficient Stream Loss-Tolerant Authentication
                      (TESLA) in the Secure Real-time Transport Protocol
                      (SRTP)", RFC 4383, February 2006.

   [RFC4442]          Fries, S. and H. Tschofenig, "Bootstrapping Timed
                      Efficient Stream Loss-Tolerant Authentication
                      (TESLA)", RFC 4442, March 2006.

   [RMT-FLUTE]        Paila, T., Walsh, R., Luby, M., Lehtonen, R., and
                      V. Roca, "FLUTE - File Delivery over
                      Unidirectional Transport", Work in Progress,
                      August 2009.

   [RMT-SIMPLE-AUTH]  Roca, V., "Simple Authentication Schemes for the
                      ALC and NORM Protocols", Work in Progress,
                      October 2009.

Top      Up      ToC       Page 58 
Authors' Addresses

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

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


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

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


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

   EMail: faurite@lcpc.fr