authenticated message (the hash of the message is 20 bytes). This
implies that it is possible to cache approximately 204 messages. If
the expected number of messages per minute can be estimated, the
clock skew can easily be calculated. For example, in a SIP scenario
where the client is expected, in the most extreme case, to receive 10
calls per minute, the clock skew needed is then approximately 20
minutes. In a not so extreme setting, where one could expect an
incoming call every 5th minute, this would result in a clock skew on
the order of 16.5 hours (approx 1000 minutes).
Consider a very extreme case, where the maximum number of incoming
messages are assumed to be on the order of 120 messages per minute,
and a requirement that the clock skew is on the order of 10 minutes,
a 48kB replay cache would be required.
Hence, one can note that the required clock skew will depend largely
on the setting in which MIKEY is used. One recommendation is to fix
a size for the replay cache, allowing the clock skew to be large (the
initial clock skew can be set depending on the application in which
it is used). As the replay cache grows, the clock skew is decreased
depending on the percentage of the used replay cache. Note that this
is locally handled, which will not require interaction with the peer
(even though it may indirectly effect the peer). However, exactly
how to implement such functionality is out of the scope of this
document and considered implementation specific.
In case of a DoS attack, the client will most likely be able to
handle the replay cache. A more likely (and serious) DoS attack is a
CPU DoS attack where the attacker sends messages to the peer, which
then needs to expend resources on verifying the MACs/signatures of
the incoming messages.
6. Payload Encoding
This section describes, in detail, all the payloads. For all
encoding, network byte order is always used. While defining
supported types (e.g., which hash functions are supported) the
mandatory-to-implement types are indicated (as Mandatory), as well as
the default types (note, default also implies mandatory
implementation). Support for the other types are implicitly assumed
to be optional.
In the following, note that the support for SRTP [SRTP] as a security
protocol is defined. This will help us better understand the purpose
of the different payloads and fields. Other security protocols MAY
be specified for use within MIKEY, see Section 10.
In the following, the sign ~ indicates variable length field.
6.1. Common Header payload (HDR)
The Common Header payload MUST always be present as the first payload
in each message. The Common Header includes a general description of
the exchange message.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! version ! data type ! next payload !V! PRF func !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! CSB ID !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! #CS ! CS ID map type! CS ID map info ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* version (8 bits): the version number of MIKEY.
version = 0x01 refers to MIKEY as defined in this document.
* data type (8 bits): describes the type of message (e.g., public-
key transport message, verification message, error message).
Data type | Value | Comment
--------------------------------------
Pre-shared | 0 | Initiator’s pre-shared key message
PSK ver msg | 1 | Verification message of a Pre-shared
| | key message
Public key | 2 | Initiator’s public-key transport message
PK ver msg | 3 | Verification message of a public-key
| | message
D-H init | 4 | Initiator’s DH exchange message
D-H resp | 5 | Responder’s DH exchange message
Error | 6 | Error message
Table 6.1.a
* next payload (8 bits): identifies the payload that is added after
this payload.
Next payload | Value | Section
------------------------------
Last payload | 0 | -
KEMAC | 1 | 6.2
PKE | 2 | 6.3
DH | 3 | 6.4
SIGN | 4 | 6.5
T | 5 | 6.6
ID | 6 | 6.7
CERT | 7 | 6.7
CHASH | 8 | 6.8
V | 9 | 6.9
SP | 10 | 6.10
RAND | 11 | 6.11
ERR | 12 | 6.12
Key data | 20 | 6.13
General Ext. | 21 | 6.15
Table 6.1.b
Note that some of the payloads cannot directly follow the header
(such as "Last payload", "Signature"). However, the Next payload
field is generic for all payloads. Therefore, a value is
allocated for each payload. The Next payload field is set to zero
(Last payload) if the current payload is the last payload.
* V (1 bit): flag to indicate whether a verification message is
expected or not (this only has meaning when it is set by the
Initiator). The V flag SHALL be ignored by the receiver in the DH
method (as the response is MANDATORY).
V = 0 ==> no response expected
V = 1 ==> response expected
* PRF func (7 bits): indicates the PRF function that has been/will
be used for key derivation.
PRF func | Value | Comments
--------------------------------------------------------
MIKEY-1 | 0 | Mandatory (see Section 4.1.2)
Table 6.1.c
* CSB ID (32 bits): identifies the CSB. It is RECOMMENDED that the
CSB ID be chosen at random by the Initiator. This ID MUST be
unique between each Initiator-Responder pair, i.e., not globally
unique. An Initiator MUST check for collisions when choosing the
ID (if the Initiator already has one or more established CSBs with
the Responder). The Responder uses the same CSB ID in the
response.
* #CS (8 bits): indicates the number of Crypto Sessions that will be
handled within the CBS. Note that even though it is possible to
use 255 CSs, it is not likely that a CSB will include this many
CSs. The integer 0 is interpreted as no CS included. This may be
the case in an initial setup message.
* CS ID map type (8 bits): specifies the method of uniquely mapping
Crypto Sessions to the security protocol sessions.
CS ID map type | Value
-----------------------
SRTP-ID | 0
Table 6.1.d
* CS ID map info (16 bits): identifies the crypto session(s) for
which the SA should be created. The currently defined map type is
the SRTP-ID (defined in Section 6.1.1).
6.1.1. SRTP ID
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Policy_no_1 ! SSRC_1 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! SSRC_1 (cont) ! ROC_1 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ROC_1 (cont) ! Policy_no_2 ! SSRC_2 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! SSRC_2 (cont) ! ROC_2 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ROC_2 (cont) ! :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
: : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Policy_no_#CS ! SSRC_#CS !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!SSRC_#CS (cont)! ROC_#CS !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ROC_#CS (cont)!
+-+-+-+-+-+-+-+-+
* Policy_no_i (8 bits): The security policy applied for the stream
with SSRC_i. The same security policy may apply for all CSs.
* SSRC_i (32 bits): specifies the SSRC that MUST be used for the
i-th SRTP stream. Note that it is the sender of the streams that
chooses the SSRC. Therefore, it is possible that the Initiator of
MIKEY cannot fill in all fields. In this case, SSRCs that are not
chosen by the Initiator are set to zero and the Responder fills in
these fields in the response message. Note that SRTP specifies
requirements on the uniqueness of the SSRCs (to avoid two-time pad
problems if the same TEK is used for more than one stream) [SRTP].
* ROC_i (32 bits): Current rollover counter used in SRTP. If the
SRTP session has not started, this field is set to 0. This field
is used to enable a member to join and synchronize with an already
started stream.
NOTE: The stream using SSRC_i will also have Crypto Session ID equal
to no i (NOT to the SSRC).
6.2. Key data transport payload (KEMAC)
The Key data transport payload contains encrypted Key data sub-
payloads (see Section 6.13 for the definition of the Key data sub-
payload). It may contain one or more Key data payloads, each
including, for example, a TGK. The last Key data payload has its
Next payload field set to Last payload. For an update message (see
also Section 4.5), it is allowed to skip the Key data sub-payloads
(which will result in the Encr data len being equal to 0).
Note that the MAC coverage depends on the method used, i.e., pre-
shared vs public key, see below.
If the transport method used is the pre-shared key method, this Key
data transport payload is the last payload in the message (note that
the Next payload field is set to Last payload). The MAC is then
calculated over the entire MIKEY message following the directives in
Section 5.2.
If the transport method used is the public-key method, the
Initiator’s identity is added in the encrypted data. This is done by
adding the ID payload as the first payload, which is then followed by
the Key data sub-payloads. Note that for an update message, the ID
is still sent encrypted to the Responder (this is to avoid certain
re-direction attacks) even though no Key data sub-payload is added
after.
In the public-key case, the coverage of the MAC field is over the Key
data transport payload only, instead of the complete MIKEY message,
as in the pre-shared case. The MAC is therefore calculated over the
Key data transport payload, except for the MAC field and where the
Next payload field has been set to zero (see also Section 5.2).
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next payload ! Encr alg ! Encr data len !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Encr data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Mac alg ! MAC ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Next payload (8 bits): identifies the payload that is added after
this payload. See Section 6.1 for defined values.
* Encr alg (8 bits): the encryption algorithm used to encrypt the
Encr data field.
Encr alg | Value | Comment
-------------------------------------------
NULL | 0 | Very restricted usage, see Section 4.2.3!
AES-CM-128 | 1 | Mandatory; AES-CM using a 128-bit key, see
Section 4.2.3)
AES-KW-128 | 2 | AES Key Wrap using a 128-bit key, see
Section 4.2.3
Table 6.2.a
* Encr data len (16 bits): length of Encr data (in bytes).
* Encr data (variable length): the encrypted key sub-payloads (see
Section 6.13).
* MAC alg (8 bits): specifies the authentication algorithm used.
MAC alg | Value | Comments | Length (bits)
----------------------------------------------------------
NULL | 0 | restricted usage | 0
| | Section 4.2.4 |
HMAC-SHA-1-160 | 1 | Mandatory, | 160
| | Section 4.2.4 |
Table 6.2.b
* MAC (variable length): the message authentication code of the
entire message.
6.3. Envelope data payload (PKE)
The Envelope data payload contains the encrypted envelope key that is
used in the public-key transport to protect the data in the Key data
transport payload. The encryption algorithm used is implicit from
the certificate/public key used.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! C ! Data len ! Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Next payload (8 bits): identifies the payload that is added after
this payload. See Section 6.1 for values.
* C (2 bits): envelope key cache indicator (Section 3.2).
Cache type | Value | Comments
--------------------------------------
No cache | 0 | The envelope key MUST NOT be cached
Cache | 1 | The envelope key MUST be cached
Cache for CSB | 2 | The envelope key MUST be cached, but only
| | to be used for the specific CSB.
Table 6.3
* Data len (14 bits): the length of the data field (in bytes).
* Data (variable length): the encrypted envelope key.
6.4. DH data payload (DH)
The DH data payload carries the DH-value and indicates the DH-group
used. Notice that in this sub-section, "MANDATORY" is conditioned
upon DH being supported.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! DH-Group ! DH-value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Reserv! KV ! KV data (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Next payload (8 bits): identifies the payload that is added after
this payload. See Section 6.1 for values.
* DH-Group (8 bits): identifies the DH group used.
DH-Group | Value | Comment | DH Value length (bits)
--------------------------------------|---------------------
OAKLEY 5 | 0 | Mandatory | 1536
OAKLEY 1 | 1 | | 768
OAKLEY 2 | 2 | | 1024
Table 6.4
* DH-value (variable length): the public DH-value (the length is
implicit from the group used).
* KV (4 bits): indicates the type of key validity period specified.
This may be done by using an SPI (alternatively an MKI in SRTP) or
by providing an interval in which the key is valid (e.g., in the
latter case, for SRTP this will be the index range where the key
is valid). See Section 6.13 for pre-defined values.
* KV data (variable length): This includes either the SPI/MKI or an
interval (see Section 6.14). If KV is NULL, this field is not
included.
6.5. Signature payload (SIGN)
The Signature payload carries the signature and its related data.
The signature payload is always the last payload in the PK transport
and DH exchange messages. The signature algorithm used is implicit
from the certificate/public key used.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! S type| Signature len ! Signature ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* S type (4 bits): indicates the signature algorithm applied by the
signer.
S type | Value | Comments
-------------------------------------
RSA/PKCS#1/1.5| 0 | Mandatory, PKCS #1 version 1.5 signature
[PSS]
RSA/PSS | 1 | RSASSA-PSS signature [PSS]
Table 6.5
* Signature len (12 bits): the length of the signature field (in
bytes).
* Signature (variable length): the signature (its formatting and
padding depend on the type of signature).
6.6. Timestamp payload (T)
The timestamp payload carries the timestamp information.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! TS type ! TS value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Next payload (8 bits): identifies the payload that is added after
this payload. See Section 6.1 for values.
* TS type (8 bits): specifies the timestamp type used.
TS type | Value | Comments | length of TS value
-------------------------------------|-------------------
NTP-UTC | 0 | Mandatory | 64-bits
NTP | 1 | Mandatory | 64-bits
COUNTER | 2 | Optional | 32-bits
Table 6.6
Note: COUNTER SHALL be padded (with leading zeros) to a 64-bit
value when used as input for the default PRF.
* TS-value (variable length): The timestamp value of the specified
TS type.
6.7. ID payload (ID) / Certificate Payload (CERT)
Note that the ID payload and the Certificate payload are two
completely different payloads (having different payload identifiers).
However, as they share the same payload structure, they are described
in the same section.
The ID payload carries a uniquely defined identifier.
The certificate payload contains an indicator of the certificate
provided as well as the certificate data. If a certificate chain is
to be provided, each certificate in the chain should be included in a
separate CERT payload.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! ID/Cert Type ! ID/Cert len !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ID/Certificate Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Next payload (8 bits): identifies the payload that is added after
this payload. See Section 6.1 for values.
If the payload is an ID payload, the following values apply for the
ID type field:
* ID Type (8 bits): specifies the identifier type used.
ID Type | Value | Comments
----------------------------------------------