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 2 of 3, p. 16 to 36
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 16 
3.  Sender Operations

   This section describes the TESLA operations at a sender.  For more
   information on the TESLA protocol and its principles, please refer to
   [RFC4082][Perrig04].

3.1.  TESLA Parameters

3.1.1.  Time Intervals

   The sender divides the time into uniform intervals of duration T_int.
   Time interval numbering starts at 0 and is incremented consecutively.
   The interval index MUST be stored in an unsigned 32-bit integer so
   that wrapping to 0 takes place only after 2^^32 intervals.  For
   instance, if T_int is equal to 0.5 seconds, then wrapping takes place
   after approximately 68 years.

3.1.2.  Key Chains

3.1.2.1.  Principles

   The sender computes a one-way key chain of n_c = N+1 keys, and
   assigns one key from the chain to each interval, consecutively but in
   reverse order.  Key numbering starts at 0 and is incremented
   consecutively, following the time interval numbering: K_0, K_1, ...,
   K_N.

   In order to compute this chain, the sender must first select a
   Primary Key, K_N, and a PRF function, f (Section 7, TESLA-PRF).  The
   randomness of the Primary Key, K_N, is vital to the security and no
   one should be able to guess it.

   The function F is a one-way function that is defined as: F(k) =
   f_k(0), where f_k(0) is the result of the application of the PRF f to
   k and 0.  When f is an HMAC (Section 7), k is used as the key, and 0
   as the message, using the algorithm described in [RFC2104].

Top      Up      ToC       Page 17 
   Similarly, the function F' is a one-way function that is defined as:
   F'(k) = f_k(1), where f_k(1) is the result of the application of the
   same PRF f to k and 1.

   The sender then computes all the keys of the chain, recursively,
   starting with K_N, using: K_{i-1} = F(K_i).  Therefore, K_i = F^{N-
   i}(K_N), where F^i(x) is the execution of function F with the
   argument x, i times.  The receiver can then compute any value in the
   key chain from K_N, even if it does not have intermediate values
   [RFC4082].  The key for MAC calculation can then be derived from the
   corresponding K_i key by K'_i = F'(K_i).

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

3.1.2.2.  Using Multiple Key Chains

   When several key chains are needed, all of them MUST be of the same
   length.  Switching from the current key chain to the next one
   requires that a commitment to the new key chain be communicated in a
   secure way to the receiver.  This can be done by using either an out-
   of-band mechanism or an in-band mechanism.  This document only
   specifies the in-band mechanism.

   < -------- old key chain --------- >||< -------- new key chain --...
   +-----+-----+ .. +-----+-----+-----+||+-----+-----+-----+-----+-----+
      0     1    ..   N-2   N-1    N   ||  N+1   N+2   N+3   N+4   N+5
                                       ||
   Key disclosures:                    ||
     N/A   N/A   ..  K_N-4 K_N-3 K_N-2 || K_N-1  K_N  K_N+1 K_N+2 K_N+3
                    |                  ||            |                 |
                    |< -------------- >||            |< ------------- >|
   Additional key        F(K_N+1)      ||                   K_N
   disclosures        (commitment to   ||              (last key of the
   (in parallel):      the new chain)  ||                 old chain)

       Figure 1: Switching to the Second Key Chain with the In-Band
        Mechanism, Assuming That d=2, n_tx_newkcc=3, n_tx_lastkey=3

Top      Up      ToC       Page 18 
   Figure 1 illustrates the switch to the new key chain, using the in-
   band mechanism.  Let us say that the old key chain stops at K_N and
   the new key chain starts at K_{N+1} (i.e., F(K_{N+1}) and K_N are two
   different keys).  Then, the sender includes the commitment F(K_{N+1})
   to the new key chain into packets authenticated with the old key
   chain (see Section 3.4.5).  This commitment SHOULD be sent during
   n_tx_newkcc time intervals before the end of the old key chain.
   Since several packets are usually sent during an interval, the sender
   SHOULD alternate between sending a disclosed key of the old key chain
   and the commitment to the new key chain.  The details of how to
   alternate between the disclosure and commitment are out of the scope
   of this document.

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

   When the key chain is changed, it becomes impossible to recover a
   previous key from the old key chain.  This is a problem if the
   receiver lost the packets disclosing the last key of the old key
   chain.  A solution consists in re-sending the last key, K_N, of the
   old key chain (see Section 3.4.6).  This SHOULD be done during
   n_tx_lastkey additional time intervals after the end of the time
   interval where K_N is disclosed.  Since several packets are usually
   sent during an interval, the sender SHOULD alternate between sending
   a disclosed key of the new key chain, and the last key of the old key
   chain.  The details of how to alternate between the two disclosures
   are out of the scope of this document.

   In some cases, a receiver having experienced a very long
   disconnection might have lost the commitment of the new chain.
   Therefore, this receiver will not be able to authenticate any packet
   related to the new chain or any of the following ones.  The only
   solution for this receiver to catch up consists in receiving an
   additional bootstrap information message.  This can happen by waiting
   for the next periodic transmission (if sent in-band) or through an
   external mechanism (Section 3.2.1).

