Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols
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 Disclosure3.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 Commitment3.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.