part of this architecture, and can be used as a so-called
Registration protocol. The main entities involved in the
architecture are the group controller/key server (GCKS), the
receiver(s), and the sender(s).
In MIKEY, the sender could act as GCKS and push keys down to the
receiver(s).
Note that, for example, in a SIP-initiated call, the sender may also
be a receiver. As MIKEY addresses small interactive groups, a member
may dynamically change between being a sender and receiver (or being
both simultaneously).
3. Basic Key Transport and Exchange Methods
The following sub-sections define three different methods of
transporting/establishing a TGK: with the use of a pre-shared key,
public-key encryption, and Diffie-Hellman (DH) key exchange. In the
following, we assume unicast communication for simplicity. In
addition to the TGK, a random "nonce", denoted RAND, is also
transported. In all three cases, the TGK and RAND values are then
used to derive TEKs as described in Section 4.1.3. A timestamp is
also sent to avoid replay attacks (see Section 5.4).
The pre-shared key method and the public-key method are both based on
key transport mechanisms, where the actual TGK is pushed (securely)
to the recipient(s). In the Diffie-Hellman method, the actual TGK is
instead derived from the Diffie-Hellman values exchanged between the
peers.
The pre-shared case is, by far, the most efficient way to handle the
key transport due to the use of symmetric cryptography only. This
approach also has the advantage that only a small amount of data has
to be exchanged. Of course, the problematic issue is scalability as
it is not always feasible to share individual keys with a large group
of peers. Therefore, this case mainly addresses scenarios such as
server-to-client and also those cases where the public-key modes have
already been used, thus allowing for the "cache" of a symmetric key
(see below and Section 3.2).
Public-key cryptography can be used to create a scalable system. A
disadvantage with this approach is that it is more resource consuming
than the pre-shared key approach. Another disadvantage is that in
most cases, a PKI (Public Key Infrastructure) is needed to handle the
distribution of public keys. Of course, it is possible to use public
keys as pre-shared keys (e.g., by using self-signed certificates).
It should also be noted that, as mentioned above, this method may be
used to establish a "cached" symmetric key that later can be used to
establish subsequent TGKs by using the pre-shared key method (hence,
the subsequent request can be executed more efficiently).
In general, the Diffie-Hellman (DH) key agreement method has a higher
resource consumption (both computationally and in bandwidth) than the
previous ones, and needs certificates as in the public-key case.
However, it has the advantage of providing perfect forward secrecy
(PFS) and flexibility by allowing implementation in several different
finite groups.
Note that by using the DH method, the two involved parties will
generate a unique unpredictable random key. Therefore, it is not
possible to use this DH method to establish a group TEK (as the
different parties in the group would end up with different TEKs). It
is not the intention of the DH method to work in this scenario, but
to be a good alternative in the special peer-to-peer case.
The following general notation is used:
HDR: The general MIKEY header, which includes MIKEY CSB related data
(e.g., CSB ID) and information mapping to the specific security
protocol used. See Section 6.1 for payload definition.
T: The timestamp, used mainly to prevent replay attacks. See
Section 6.6 for payload definition and also Section 5.4 for other
timestamp related information.
IDx: The identity of entity x (IDi=Initiator, IDr=Responder). See
Section 6.7 for payload definition.
RAND: Random/pseudo-random byte-string, which is always included in
the first message from the Initiator. RAND is used as a freshness
value for the key generation. It is not included in update messages
of a CSB. See Section 6.11 for payload definition. For randomness
recommendations for security, see [RAND].
SP: The security policies for the data security protocol. See
Section 6.10 for payload definition.
3.1. Pre-shared key
In this method, the pre-shared secret key, s, is used to derive key
material for both the encryption (encr_key) and the integrity
protection (auth_key) of the MIKEY messages, as described in Section
4.1.4. The encryption and authentication transforms are described in
Section 4.2.
Initiator Responder
I_MESSAGE =
HDR, T, RAND, [IDi],[IDr],
{SP}, KEMAC --->
R_MESSAGE =
[<---] HDR, T, [IDr], V
The main objective of the Initiator’s message (I_MESSAGE) is to
transport one or more TGKs (carried into KEMAC) and a set of security
parameters (SPs) to the Responder in a secure manner. As the
verification message from the Responder is optional, the Initiator
indicates in the HDR whether it requires a verification message or
not from the Responder.
KEMAC = E(encr_key, {TGK}) || MAC
The KEMAC payload contains a set of encrypted sub-payloads and a MAC.
Each sub-payload includes a TGK randomly and independently chosen by
the Initiator (and other possible related parameters, e.g., the key
lifetime). The MAC is a Message Authentication Code covering the
entire MIKEY message using the authentication key, auth_key. See
Section 6.2 for payload definition and Section 5.2 for an exact
definition of the MAC calculation.
The main objective of the verification message from the Responder is
to obtain mutual authentication. The verification message, V, is a
MAC computed over the Responder’s entire message, the timestamp (the
same as the one that was included in the Initiator’s message), and
the two parties identities, using the authentication key. See also
Section 5.2 for the exact definition of the Verification MAC
calculation and Section 6.9 for payload definition.
The ID fields SHOULD be included, but they MAY be left out when it
can be expected that the peer already knows the other party’s ID
(otherwise it cannot look up the pre-shared key). For example, this
could be the case if the ID is extracted from SIP.
It is MANDATORY to implement this method.
3.2. Public-key encryption
Initiator Responder
I_MESSAGE =
HDR, T, RAND, [IDi|CERTi], [IDr], {SP},
KEMAC, [CHASH], PKE, SIGNi --->
R_MESSAGE =
[<---] HDR, T, [IDr], V
As in the previous case, the main objective of the Initiator’s
message is to transport one or more TGKs and a set of security
parameters to the Responder in a secure manner. This is done using
an envelope approach where the TGKs are encrypted (and integrity
protected) with keys derived from a randomly/pseudo-randomly chosen
"envelope key". The envelope key is sent to the Responder encrypted
with the public key of the Responder.
The PKE contains the encrypted envelope key: PKE = E(PKr, env_key).
It is encrypted using the Responder’s public key (PKr). If the
Responder possesses several public keys, the Initiator can indicate
the key used in the CHASH payload (see Section 6.8).
The KEMAC contains a set of encrypted sub-payloads and a MAC:
KEMAC = E(encr_key, IDi || {TGK}) || MAC
The first payload (IDi) in KEMAC is the identity of the Initiator
(not a certificate, but generally the same ID as the one specified in
the certificate). Each of the following payloads (TGK) includes a
TGK randomly and independently chosen by the Initiator (and possible
other related parameters, e.g., the key lifetime). The encrypted
part is then followed by a MAC, which is calculated over the KEMAC
payload. The encr_key and the auth_key are derived from the envelope
key, env_key, as specified in Section 4.1.4. See also Section 6.2
for payload definition.
The SIGNi is a signature covering the entire MIKEY message, using the
Initiator’s signature key (see also Section 5.2 for the exact
definition).
The main objective of the verification message from the Responder is
to obtain mutual authentication. As the verification message V from
the Responder is optional, the Initiator indicates in the HDR whether
it requires a verification message or not from the Responder. V is
calculated in the same way as in the pre-shared key mode (see also
Section 5.2 for the exact definition). See Section 6.9 for payload
definition.
Note that there will be one encrypted IDi and possibly also one
unencrypted IDi. The encrypted one is used together with the MAC as
a countermeasure for certain man-in-the-middle attacks, while the
unencrypted one is always useful for the Responder to immediately
identify the Initiator. The encrypted IDi MUST always be verified to
be equal with the expected IDi.
It is possible to cache the envelope key, so that it can be used as a
pre-shared key. It is not recommended for this key to be cached
indefinitely (however it is up to the local policy to decide this).
This function may be very convenient during the lifetime of a CSB, if
a new crypto session needs to be added (or an expired one removed).
Then, the pre-shared key can be used, instead of the public keys (see
also Section 4.5). If the Initiator indicates that the envelope key
should be cached, the key is at least to be cached during the
lifetime of the entire CSB.
The cleartext ID fields and certificate SHOULD be included, but they
MAY be left out when it can be expected that the peer already knows
the other party’s ID, or can obtain the certificate in some other
manner. For example, this could be the case if the ID is extracted
from SIP.
For certificate handling, authorization, and policies, see Section
4.3.
It is MANDATORY to implement this method.
3.3. Diffie-Hellman key exchange
For a fixed, agreed upon, cyclic group, (G,*), we let g denote a
generator for this group. Choices for the parameters are given in
Section 4.2.7. The other transforms below are described in Section
4.2.
This method creates a DH-key, which is used as the TGK. This method
cannot be used to create group keys; it can only be used to create
single peer-to-peer keys. It is OPTIONAL to implement this method.
Initiator Responder
I_MESSAGE =
HDR, T, RAND, [IDi|CERTi],[IDr]
{SP}, DHi, SIGNi --->
R_MESSAGE =
<--- HDR, T, [IDr|CERTr], IDi,
DHr, DHi, SIGNr
The main objective of the Initiator’s message is to, in a secure way,
provide the Responder with its DH value (DHi) g^(xi), where xi MUST
be randomly/pseudo-randomly and secretly chosen, and a set of
security protocol parameters.
The SIGNi is a signature covering the Initiator’s MIKEY message,
I_MESSAGE, using the Initiator’s signature key (see Section 5.2 for
the exact definition).
The main objective of the Responder’s message is to, in a secure way,
provide the Initiator with the Responder’s value (DHr) g^(xr), where
xr MUST be randomly/pseudo-randomly and secretly chosen. The
timestamp that is included in the answer is the same as the one
included in the Initiator’s message.
The SIGNr is a signature covering the Responder’s MIKEY message,
R_MESSAGE, using the Responder’s signature key (see Section 5.2 for
the exact definition).
The DH group parameters (e.g., the group G, the generator g) are
chosen by the Initiator and signaled to the Responder. Both parties
calculate the TGK, g^(xi*xr) from the exchanged DH-values.
Note that this approach does not require that the Initiator has to
possess any of the Responder’s certificates before the setup.
Instead, it is sufficient that the Responder includes its signing
certificate in the response.
The ID fields and certificate SHOULD be included, but they MAY be
left out when it can be expected that the peer already knows the
other party’s ID (or can obtain the certificate in some other
manner). For example, this could be the case if the ID is extracted
from SIP.
For certificate handling, authorization, and policies, see Section
4.3.
4. Selected Key Management Functions
MIKEY manages symmetric keys in two main ways. First, following key
transport or key exchange of TGK(s) (and other parameters) as defined
by any of the above three methods, MIKEY maintains a mapping between
Data SA identifiers and Data SAs, where the identifiers used depend
on the security protocol in question, see Section 4.4. Thus, when
the security protocol requests a Data SA, given such a Data SA
identifier, an up-to-date Data SA will be obtained. In particular,
correct keying material, TEK(s), might need to be derived. The
derivation of TEK(s) (and other keying material) is done from a TGK
and is described in Section 4.1.3.
Second, for use within MIKEY itself, two key management procedures
are needed:
* in the pre-shared case, deriving encryption and authentication key
material from a single pre-shared key, and
* in the public key case, deriving similar key material from the
transported envelope key.
These two key derivation methods are specified in section 4.1.4.
All the key derivation functionality mentioned above is based on a
pseudo-random function, defined next.
4.1. Key Calculation
In the following, we define a general method (pseudo-random function)
to derive one or more keys from a "master" key. This method is used
to derive:
* TEKs from a TGK and the RAND value,
* encryption, authentication, or salting key from a pre-shared/
envelope key and the RAND value.
4.1.1. Assumptions
We assume that the following parameters are in place:
csb_id : Crypto Session Bundle ID (32-bits unsigned integer)
cs_id : the Crypto Session ID (8-bits unsigned integer)
RAND : (at least) 128-bit (pseudo-)random bit-string sent by the
Initiator in the initial exchange.
The key derivation method has the following input parameters:
inkey : the input key to the derivation function
inkey_len : the length in bits of the input key
label : a specific label, dependent on the type of the key to be
derived, the RAND, and the session IDs
outkey_len: desired length in bits of the output key.
The key derivation method has the following output:
outkey: the output key of desired length.
4.1.2. Default PRF Description
Let HMAC be the SHA-1 based message authentication function, see
[HMAC] [SHA-1]. Similarly to [TLS], we define:
P (s, label, m) = HMAC (s, A_1 || label) ||
HMAC (s, A_2 || label) || ...
HMAC (s, A_m || label)
where
A_0 = label,
A_i = HMAC (s, A_(i-1))
s is a key (defined below)
m is a positive integer (also defined below).
Values of label depend on the case in which the PRF is invoked, and
values are specified in the following for the default PRF. Thus,
note that other PRFs later added to MIKEY MAY specify different input
parameters.
The following procedure describes a pseudo-random function, denoted
PRF(inkey,label), based on the above P-function, applied to compute
the output key, outkey:
* let n = inkey_len / 256, rounded up to the nearest integer if not
already an integer
* split the inkey into n blocks, inkey = s_1 || ... || s_n, where *
all s_i, except possibly s_n, are 256 bits each
* let m = outkey_len / 160, rounded up to the nearest integer if not
already an integer
(The values "256" and "160" equals half the input block-size and full
output hash size, respectively, of the SHA-1 hash as part of the P-
function.)
Then, the output key, outkey, is obtained as the outkey_len most
significant bits of
PRF(inkey, label) = P(s_1, label, m) XOR P(s_2, label, m) XOR ...
XOR P(s_n, label, m).
4.1.3. Generating keys from TGK
In the following, we describe how keying material is derived from a
TGK, thus assuming that a mapping of the Data SA identifier to the
correct TGK has already been done according to Section 4.4.
The key derivation method SHALL be executed using the above PRF with
the following input parameters:
inkey : TGK
inkey_len : bit length of TGK
label : constant || cs_id || csb_id || RAND
outkey_len : bit length of the output key.
The constant part of label depends on the type of key that is to be
generated. The constant 0x2AD01C64 is used to generate a TEK from
TGK. If the security protocol itself does not support key derivation
for authentication and encryption from the TEK, separate
authentication and encryption keys MAY be created directly for the
security protocol by replacing 0x2AD01C64 with 0x1B5C7973 and
0x15798CEF respectively, and outkey_len by the desired key-length(s)
in each case.
A salt key can be derived from the TGK as well, by using the constant
0x39A2C14B. Note that the Key data sub-payload (Section 6.13) can
carry a salt. The security protocol in need of the salt key SHALL
use the salt key carried in the Key data sub-payload (in the pre-
shared and public-key case), when present. If that is not sent, then
it is possible to derive the salt key via the key derivation
function, as described above.
The table below summarizes the constant values, used to generate keys
from a TGK.
constant | derived key from the TGK
--------------------------------------
0x2AD01C64 | TEK
0x1B5C7973 | authentication key
0x15798CEF | encryption key
0x39A2C14B | salting key
Table 4.1.3: Constant values for the derivation of keys from TGK.
Note that these 32-bit constant values (listed in the table above)
are taken from the decimal digits of e (i.e., 2.7182...), where each
constant consists of nine decimal digits (e.g., the first nine
decimal digits 718281828 = 0x2AD01C64). The strings of nine
decimal digits are not chosen at random, but as consecutive "chunks"
from the decimal digits of e.
4.1.4. Generating keys for MIKEY messages from an envelope/pre-shared
key
This derivation is to form the symmetric encryption key (and salting
key) for the encryption of the TGK in the pre-shared key and public
key methods. This is also used to derive the symmetric key used for
the message authentication code in these messages, and the
corresponding verification messages. Hence, this derivation is
needed in order to get different keys for the encryption and the MAC
(and in the case of the pre-shared key, it will result in fresh key
material for each new CSB). The parameters for the default PRF are
here:
inkey : the envelope key or the pre-shared key
inkey_len : the bit length of inkey
label : constant || 0xFF || csb_id || RAND
outkey_len : desired bit length of the output key.
The constant part of label depends on the type of key that is to be
generated from an envelope/pre-shared key, as summarized below.
constant | derived key
--------------------------------------
0x150533E1 | encryption key
0x2D22AC75 | authentication key
0x29B88916 | salt key
Table 4.1.4: Constant values for the derivation of keys from an
envelope/pre-shared key.
4.2. Pre-defined Transforms and Timestamp Formats
This section identifies default transforms for MIKEY. It is
mandatory to implement and support the following transforms in the
respective case. New transforms can be added in the future (see
Section 4.2.9 for further guidelines).
4.2.1. Hash functions
In MIKEY, it is MANDATORY to implement SHA-1 as the default hash
function.
4.2.2. Pseudo-random number generator and PRF
A cryptographically secure random or pseudo-random number generator
MUST be used for the generation of the keying material and nonces,
e.g., [BMGL]. However, which one to use is implementation specific
(as the choice will not affect the interoperability).
For the key derivations, it is MANDATORY to implement the PRF
specified in Section 4.1. Other PRFs MAY be added by writing
standard-track RFCs specifying the PRF constructions and their exact
use within MIKEY.
4.2.3. Key data transport encryption
The default and mandatory-to-implement key transport encryption is
AES in counter mode, as defined in [SRTP], using a 128-bit key as
derived in Section 4.1.4, SRTP_PREFIX_LENGTH set to zero, and using
the initialization vector
IV = (S XOR (0x0000 || CSB ID || T)) || 0x0000,
where S is a 112-bit salting key, also derived as in Section 4.1.4,
and where T is the 64-bit timestamp sent by the Initiator.
Note: this restricts the maximum size that can be encrypted to 2^23
bits, which is still enough for all practical purposes [SRTP].
The NULL encryption algorithm (i.e., no encryption) can be used (but
implementation is OPTIONAL). Note that this MUST NOT be used unless
the underlying protocols can guarantee security. The main reason for
including this is for specific SIP scenarios, where SDP is protected
end-to-end. For this scenario, MIKEY MAY be used with the pre-shared
key method, the NULL encryption, and NULL authentication algorithm
(see Section 4.2.4) while relying on the security of SIP. Use this
option with caution!
The AES key wrap function [AESKW] is included as an OPTIONAL
implementation method. If the key wrap function is used in the
public key method, the NULL MAC is RECOMMENDED to be used, as the key
wrap itself will provide integrity of the encrypted content (note
though that the NULL MAC SHOULD NOT be used in the pre-shared key
case, as the MAC in that case covers the entire message). The 128-
bit key and a 64-bit salt, S, are derived in accordance to Section
4.1.4 and the key wrap IV is then set to S.
4.2.4. MAC and Verification Message function
MIKEY uses a 160-bit authentication tag, generated by HMAC with SHA-1
as the MANDATORY implementation method, see [HMAC]. Authentication
keys are derived according to Section 4.1.4. Note that the
authentication key size SHOULD be equal to the size of the hash
function’s output (e.g., for HMAC-SHA-1, a 160-bit authentication key
is used) [HMAC].
The NULL authentication algorithm (i.e., no MAC) can be used together
with the NULL encryption algorithm (but implementation is OPTIONAL).
Note that this MUST NOT be used unless the underlying protocols can
guarantee security. The main reason for including this is for
specific SIP scenarios, where SDP is protected end-to-end. For this
scenario, MIKEY MAY be used with the pre-shared key method and the