3.1.2.3.  Values of the n_tx_lastkey and n_tx_newkcc Parameters

   When several key chains and the in-band commitment mechanism are
   used, a sender MUST initialize the n_tx_lastkey and n_tx_newkcc
   parameters in such a way that no overlapping occurs.  In other words,
   once a sender starts transmitting commitments for a new key chain, he
   MUST NOT send a disclosure for the last key of the old key chain any
   more.  Therefore, the following property MUST be verified:

Top      Up      ToC       Page 19 
      d + n_tx_lastkey + n_tx_newkcc <= N + 1

   It is RECOMMENDED, for robustness purposes, that, once n_tx_lastkey
   has been chosen, then:

      n_tx_newkcc = N + 1 - n_tx_lastkey - d

   In other words, the sender starts transmitting a commitment to the
   following key chain immediately after having sent all the disclosures
   of the last key of the previous key chain.  Doing so increases the
   probability that a receiver gets a commitment for the following key
   chain.

   In any case, these two parameters are sender specific and need not be
   transmitted to the receivers.  Of course, as explained above, the
   sender alternates between the disclosure of a key of the current key
   chain and the commitment to the new key chain (or the last key of the
   old key chain).

3.1.2.4.  The Particular Case of the Session Start

   Since a key cannot be disclosed before the disclosure delay, d, no
   key will be disclosed during the first d time intervals (intervals 0
   and 1 in Figure 1) of the session.  To that purpose, the sender uses
   the Authentication Tag without Key Disclosure, Section 3.4.4.  The
   following key chains, if any, are not concerned since they will
   disclose the last d keys of the previous chain.

3.1.2.5.  Managing Silent Periods

   An ALC or NORM sender may stop transmitting packets for some time.
   For instance, 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 any case, this is an issue since the authentication of
   the packets sent during the last d intervals requires that the
   associated keys be disclosed, which will take place during d
   additional time intervals.

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

Top      Up      ToC       Page 20 
3.1.3.  Time Interval Schedule

   The sender must determine the following parameters:

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

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

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

   o  N, the length of a key chain.

   The correct choice of T_int, d, and N is crucial for the efficiency
   of the scheme.  For instance, a T_int * d product that is too long
   will cause excessive delay in the authentication process.  A T_int *
   d product that is too short prevents many receivers from verifying
   packets.  An N * T_int product that is too small will cause the
   sender to switch too often to new key chains.  An N that is too long
   with respect to the expected session duration (if known) will require
   the sender to compute too many useless keys.  Sections 3.2 and 3.6 of
   [RFC4082] give general guidelines for initializing these parameters.

   The T_0, T_int, d, and N parameters MUST NOT be changed during the
   lifetime of the session.  This restriction is meant to prevent
   introducing vulnerabilities.  For instance, if a sender was
   authorized to change the key disclosure schedule, a receiver that did
   not receive the change notification would still believe in the old
   key disclosure schedule, thereby creating vulnerabilities [RFC4082].

3.1.4.  Timing Parameters

   In indirect time synchronization mode, the sender must determine the
   following parameter:

   o  D^O_t, the upper bound of the lag of the sender's clock with
      respect to the time reference.

   The D^O_t parameter MUST NOT be changed during the lifetime of the
   session.

Top      Up      ToC       Page 21 
3.2.  TESLA Signaling Messages

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

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

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

3.2.1.  Bootstrap Information

   In order to initialize the TESLA component at a receiver, the sender
   must communicate some key information in a secure way.  This
   information can be sent in-band or out-of-band, as discussed in
   Section 2.2.  In this section, we only consider the in-band scheme.

   The TESLA bootstrap information message MUST be digitally signed
   (Section 3.3.2).  The goal is to enable a receiver to check the
   packet source and packet integrity.  Then, the bootstrap information
   can be:

   o  unicast to a receiver during a direct time synchronization
      request/response exchange;

   o  broadcast to all receivers.  This is typically the case in
      indirect time synchronization mode.  It can also be used in direct
      time synchronization mode, for instance, when a large number of
      clients arrive at the same time, in which case it is more
      efficient to answer globally.

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

   A periodic broadcast of the bootstrap information message could also
   be useful when:

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

