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].
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
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:
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).
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.
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;
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.
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.
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
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.
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
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).
"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.
"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.
"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 |
+--------------------------+----------------------------------------+
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.
"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.
"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).
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.
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.
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)