Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 5776

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

Pages: 58
Experimental
Errata
Part 2 of 3 – Pages 16 to 36
First   Prev   Next

Top   ToC   RFC5776 - Page 16   prevText

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   ToC   RFC5776 - 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   ToC   RFC5776 - 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   ToC   RFC5776 - 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   ToC   RFC5776 - 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   ToC   RFC5776 - 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   ToC   RFC5776 - 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   ToC   RFC5776 - 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   ToC   RFC5776 - 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   ToC   RFC5776 - 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   ToC   RFC5776 - 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   ToC   RFC5776 - 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   ToC   RFC5776 - 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   ToC   RFC5776 - 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   ToC   RFC5776 - 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   ToC   RFC5776 - 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   ToC   RFC5776 - 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   ToC   RFC5776 - 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   ToC   RFC5776 - 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   ToC   RFC5776 - 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   ToC   RFC5776 - 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 Section