Top      Up      ToC       Page 22 
   o  some clients experience an intermittent connectivity.  This is
      particularly important when several key chains are used in an ALC
      or NORM session, since there is a risk that a receiver loses 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 period of a few seconds for the
   transmission of this bootstrap information is often a reasonable
   value.

3.2.2.  Direct Time Synchronization Response

   In direct time synchronization, upon receipt of a synchronization
   request, the sender records its local time, t_s, and sends a response
   message that contains both t_r and t_s (Section 2.4.1).  This message
   is unicast to the receiver.  This direct time synchronization
   response message MUST be digitally signed in order to enable a
   receiver to check the packet source and packet integrity
   (Section 3.3.2).  The receiver MUST also be able to associate this
   response and his request, which is the reason why t_r is included in
   the response message.

3.3.  TESLA Authentication Information

   At a sender, TESLA produces three types of security tags:

   o  an authentication tag, in case of data packets, and which contains
      the MAC of the packet;

   o  a digital signature, in case of one of the two TESLA signaling
      packets, namely a bootstrap information message or a direct time
      synchronization response; and

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

   Because of interdependencies, their computation MUST follow a strict
   order:

   o  first of all, compute the authentication tag (with data packet) or
      the digital signature (with signaling packet);

   o  finally, compute the Group Mac.

Top      Up      ToC       Page 23 
3.3.1.  Authentication Tags

   All the data packets sent MUST have an authentication tag containing:

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

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

   o  either a disclosed key (which belongs to the current key chain or
      the previous key chain), or a commitment to a new key chain, or no
      key at all.

   The computation of MAC(K'_i, M) 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 "MAC(K'_i, M)" field of the authentication tag MUST
   be set to 0.

3.3.2.  Digital Signatures

   The bootstrap information message (with the in-band bootstrap scheme)
   and direct time synchronization response message (with the indirect
   time synchronization scheme) both need to be signed by the sender.
   These two messages contain a "Signature" field to hold the digital
   signature.  The bootstrap information message also contains the
   "Signature Encoding Algorithm", the "Signature Cryptographic
   Function", and the "Signature Length" fields that enable a receiver
   to process the "Signature" field.  Note that there are no such
   "Signature Encoding Algorithm", "Signature Cryptographic Function",
   and "Signature Length" fields in the case of a direct time
   synchronization response message since it is assumed that these
   parameters are already known (i.e., the receiver either received a
   bootstrap information message before or these values have been
   communicated out-of-band).

   Several "Signature Encoding Algorithms" can be used, including
   RSASSA-PKCS1-v1_5, the default, and RSASSA-PSS (Section 7).  With
   these encodings, SHA-256 is the default "Signature Cryptographic
   Function".

   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, since this Group MAC is calculated later.

Top      Up      ToC       Page 24 
   More specifically, from [RFC4359]: Digital signature generation is
   performed as described in [RFC3447], Section 8.2.1 for RSASSA-PKCS1-
   v1_5 and Section 8.1.1 for RSASSA-PSS.  The authenticated portion of
   the packet is used as the message M, which is passed to the signature
   generation function.  The signer's RSA private key is passed as K.
   In summary, (when SHA-256 is used), the signature generation process
   computes a SHA-256 hash of the authenticated packet bytes, signs the
   SHA-256 hash using the private key, and encodes the result with the
   specified RSA encoding type.  This process results in a value S,
   which is the digital signature to be included in the packet.

   With RSASSA-PKCS1-v1_5 and RSASSA-PSS signatures, the size of the
   signature is equal to the "RSA modulus", unless the "RSA modulus" is
   not a multiple of 8 bits.  In that case, the signature MUST be
   prepended with between 1 and 7 bits set to zero such that the
   signature is a multiple of 8 bits [RFC4359].  The key size, which in
   practice is also equal to the "RSA modulus", has major security
   implications.  [RFC4359] explains how to choose this value depending
   on the maximum expected lifetime of the session.  This choice is out
   of the scope of this document.

3.3.3.  Group MAC Tags

   An optional Group MAC can be used to mitigate Denial-of-Service (DoS)
   attacks coming from attackers that are not group members [RFC4082].
   This feature assumes that a group key, K_g, is shared by the sender
   and all receivers.  When the attacker is not a group member, the
   benefits of adding a Group MAC to every packet sent are threefold:

   o  a receiver can immediately drop faked packets, without having to
      wait for the disclosure delay, d;

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

   o  a receiver can immediately drop faked direct time synchronization
      response and bootstrap messages, without having to verify the
      digital signature, a computation-intensive task.

   The computation of the Group MAC, MAC(K_g, M), 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 "Group MAC" field MUST be set to 0.  However,
   the digital signature (e.g., of a bootstrap message) and the "MAC"
   fields (e.g., of an authentication tag), when present, MUST have been

