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.e
6.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.12
6.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.
7. Transport protocols
MIKEY MAY be integrated within session establishment protocols.
Currently, integration of MIKEY within SIP/SDP and RTSP is defined in
[KMASDP]. MIKEY MAY use other transports, in which case how MIKEY is
transported over such a transport protocol has to be defined.
8. Groups
What has been discussed up to now is not limited to single peer-to-
peer communication (except for the DH method), but can be used to
distribute group keys for small-size interactive groups and simple
one-to-many scenarios. Section 2.1. describes the scenarios in the
focus of MIKEY. This section describes how MIKEY is used in a group
scenario (though, see also Section 4.3 for issues related to
authorization).
8.1. Simple one-to-many
++++
|S |
| |
++++
|
--------+-------------- - -
| | |
v v v
++++ ++++ ++++
|A | |B | |C |
| | | | | |
++++ ++++ ++++
Figure 8.1. Simple one-to-many scenario.
In the simple one-to-many scenario, a server is streaming to a small
group of clients. RTSP or SIP is used for the registration and the
key management set up. The streaming server acts as the Initiator of
MIKEY. In this scenario, the pre-shared key or public key transport
mechanism will be appropriate in transporting the same TGK to all the
clients (which will result in common TEKs for the group).
Note, if the same TGK/TEK(s) should be used by all the group members,
the streaming server MUST specify the same CSB_ID and CS_ID(s) for
the session to all the group members.
As the communication may be performed using multicast, the members
need a common security policy if they want to be part of the group.
This limits the possibility of negotiation.
Furthermore, the Initiator should carefully consider whether to
request the verification message in reply from each receiver, as this
may result in a certain load for the Initiator itself as the group
size increases.
8.2. Small-size interactive group
As described in the overview section, for small-size interactive