tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 3830

 
 
 

MIKEY: Multimedia Internet KEYing

Part 3 of 4, p. 32 to 50
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 32 
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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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 RFC Part