Top      Up      ToC       Page 25 
   calculated since they are included in the Group MAC calculation
   itself.  Then, the sender truncates the MAC output to keep the n_w
   most significant bits and stores the result in the "Group MAC" field.

   This scheme features a few limits:

   o  it is of no help if a group member (who knows K_g) impersonates
      the sender and sends forged messages to other receivers;

   o  it requires an additional MAC computing for each packet, both at
      the sender and receiver sides;

   o  it increases the size of the TESLA authentication headers.  In
      order to limit this problem, the length of the truncated output of
      the MAC, n_w, SHOULD be kept small (e.g., 32 bits) (see [RFC3711],
      Section 9.5).  As a side effect, the authentication service is
      significantly weakened: the probability of any forged packet being
      successfully authenticated becomes one in 2^32.  Since the Group
      MAC check is only a pre-check that must be followed by the
      standard TESLA authentication check, this is not considered to be
      an issue.

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

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

3.4.  Format of TESLA Messages and Authentication Tags

   This section specifies the format of the various kinds of TESLA
   messages and authentication tags sent by the session's sender.
   Because these TESLA messages are carried as EXT_AUTH Header
   Extensions of the ALC or NORM packets (Section 5), the following
   formats do not start on 32-bit word boundaries.

Top      Up      ToC       Page 26 
3.4.1.  Format of a Bootstrap Information Message

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

   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
                                                  +-+-+-+-+-+-+-+-+  ---
                                                  | V |resvd|S|G|A|  ^
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
  |       d       |    PRF Type   | MAC Func Type |Gr MAC Fun Type|  | f
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  | i
  |   SigEncAlgo  | SigCryptoFunc |       Signature Length        |  | x
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  | e
  |            Reserved           |             T_int             |  | d
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
  |                                                               |  | l
  +                  T_0 (NTP timestamp format)                   +  | e
  |                                                               |  | n
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  | g
  |                      N (Key Chain Length)                     |  | t
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  | h
  |                    Current Interval Index i                   |  v
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  ---
  |                                                               |
  ~                 Current Key Chain Commitment  +-+-+-+-+-+-+-+-+
  |                                               |   Padding     |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  +                                                               +
  ~                           Signature                           ~
  +                                               +-+-+-+-+-+-+-+-+
  |                                               |    Padding    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |P|                                                             |
  +-+       D^O_t Extension (optional, present if A==1)           +
  |    (NTP timestamp diff, positive if P==1, negative if P==0)   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  ~                      Group MAC (optional)                     ~
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 2: Bootstrap Information Format

Top      Up      ToC       Page 27 
   The format of the bootstrap information is depicted in Figure 2.  The
   fields are:

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

      The "V" field contains the version number of the protocol.  For
      this specification, the value of 0 MUST be used.

   "Reserved" field (3 bits):

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

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

      The "S" flag indicates whether this TESLA session is restricted to
      a single key chain (S==1) or relies on one or multiple key chains
      (S==0).

   "G" (Group MAC Present) flag (1 bit):

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

   "A" flag (1 bit):

      The "A" flag indicates whether the "P" flag and "D^O_t" fields are
      present (A==1) or not (A==0).  In indirect time synchronization
      mode, A MUST be equal to 1 since these fields are needed.

   "d" field (8 bits):

      "d" is an unsigned integer that defines the key disclosure delay
      (in number of intervals). d MUST be greater than or equal to 2.

   "PRF Type" field (8 bits):

      The "PRF Type" is the reference number of the f function used to
      derive the F (for key chain) and F' (for MAC keys) functions
      (Section 7).

   "MAC Function Type" field (8 bits):

      The "MAC Function Type" is the reference number of the function
      used to compute the MAC of the packets (Section 7).

Top      Up      ToC       Page 28 
   "Group MAC Function Type" field (8 bits):

      When G==1, this field contains the reference number of the
      cryptographic MAC function used to compute the Group MAC
      (Section 7).  When G==0, this field MUST be set to zero.

   "Signature Encoding Algorithm" field (8 bits):

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

   "Signature Cryptographic Function" field (8 bits):

      The "Signature Cryptographic Function" is the reference number
      (Section 7) of the cryptographic function used within the digital
      signature.

   "Signature Length" field (16 bits):

      The "Signature Length" is an unsigned integer that indicates the
      "Signature" field size in bytes in the "Signature Extension"
      field.  This is also the signature key length, since both
      parameters are equal.

   "Reserved" fields (16 bits):

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

   "T_int" field (16 bits):

      "T_int" is an unsigned 16-bit integer that defines the interval
      duration (in milliseconds).

   "T_0" field (64 bits):

      "T_0" is a timestamp in NTP timestamp format that indicates the
      beginning of the session, i.e., the beginning of time interval 0.

   "N" field (32 bits):

      "N" is an unsigned integer that indicates the key chain length.
      There are N + 1 keys per chain.

