Tech-invite3GPPspaceIETFspace
96959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 3830

MIKEY: Multimedia Internet KEYing

Pages: 66
Proposed Standard
Errata
Updated by:  47386309
Part 3 of 4 – Pages 32 to 50
First   Prev   Next

Top   ToC   RFC3830 - Page 32   prevText

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).
Top   ToC   RFC3830 - Page 33
      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).
Top   ToC   RFC3830 - Page 34
      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).
Top   ToC   RFC3830 - Page 35

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).
Top   ToC   RFC3830 - Page 36

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.
Top   ToC   RFC3830 - Page 37
      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).
Top   ToC   RFC3830 - Page 38
      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.
Top   ToC   RFC3830 - Page 39
   *  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.
Top   ToC   RFC3830 - Page 40
      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.
Top   ToC   RFC3830 - Page 41
      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).
Top   ToC   RFC3830 - Page 42
      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.
Top   ToC   RFC3830 - Page 43
   *  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.
Top   ToC   RFC3830 - Page 44

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].
Top   ToC   RFC3830 - Page 45
   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.
Top   ToC   RFC3830 - Page 46

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.
Top   ToC   RFC3830 - Page 47
                        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).
Top   ToC   RFC3830 - Page 48
      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).
Top   ToC   RFC3830 - Page 49
   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.
Top   ToC   RFC3830 - Page 50

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)

Next Section