RFC 3830
MIKEY: Multimedia Internet KEYing
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 ---------------------------------------------- NAI | 0 | Mandatory (see [NAI]) URI | 1 | Mandatory (see [URI]) Table 6.7.a If the payload is a Certificate payload, the following values applies for the Cert type field: * Cert Type (8 bits): specifies the certificate type used. Cert Type | Value | Comments ---------------------------------------------- X.509v3 | 0 | Mandatory X.509v3 URL | 1 | plain ASCII URL to the location of the Cert X.509v3 Sign | 2 | Mandatory (used for signatures only) X.509v3 Encr | 3 | Mandatory (used for encryption only) Table 6.7.b * ID/Cert len (16 bits): the length of the ID or Certificate field (in bytes). * ID/Certificate (variable length): The ID or Certificate data. The X.509 [X.509] certificates are included as a bytes string using DER encoding as specified in X.509.6.8. Cert hash payload (CHASH)
The Cert hash payload contains the hash of the certificate 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 ! Hash func ! Hash ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * Next payload (8 bits): identifies the payload that is added after this payload. See Section 6.1 for values. * Hash func (8 bits): indicates the hash function that is used (see also Section 4.2.1).
Hash func | Value | Comment | hash length (bits) ------------------------------------------------- SHA-1 | 0 | Mandatory | 160 MD5 | 1 | | 128 Table 6.8 * Hash (variable length): the hash data. The hash length is implicit from the hash function used.6.9. Ver msg payload (V)
The Ver msg payload contains the calculated verification message in the pre-shared key and the public-key transport methods. Note that the MAC is calculated over the entire MIKEY message, as well as the IDs and Timestamp (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 ! Auth alg ! Ver data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * Next payload (8 bits): identifies the payload that is added after this payload. See Section 6.1 for values. * Auth alg (8 bits): specifies the MAC algorithm used for the verification message. See Section 6.2 for defined values. * Ver data (variable length): the verification message data. The length is implicit from the authentication algorithm used.6.10. Security Policy payload (SP)
The Security Policy payload defines a set of policies that apply to a specific security protocol. 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 ! Policy no ! Prot type ! Policy param ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ length (cont) ! Policy param ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * Next payload (8 bits): identifies the payload that is added after this payload. See Section 6.1 for values.
* Policy no (8 bits): each security policy payload must be given a
distinct number for the current MIKEY session by the local peer.
This number is used to map a crypto session to a specific policy
(see also Section 6.1.1).
* Prot type (8 bits): defines the security protocol.
Prot type | Value |
---------------------------
SRTP | 0 |
Table 6.10
* Policy param length (16 bits): defines the total length of the
policy parameters for the specific security protocol.
* Policy param (variable length): defines the policy for the
specific security protocol.
The Policy param part is built up by a set of Type/Length/Value
fields. For each security protocol, a set of possible
types/values that can be negotiated is defined.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Type ! Length ! Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Type (8 bits): specifies the type of the parameter.
* Length (8 bits): specifies the length of the Value field (in
bytes).
* Value (variable length): specifies the value of the parameter.
6.10.1. SRTP policy
This policy specifies the parameters for SRTP and SRTCP. The types/values that can be negotiated are defined by the following table: Type | Meaning | Possible values ---------------------------------------------------- 0 | Encryption algorithm | see below 1 | Session Encr. key length | depends on cipher used 2 | Authentication algorithm | see below 3 | Session Auth. key length | depends on MAC used 4 | Session Salt key length | see [SRTP] for recommendations 5 | SRTP Pseudo Random Function | see below 6 | Key derivation rate | see [SRTP] for recommendations 7 | SRTP encryption off/on | 0 if off, 1 if on 8 | SRTCP encryption off/on | 0 if off, 1 if on 9 | sender's FEC order | see below 10 | SRTP authentication off/on | 0 if off, 1 if on 11 | Authentication tag length | in bytes 12 | SRTP prefix length | in bytes Table 6.10.1.a Note that if a Type/Value is not set, the default is used (according to SRTP's own criteria). Note also that, if "Session Encr. key length" is set, this should also be seen as the Master key length (otherwise, the SRTP default Master key length is used). For the Encryption algorithm, a one byte length is enough. The currently defined possible Values are: SRTP encr alg | Value --------------------- NULL | 0 AES-CM | 1 AES-F8 | 2 Table 6.10.1.b where AES-CM is AES in CM, and AES-F8 is AES in f8 mode [SRTP].
For the Authentication algorithm, a one byte length is enough. The currently defined possible Values are: SRTP auth alg | Value --------------------- NULL | 0 HMAC-SHA-1 | 1 Table 6.10.1.c For the SRTP pseudo-random function, a one byte length is also enough. The currently defined possible Values are: SRTP PRF | Value --------------------- AES-CM | 0 Table 6.10.1.d If FEC is used at the same time SRTP is used, MIKEY can negotiate the order in which these should be applied at the sender side. FEC order | Value | Comments -------------------------------- FEC-SRTP | 0 | First FEC, then SRTP Table 6.10.1.e6.11. RAND payload (RAND)
The RAND payload consists of a (pseudo-)random bit-string. The RAND MUST be independently generated per CSB (note that if the CSB has several members, the Initiator MUST use the same RAND for all the members). For randomness recommendations for security, see [RAND]. 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 ! RAND len ! RAND ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * Next payload (8 bits): identifies the payload that is added after this payload. See Section 6.1 for values. * RAND len (8 bits): length of the RAND (in bytes). It SHOULD be at least 16. * RAND (variable length): a (pseudo-)randomly chosen bit-string.
6.12. Error payload (ERR)
The Error payload is used to specify the error(s) that may have occurred. 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 ! Error no ! Reserved ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * Next payload (8 bits): identifies the payload that is added after this payload. See Section 6.1 for values. * Error no (8 bits): indicates the type of error that was encountered. Error no | Value | Comment ------------------------------------------------------- Auth failure | 0 | Authentication failure Invalid TS | 1 | Invalid timestamp Invalid PRF | 2 | PRF function not supported Invalid MAC | 3 | MAC algorithm not supported Invalid EA | 4 | Encryption algorithm not supported Invalid HA | 5 | Hash function not supported Invalid DH | 6 | DH group not supported Invalid ID | 7 | ID not supported Invalid Cert | 8 | Certificate not supported Invalid SP | 9 | SP type not supported Invalid SPpar | 10 | SP parameters not supported Invalid DT | 11 | not supported Data type Unspecified error | 12 | an unspecified error occurred Table 6.126.13. Key data sub-payload
The Key data payload contains key material, e.g., TGKs. The Key data payloads are never included in clear, but as an encrypted part of the Key data transport payload. Note that a Key data transport payload can contain multiple Key data sub-payloads.
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 ! Type ! KV ! Key data len !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Key data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Salt len (optional) ! Salt data (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! KV data (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Next payload (8 bits): identifies the payload that is added after
this payload. See Section 6.1 for values.
* Type (4 bits): indicates the type of key included in the payload.
Type | Value
-----------------
TGK | 0
TGK+SALT | 1
TEK | 2
TEK+SALT | 3
Table 6.13.a
Note that the possibility of including a TEK (instead of using the
TGK) is provided. When sent directly, the TEK can generally not
be shared between more than one Crypto Session (unless the
Security protocol allows for this, e.g., [SRTP]). The recommended
use of sending a TEK, instead of a TGK, is when pre-encrypted
material exists and therefore, the TEK must be known in advance.
* KV (4 bits): indicates the type of key validity period specified.
This may be done by using an SPI (or MKI in the case of [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).
KV | Value | Comments ------------------------------------------- Null | 0 | No specific usage rule (e.g., a TEK | | that has no specific lifetime) SPI | 1 | The key is associated with the SPI/MKI Interval | 2 | The key has a start and expiration time | | (e.g., an SRTP TEK) Table 6.13.b Note that when NULL is specified, any SPI or Interval is valid. For an Interval, this means that the key is valid from the first observed sequence number until the key is replaced (or the security protocol is shutdown). * Key data len (16 bits): the length of the Key data field (in bytes). Note that the sum of the overall length of all the Key data payloads contained in a single Key data transport payload (KEMAC) MUST be such that the KEMAC payload does not exceed a length of 2^16 bytes (total length of KEMAC, see Section 6.2). * Key data (variable length): The TGK or TEK data. * Salt len (16 bits): The salt key length in bytes. Note that this field is only included if the salt is specified in the Type-field. * Salt data (variable length): The salt key data. Note that this field is only included if the salt is specified in the Type-field. (For SRTP, this is the so-called master salt.) * KV data (variable length): This includes either the SPI or an interval (see Section 6.14). If KV is NULL, this field is not included.6.14. Key validity data
The Key validity data is not a standalone payload, but part of either the Key data payload (see Section 6.13) or the DH payload (see Section 6.4). The Key validity data gives a guideline of when the key should be used. There are two KV types defined (see Section 6.13), SPI/MKI (SPI) or a lifetime range (interval).
SPI/MKI
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! SPI Length ! SPI ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* SPI Length (8 bits): the length of the SPI (or MKI) in bytes.
* SPI (variable length): the SPI (or MKI) value.
Interval
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! VF Length ! Valid From ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! VT Length ! Valid To (expires) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* VF Length (8 bits): length of the Valid From field in bytes.
* Valid From (variable length): sequence number, index, timestamp,
or other start value that the security protocol uses to identify
the start position of the key usage.
* VT Length (8 bits): length of the Valid To field in bytes.
* Valid To (variable length): sequence number, index, timestamp, or
other expiration value that the security protocol can use to
identify the expiration of the key usage.
Note that for SRTP usage, the key validity period for a TGK/TEK
should be specified with either an interval, where the VF/VT
Length is equal to 6 bytes (i.e., the size of the index), or with
an MKI. It is RECOMMENDED that if more than one SRTP stream is
sharing the same keys and key update/re-keying is desired, this is
handled using MKI rather than the From-To method.
6.15. General Extension Payload
The General extensions payload is included to allow possible extensions to MIKEY without the need for defining a completely new payload each time. This payload can be used in any MIKEY message and is part of the authenticated/signed data part. 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 ! Type ! Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * Next payload (8 bits): identifies the payload that is added after this payload. * Type (8 bits): identifies the type of general payload. Type | Value | Comments --------------------------------------- Vendor ID | 0 | Vendor specific byte string SDP IDs | 1 | List of SDP key mgmt IDs (allocated for use in [KMASDP]) Table 6.15 * Length (16 bits): the length in bytes of the Data field. * Data (variable length): the general payload data.
(page 50 continued on part 4)