Top      Up      ToC       Page 29 
   "i" (Interval Index of K_i) field (32 bits):

      "i" is an unsigned integer that indicates the current interval
      index when this bootstrap information message is sent.

   "Current Key Chain Commitment" field (variable size, padded if
   necessary for 32-bit word alignment):

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

   "Signature" field (variable size, padded if necessary for 32-bit word
   alignment):

      The "Signature" field is mandatory.  It contains a digital
      signature of this message, as specified by the encoding algorithm,
      cryptographic function, and key length parameters.  If the
      signature length is not a multiple of 32 bits, this field is
      padded with 0.

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

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

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

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

Top      Up      ToC       Page 30 
   "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).

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

   In order to prevent attacks, some parameters MUST NOT be changed
   during the lifetime of the session (Sections 3.1.3 and 3.1.4).  The
   following table summarizes the parameter's status:

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

Top      Up      ToC       Page 31 
3.4.2.  Format of a Direct Time Synchronization Response

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

        Figure 3: Format of a Direct Time Synchronization Response

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

   "Reserved" field (8 bits):

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

   "t_s" (NTP timestamp, 64 bits):

      "t_s" is a timestamp in NTP timestamp format 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 a timestamp in NTP timestamp format that contains the
      receiver local time value received in the direct time
      synchronization request message.

Top      Up      ToC       Page 32 
   "Signature" field (variable size, padded if necessary for 32-bit word
   alignment):

      The "Signature" field is mandatory.  It contains a digital
      signature of this message, as specified by the encoding algorithm,
      cryptographic function, and key length parameters communicated in
      the bootstrap information message (if applicable) or out-of-band.
      If the signature length is not a multiple of 32 bits, this field
      is padded with 0.

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

3.4.3.  Format of a Standard Authentication Tag

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

            Figure 4: Format of the Standard Authentication Tag

   A Standard Authentication Tag is composed of the following fields:

   "Reserved" field (8 bits):

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

Top      Up      ToC       Page 33 
   "i" (Interval Index) field (32 bits):

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

   "Disclosed Key" (variable size, non padded):

      The "Disclosed Key" is the key used for interval i-d: K_{i-d}.
      There is no padding between the "Disclosed Key" and "MAC(K'_i, M)"
      fields, and the latter MAY not start on a 32-bit boundary,
      depending on the n_p parameter.

   "MAC(K'_i, M)" (variable size, padded if necessary for 32-bit word
   alignment):

      "MAC(K'_i, M)" is the truncated message authentication code of the
      current packet.  Only the n_m most significant bits of the MAC
      output are kept [RFC2104].

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

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

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

3.4.4.  Format of an Authentication Tag without Key Disclosure

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

Top      Up      ToC       Page 34 
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                                    +-+-+-+-+-+-+-+-+
                                                    |   Reserved    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                i (Interval Index of K'_i)                     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    ~                       MAC(K'_i, M)            +-+-+-+-+-+-+-+-+
    |                                               |   Padding     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                     Group MAC (optional)                      ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Figure 5: Format of the Authentication Tag without Key Disclosure

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

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

   Note that since there is no padding between the "F(K_{N+1})" and
   "MAC(K'_i, M)" fields, the latter MAY not start on a 32-bit boundary,
   depending on the n_p parameter.

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

                Figure 6: Format of the Authentication Tag
                      with a New Key Chain Commitment

3.4.6.  Format of an Authentication Tag with a "Last Key of Old Chain"
        Disclosure

   During the first n_tx_lastkey intervals of the new key chain after
   the disclosing interval, d, the sender SHOULD disclose the last key
   of the old key chain.  This is done by replacing the disclosed key of
   the Authentication Tag with the Last Key of the Old Chain, K_N (or
   K_{2N+1} in case of a switch between the second and third key chains,
   etc.).  Figure 7 shows the corresponding format.

   Note that since there is no padding between the "K_N" and "MAC(K'_i,
   M)" fields, the latter MAY not start on a 32-bit boundary, depending
   on the n_p parameter.

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

                Figure 7: Format of the Authentication Tag
                   with an Old Chain Last Key Disclosure



(page 36 continued on part 3)

Next RFC Part