tech-invite   World Map     

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

RFC 6043

 
 
 

MIKEY-TICKET: Ticket-Based Modes of Key Distribution in Multimedia Internet KEYing (MIKEY)

Part 2 of 3, p. 23 to 43
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 23 
5.  Key Management Functions

5.1.  Key Derivation

   For all messages in the Ticket Request and Ticket Resolve exchanges,
   the keys used to protect the MIKEY messages are derived from a pre-
   shared key or an envelope key.  As crypto sessions SHALL NOT be
   handled, further keying material (i.e., TEKs) does not have to be
   derived.

   In the Ticket Transfer exchange, the keys used to protect the MIKEY
   messages are derived from an MPK.  If key forking is used, the KMS
   and the Initiator SHALL fork the MPKr and the TGKs (encoded in the
   ticket) based on a modifier, and different MPKs (MPKi and MPKr')
   SHALL be used to protect the TRANSFER_INIT and TRANSFER_RESP
   messages.  In addition, the Responder MAY generate a RAND used to
   give Responder key freshness guarantee.

   The key hierarchy and its dependencies on TRANSFER_INIT message
   contents for the case without key forking and RANDRr are illustrated
   in Figure 4.  The KEMAC shown is the KEMAC sent from the KMS to the
   Initiator and the Responder.  The illustrated key derivations are
   done by the Initiator and the Responder.

Top      Up      ToC       Page 24 
                                +------+------------------+-----+------+
   KEMAC                        | MPKi |..................| TGK | SALT |
                                +--+---+------------------+--+--+--+---+
                                   | MPKi                    |     |
                                   v                         |     |
                       CSB ID    -----   auth_key    ------  |     |
                    +---------->| PRF |------------>| AUTH | |     |
                    |            -----               ------  |     |
                    |              ^                MAC |    |     |
                    |              | RAND               v    |     |
                 +--+--+------+----+---+--+--------+--+---+  |     |
   TRANSFER_INIT | HDR |......| RANDRi |..| TICKET |..| V |  |     |
                 +--+--+------+----+---+--+--------+--+---+  |     |
                    |              | RAND                    |     |
                    |              v                         |     |
                    |   CS ID    -----           TGK         |     |
                    +---------->| PRF |<---------------------+     |
                                 -----                             |
                                   | TEK                      SALT |
                                   v                               v
                                ---------------------------------------
                               |      Security Protocol, e.g., SRTP    |
                                ---------------------------------------

          Figure 4: Key hierarchy without key forking and RANDRr

   The key hierarchy and its dependencies on TRANSFER_RESP message
   contents for the case with key forking and RANDRr are illustrated in
   Figure 5.  The KEMAC shown is the KEMAC sent from the KMS to the
   Initiator.  MOD is the modifier (IDRr, RANDRkms).  The two key
   derivations that produce forked keys are done by the Initiator and
   the KMS, and the remaining two key derivations are done by the
   Initiator and the Responder.  The random value RANDRi from the
   TRANSFER_INIT message is used as input to the derivation of the
   auth_key and may be used as input to the derivation of the TEK, but
   this is omitted from the figure.  The protection of the TRANSFER_INIT
   message is done as in Figure 4.

Top      Up      ToC       Page 25 
                        +------+--------------------------+-----+------+
KEMAC                   | MPKr |..........................| TGK | SALT |
                        +--+---+--------------------------+--+--+--+---+
                           | MPKr                            |     |
                           v                                 |     |
                         -----   MPKr'                       |     |
                        | PRF |-------+                  TGK |     |
                         -----        |                      |     |
                           ^          v                      |     |
                   CSB ID  |        -----  auth_key  ------  |     |
                 +---------)------>| PRF |--------->| AUTH | |     |
                 |         |        -----            ------  |     |
                 |         | ID Data  ^             MAC |    |     |
                 |         | RAND     | RAND            v    |     |
              +--+--+---+--+--+---+---+----+----------+---+  |     |
TRANSFER_RESP | HDR |...| MOD |...| RANDRr |..........| V |  |     |
              +--+--+---+--+--+---+---+----+----------+---+  |     |
                 |         |          | RAND                 v     |
                 |         |          |          ID Data   -----   |
                 |         +----------)------------------>| PRF |  |
                 |                    |            RAND    -----   |
                 |                    v                      |     |
                 |       CS ID      -----         TGK'       |     |
                 +---------------->| PRF |<------------------+     |
                                    -----                          |
                                      | TEK                   SALT |
                                      v                            v
                                ---------------------------------------
                               |      Security Protocol, e.g., SRTP    |
                                ---------------------------------------

            Figure 5: Key hierarchy with key forking and RANDRr

   The labels in the key derivations SHALL NOT include entire RANDR
   payloads, only the fields RAND length and RAND from the corresponding
   payload.

5.1.1.  Deriving Forked Keys

   When key forking is used (determined by the I flag in the Ticket
   Policy), the MPKr and TGKs (encoded in the ticket) SHALL be forked.
   The TEKs and GTGKs (Group TGKs), however, SHALL NOT be forked.  This
   key forking is done by the KMS and the Initiator using the PRF
   (Pseudorandom Function) indicated in the Ticket Policy.  The
   parameters for the PRF are:

Top      Up      ToC       Page 26 
   inkey:     : MPKr or TGK
   inkey_len  : bit length of the inkey
   label      : constant || 0xFF || 0xFFFFFFFF || 0x00 ||
                length ID Data || ID Data || length RANDRkms || RANDRkms
   outkey_len : desired bit length of the outkey (MPKr', TGK')
                SHALL be equal to inkey_len

   where the ID Data field is taken from the IDRr payload sent in the
   RESOLVE_RESP and TRANSFER_RESP messages.  Length ID Data is the
   length of the ID Data field in bytes as a 16-bit unsigned integer.
   Length RANDRkms is the length of RANDRkms in bytes as an 8-bit
   unsigned integer.  The constant depends on the derived key type as
   summarized below.

                          Derived key | Constant
                          ------------+-----------
                          MPKr'       | 0x2B288856
                          TGK'        | 0x1512B54A

              Table 5.1: Constants for forking key derivation

   The constants are taken from the decimal digits of e as described in
   [RFC3830].

5.1.2.  Deriving Keys from an Envelope Key/PSK/MPK

   This derivation is used to form the keys used to protect the MIKEY
   messages.  For the Ticket Request and Ticket Resolve exchanges, the
   keys used to protect the MIKEY messages are derived from a pre-shared
   key or an envelope key.  For the Ticket Transfer exchange, the keys
   are derived from an MPK.  If key forking is used, different MPKs
   (MPKi and MPKr') SHALL be used to protect the TRANSFER_INIT and
   TRANSFER_RESP messages.  The initial messages SHALL be protected with
   keys derived using the following parameters:

   inkey:     : pre-shared key, envelope key, or MPKi
   inkey_len  : bit length of the inkey
   label      : constant || 0xFF || CSB ID || 0x01 ||
                length RANDRi || [RANDRi] || length RANDRr || [RANDRr]
   outkey_len : desired bit length of the outkey (encr_key,
                auth_key, salt_key)

   The response messages SHALL be protected with keys derived using the
   following parameters:

Top      Up      ToC       Page 27 
   inkey:     : pre-shared key, envelope key, MPKi, or MPKr'
   inkey_len  : bit length of the inkey
   label      : constant || 0xFF || CSB ID || 0x02 ||
                length RANDRi || [RANDRi] || length RANDRr || [RANDRr]
   outkey_len : desired bit length of the outkey (encr_key,
                auth_key, salt_key)

   The constant depends on the derived key type as defined in Section
   4.1.4 of [RFC3830].  The 32-bit CSB ID field is taken from the HDR
   payload.  RANDRi SHALL be included in the derivation of keys used to
   protect the Ticket Request and Ticket Transfer exchanges.  RANDRr
   SHALL be included in the derivation of keys used to protect the
   Ticket Resolve exchange and in the derivation of keys used to protect
   TRANSFER_RESP if the Ticket Policy determines that it shall be
   present in the TRANSFER_RESP message (G flag).  Length RANDRi is the
   length of RANDRi in bytes as an 8-bit unsigned integer, and Length
   RANDRr is the length of RANDRr in bytes as an 8-bit unsigned integer.
   If RANDRi is omitted, length RANDRi SHALL be 0 and if RANDRr is
   omitted, length RANDRr SHALL be 0.  Note that at least one of RANDRi
   and RANDRr is always used.

5.1.3.  Deriving Keys from a TGK/GTGK

   This only affects the Ticket Transfer exchange.  In the following, we
   describe how keying material is derived from a TGK/GTGK.  If key
   forking is used, any TGK encoded in the ticket SHALL be forked, and
   the forked key TGK' SHALL be used.  The key derivation method SHALL
   be executed using the PRF indicated in the HDR payload.  The
   parameters for the PRF are:

   inkey:     : TGK, TGK', or GTGK
   inkey_len  : bit length of the inkey
   label      : constant || CS ID || 0xFFFFFFFF || 0x03 ||
                length RANDRi || [RANDRi] || length RANDRr || [RANDRr]
   outkey_len : desired bit length of the outkey (TEK, encr_key,
                auth_key, salt_key)

   The constant depends on the derived key type as defined in Section
   4.1.3 of [RFC3830].  If a salting key is present in the key data sub-
   payload, a security protocol in need of a salting key SHALL use this
   salting key and a new salting key SHALL NOT be derived.  The 8-bit CS
   ID field is given by the CS ID map info field in the HDR payload.
   RANDRi SHALL be included if the Ticket Policy determines that it
   shall be used (H flag).  RANDRr SHALL be included if the Ticket
   Policy determines that it shall be present in the TRANSFER_RESP
   message (G flag).  Length RANDRi is the length of RANDRi in bytes as
   an 8-bit unsigned integer, and Length RANDRr is the length of RANDRr

Top      Up      ToC       Page 28 
   in bytes as an 8-bit unsigned integer.  If RANDRi or RANDRr is
   omitted the corresponding length SHALL be 0.  Note that at least one
   of RANDRi and RANDRr MUST be used.

5.2.  CSB Updating

   Similar to [RFC3830], MIKEY-TICKET provides a means of updating the
   CSB (Crypto Session Bundle), e.g., transporting a new TEK/TGK/GTGK or
   adding new crypto sessions.  The CSB updating is done by executing
   the Ticket Transfer exchange again, e.g., before a TEK expires or
   when a new crypto session is needed.  The CSB updating can be started
   by the Initiator:

   Initiator                               Responder

   TRANSFER_INIT =                 ---->
   HDR, T, [IDRi], [IDRr],
      {SP}, [KEMAC], V              < - -  TRANSFER_RESP =
                                           HDR, T, [IDRr],
                                           {SP}, [KEMAC], V

   The CSB updating can also be started by the Responder:

   Responder                               Initiator

   TRANSFER_INIT =                 ---->
   HDR, T, [IDRr], [IDRi],
      {SP}, [KEMAC], V              < - -  TRANSFER_RESP =
                                           HDR, T, [IDRi],
                                           {SP}, [KEMAC], V

   The new message exchange MUST use the same CSB ID as the initial
   exchange but MUST use new timestamps.  The crypto sessions
   negotiation (#CS field, CS ID map info field, and SP payloads) are
   handled as in the initial exchange.  In the TRANSFER_INIT message the
   V flag SHALL be used to indicate whether or not a response message is
   expected.  Static payloads such as RANDRi, RANDRr, RANDRkms, and
   TICKET that were provided in the initial exchange SHOULD NOT be
   included unless they are needed by a specific use case.  New RANDs or
   TICKETs MUST NOT be included.  The reason that new RANDs SHALL NOT be
   used is that if several TGKs are used, the peers would need to keep
   track of which RANDs to use for each TGK.  This adds unnecessary
   complexity.  Both messages SHALL be protected with the same keys
   (derived from MPKi or MPKr') that protected the last message
   (TRANSFER_INIT or TRANSFER_RESP) in the initial exchange.

Top      Up      ToC       Page 29 
   New keying material MAY be sent in a KEMAC payload.  If indicated by
   the Ticket Policy (L and M flags), KEMAC payloads SHALL NOT be
   included.  In the TRANSFER_RESP message, a session key MUST be
   provided for each crypto session.  The KEMAC SHALL use the NULL
   authentication algorithm, as a MAC is included in the V payload.  The
   encr_key (and salt_key) SHALL be derived from the MPK (MPKi or
   MPKr').  Depending on the encryption algorithm, the salting key may
   go into the IV (see [RFC3830]).  If a new TGK is exchanged, it SHALL
   NOT be forked.  The KEMAC is hence constructed as follows:

                    KEMAC = E(encr_key, (TEK|TGK|GTGK))

5.3.  Ticket Reuse

   MIKEY-TICKET includes features aiming to offload the KMS from
   receiving ticket requests.  One such feature is that tickets may be
   reused.  This means that a user may request a ticket for media
   sessions with another user and then under the ticket's validity
   period use this ticket to protect several media sessions with that
   user.

   When reusing a ticket that has been used in a previous Ticket
   Transfer exchange, a new Ticket Transfer exchange is executed.  The
   new exchange MUST use a new CSB ID, a new timestamp, and new RANDs
   (RANDRi, RANDRr).  If the Responder has resolved the ticket before,
   the Responder does not need to resolve the ticket again.  In that
   case, the same modifier (IDRr, RANDRkms) SHALL be used.  If the
   Ticket Policy forbids reuse (J flag), the ticket MUST NOT be reused.
   Note that such reuse cannot be detected by a stateless KMS.  When
   group keys are used, ticket reuse leaves the Initiator responsible to
   ensure that group membership has not changed since the ticket was
   last used.  (Otherwise, unauthorized responders may gain access to
   the group communication.)  Thus, if group dynamics are difficult to
   verify, the Initiator SHOULD NOT initiate ticket reuse.

   When key forking is used, only the user that requested the ticket has
   access to the encoded master keys (MPKr, TGKs).  Because of this, no
   one else can initiate a Ticket Transfer exchange using the ticket.

5.4.  Error Handling

   If a fatal error occurs during the parsing of a message, the message
   SHOULD be discarded, and an Error message SHOULD be sent to the other
   party (Initiator, Responder, KMS).  If a failure is due to the
   inability to authenticate the peer, the message SHALL be discarded,
   the Error message is OPTIONAL, and the caveats in Section 5.1.2 of
   [RFC3830] apply.  Error messages may be used to report errors in both
   initial and response messages, but not in Error messages.

Top      Up      ToC       Page 30 
   In the Ticket Request and Ticket Resolve exchanges, the Error message
   MAY be authenticated with a MAC or a signature.  The Error message is
   hence constructed as follows:

                  Error message = HDR, T, (ERR), [V|SIGNx]

   where x is in the set {i, r, kms} (Initiator, Responder, KMS).
   Unexpected payloads in the Error message SHOULD be ignored.

   In the Ticket Transfer exchange, the Error message MAY be
   authenticated with a MAC.  If the suggested security policies are not
   supported, the Error message SHOULD include the supported parameters.
   The Error message is hence constructed as follows:

                  Error message = HDR, T, (ERR), {SP}, [V]

   In Error messages, the version, PRF func, and CSB ID fields in the
   HDR payload SHALL be identical to the corresponding fields in the
   message where the error occurred.  The V field SHALL be set to '0'
   and be ignored.

   If one of the NTP timestamp types is used, a fresh timestamp value
   SHALL be used.  If the COUNTER timestamp type (see Section 6.6 of
   [RFC3830]) is used, the timestamp value MAY be equal to the one in
   the message where the error occurred.

   The MAC/Signature in the V/SIGN payloads covers the entire Error
   message, except the MAC/Signature field itself.  The auth_key SHALL
   be the same as in the message where the error occurred.

5.5.  MAC/Signature Coverage

   The MAC/Signature in the V/SIGN payloads covers the entire MIKEY
   message, except the MAC/Signature field itself.  For initial
   messages, the identities (not whole payloads) of the parties involved
   MUST directly follow the MIKEY message in the Verification MAC/
   Signature calculation.  In the TRANSFER_INIT message, the MAC SHALL
   NOT cover the Initiator Data length and Initiator Data fields in the
   TICKET payload.  Note that in the Transfer Exchange, Identity_r in
   TRANSFER_RESP (e.g., user1@example.com) MAY differ from that
   appearing in TRANSFER_INIT (e.g., IT-support@example.com).  For
   response messages, the entire initial message (including the MAC/
   Signature field) MUST directly follow the MIKEY message in the
   Verification MAC/Signature calculation (the identities are implicitly
   covered as they are covered by the initial message's MAC/Signature).

Top      Up      ToC       Page 31 
        Message type  | MAC/Signature coverage
        --------------+--------------------------------------------
        REQUEST_INIT  | REQUEST_INIT  || Identity_i || Identity_kms
        REQUEST_RESP  | REQUEST_RESP  || REQUEST_INIT
        TRANSFER_INIT | TRANSFER_INIT || Identity_i || Identity_r
        TRANSFER_RESP | TRANSFER_RESP || TRANSFER_INIT
        RESOLVE_INIT  | RESOLVE_INIT  || Identity_r || Identity_kms
        RESOLVE_RESP  | RESOLVE_RESP  || RESOLVE_INIT
        Error message | Error message

                     Table 5.2: MAC/Signature coverage

6.  Payload Encoding

   This section does not describe all the payloads that are used in the
   new message types.  It describes in detail the new TR, IDR, RANDR,
   TP, and TICKET payloads.  For the other payloads, only the additions
   and changes compared to [RFC3830] are described.  For a detailed
   description of the other MIKEY payloads, see [RFC3830].  Note that
   the fields with variable length are byte aligned and not 32-bit
   aligned.

6.1.  Common Header Payload (HDR)

   For the Common Header Payload, new values are added to the Data Type,
   Next Payload, PRF func, and CS ID map type name spaces.

   *  Data Type (8 bits): describes the type of message.

      Data Type        | Value | Comment
      -----------------+-------+-------------------------------------
      REQUEST_INIT_PSK |    11 | Ticket request initial message (PSK)
      REQUEST_INIT_PK  |    12 | Ticket request initial message (PK)
      REQUEST_RESP     |    13 | Ticket request response message
                       |       |
      TRANSFER_INIT    |    14 | Ticket transfer initial message
      TRANSFER_RESP    |    15 | Ticket transfer response message
                       |       |
      RESOLVE_INIT_PSK |    16 | Ticket resolve initial message (PSK)
      RESOLVE_INIT_PK  |    17 | Ticket resolve initial message (PK)
      RESOLVE_RESP     |    18 | Ticket resolve response message

                     Table 6.1: Data Type (Additions)

Top      Up      ToC       Page 32 
   *  Next Payload (8 bits): identifies the payload that is added after
      this payload.

                       Next Payload | Value | Section
                       -------------+-------+--------
                       TR           |    13 | 6.4
                       IDR          |    14 | 6.6
                       RANDR        |    15 | 6.8
                       TP           |    16 | 6.10
                       TICKET       |    17 | 6.10

                    Table 6.2: Next Payload (Additions)

   *  V (1 bit): flag to indicate whether a response message is expected
      ('1') or not ('0').  It MUST be set to '0' and ignored in all
      messages except TRANSFER_INIT messages used for CSB updating (see
      Section 5.2).

   *  PRF func (7 bits): indicates the PRF function that has been/will
      be used for key derivation.  Besides the PRFs already defined in
      [RFC3830] the following additional PRF may be used.

                         PRF func         | Value
                         -----------------+------
                         PRF-HMAC-SHA-256 |     1

                      Table 6.3: PRF func (Additions)

   The new PRF SHALL be constructed as described in Section 4.1.2 of
   [RFC3830] with the differences that HMAC-SHA-256 (see Section 6.2)
   SHALL be used instead of HMAC-SHA-1 and the value 256 SHALL be used
   instead of 160.  This corresponds to the full output length of
   SHA-256.

   *  #CS (8 bits): indicates the number of crypto sessions in the CS ID
      map info.

   *  CS ID map type (8 bits): specifies the method of uniquely mapping
      crypto sessions to the security protocol sessions.  In the Ticket
      Transfer exchange the new GENERIC-ID map type, which is intended
      to eliminate the limitations with the existing SRTP-ID map type,
      SHOULD be used.  The map type SRTP-ID SHALL NOT be used.

                          CS ID map type | Value
                          ----------------------
                          GENERIC-ID     |     2

                   Table 6.4: CS ID map type (Additions)

Top      Up      ToC       Page 33 
   *  CS ID map info (variable length): identifies and maps the crypto
      sessions to the security protocol sessions for which security
      associations should be created.

6.1.1.  The GENERIC-ID Map Type

   For the GENERIC-ID map type, the CS ID map info consists of #CS
   number of blocks, each mapping policies, session data (e.g., SSRC),
   and key to a specific crypto session.

    0                   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !     CS ID     !   Prot type   !S!     #P      ! Ps (OPTIONAL) ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !      Session Data Length      !    Session Data (OPTIONAL)    ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !  SPI Length   !                SPI (OPTIONAL)                 ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   *  CS ID (8 bits): defines the CS ID to be used for the crypto
      session.

   *  Prot type (8 bits): defines the security protocol to be used for
      the crypto session.  Allowed values are the ones defined for the
      Prot type field in the SP payload (see Section 6.10 of [RFC3830]).

   *  S (1 bit): flag that MAY be used by the Session Data.

   *  #P (7 bits): indicates the number of security policies provided
      for the crypto session.  In response messages, #P SHALL always be
      exactly 1.  So if #P = 0 in an initial message, a security profile
      MUST be provided in the response message.  If #P > 0, one of the
      suggested policies SHOULD be chosen in the response message.  If
      needed (e.g., in group communication, see Section 9), the
      suggested policies MAY be changed.

   *  Ps (variable length): lists the policies for the crypto session.
      It SHALL contain exactly #P policies, each having the specified
      Prot type.

       0                   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  !  Policy_no_2  !      ...      ! Policy_no_#P  !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Top      Up      ToC       Page 34 
      *  Policy_no_i (8 bits): a policy_no that corresponds to the
         policy_no of a SP payload.  In response messages, the policy_no
         may refer to a SP payload in the initial message.

   *  Session Data Length (16 bits): the length of Session Data (in
      bytes).  For the Prot type SRTP, Session Data MAY be omitted in
      the initial message (length = 0), but it MUST be provided in the
      response message.

   *  Session Data (variable length): contains session data for the
      crypto session.  The type of Session Data depends on the specified
      Prot type.  The Session Data for the Prot type SRTP is defined
      below.  The S flag is used to indicate whether the ROC and SEQ
      fields are provided ('1') or if they are omitted ('0').

       0                   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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      !                              SSRC                             !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      !                        ROC (OPTIONAL)                         !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      !         SEQ (OPTIONAL)          !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      *  SSRC (32 bits): specifies the SSRC that MUST be used for the
         crypto session.  Note that unlike [RFC3830], an SSRC field set
         to '0' has no special meaning.

      *  ROC (32 bits): current/initial rollover counter.  If the
         session has not started, this field is set to '0'.

      *  SEQ (16 bits): current/initial sequence number.

   *  SPI Length (8 bits): the length of SPI (in bytes).  SPI MAY be
      omitted in the initial message (length = 0), but it MUST be
      provided in the response message.

   *  SPI (variable length): the SPI (or MKI) corresponding to the
      session key to (initially) be used for the crypto session.  This
      does not exclude other keys to be used.  All keys MUST belong to
      the crypto session bundle.

6.2.  Key Data Transport Payload (KEMAC)

   For the KEMAC payload, new encryption and authentication algorithms
   are defined.

Top      Up      ToC       Page 35 
   *  Encr alg (8 bits): the encryption algorithm used to encrypt the
      Encr data field.  Besides the algorithms already defined in
      [RFC3830], the following additional encryption algorithm may be
      used.

              Encr alg   | Value | Comment
              -----------+-------+---------------------------
              AES-CM-256 |     3 | AES-CM using a 256-bit key

                      Table 6.5: Encr alg (Additions)

   The new encryption algorithm is defined as described in Section 4.2.3
   of [RFC3830] with the only difference being that a 256-bit key SHALL
   be used.

   *  MAC alg (8 bits): specifies the authentication algorithm used.
      Besides the algorithms already defined in [RFC3830], the following
      additional authentication algorithm may be used.

                    MAC alg          | Value | Length
                    -----------------+-------+---------
                    HMAC-SHA-256-256 |     2 | 256 bits

                       Table 6.6: MAC alg (Additions)

   The new authentication algorithm is Hash-based Message Authentication
   Code (HMAC) [RFC2104] in conjunction with SHA-256 [FIPS.180-3].  It
   SHALL be used with a 256-bit authentication key.

6.2.1.  Key Data Sub-Payload

   For the key data sub-payload, new types of keys are defined.  The
   Group TGK (GTGK) is used as a regular TGK, with the difference that
   it SHALL NOT be forked.  It is intended to enable the establishment
   of a group TGK when key forking is used.  The MIKEY Protection Key
   (MPK) is used to protect the MIKEY messages in the Ticket Transfer
   exchange.  The MPK is used as the pre-shared key in the pre-shared
   key method of [RFC3830]; however, it is not known by the Responder
   before the ticket has been resolved.

   An SPI (or MKI) MUST be specified for each key (see Section 6.13 of
   [RFC3830]).

   *  Type (4 bits): indicates the type of key included in the payload.

Top      Up      ToC       Page 36 
                  Type      | Value | Comments
                  ----------+-------+---------------------
                  GTGK      |     4 | Group TGK
                  GTGK+SALT |     5 | Group TGK + SALT
                  MPK       |     6 | MIKEY Protection Key

                    Table 6.7: Key Data Type (Additions)

6.3.  Timestamp Payload (T)

   For the timestamp payload, a new type of timestamp is defined.  The
   new type is intended to be used when defining validity periods, where
   fractions of seconds seldom matter.  The NTP-UTC-32 string contains
   four bytes, in the same format as the first four bytes in the NTP
   timestamp format, defined in [RFC4330].  This represents the number
   of seconds since 0h on 1 January 1900 with respect to the Coordinated
   Universal Time (UTC).  On 7 February 2036, the time value will
   overflow.  [RFC4330] describes a procedure to extend the time to 2104
   and this procedure is MANDATORY to support.

   *  TS Type (8 bits): specifies the timestamp type used.

                        TS Type    | Value | Length
                        -----------+-------+--------
                        NTP-UTC-32 |     3 | 32 bits

                       Table 6.8: TS Type (Additions)

   NTP-UTC-32 SHALL be padded to a 64-bit NTP-UTC timestamp (with zeroes
   in the fractional second part) when a 64-bit timestamp is required
   (e.g.  IV creation in AES-CM-128 and AES-CM-256).

6.4.  Timestamp Payload with Role Indicator (TR)

   The TR payload uses all the fields from the standard timestamp
   payload (T) but expands it with a new field describing the role of
   the timestamp.  Whereas the TS Type describes the type of the TS
   Value, the TS Role describes the meaning of the timestamp itself.
   The TR payload is intended to eliminate ambiguity when a MIKEY
   message contains several timestamp payloads (e.g., in the Ticket
   Policy).

    0                   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 Role    !    TS Type    !    TS Value   ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Top      Up      ToC       Page 37 
   *  TS Role (8 bits): specifies the sort of timestamp.

                   TS Role                        | Value
                   -------------------------------+------
                   Time of issue (TRi)            |     1
                   Start of validity period (TRs) |     2
                   End of validity period (TRe)   |     3
                   Rekeying interval (TRr)        |     4

                             Table 6.9: TS Role

6.5.  ID Payload (ID)

   For the ID payload, a new ID Type byte string is defined.  The byte
   string type is intended to be used when the ID payload is used to
   identify a pre-shared key.  Contrary to the previously defined ID
   Types (URI, Network Access Identifier), the byte string does not have
   any encoding rules.

   *  ID Type (8 bits): specifies the identifier type used.

                            ID Type     | Value
                            ------------+------
                            Byte string |     2

                      Table 6.10: ID Type (Additions)

6.6.  ID Payload with Role Indicator (IDR)

   The IDR payload uses all the fields from the standard identity
   payload (ID) but expands it with a new field describing the role of
   the ID payload.  Whereas the ID Type describes the type of the ID
   Data, the ID Role describes the meaning of the identity itself.  The
   IDR payload is intended to eliminate ambiguity when a MIKEY message
   contains several identity payloads.  The IDR payload MUST be used
   instead of the ID payload in all MIKEY-TICKET messages.

    0                   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 Role    !    ID Type    !     ID len
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ID len (cont) !                    ID Data                    ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Top      Up      ToC       Page 38 
   *  ID Role (8 bits): specifies the sort of identity.

                      ID Role                 | Value
                      ------------------------+------
                      Initiator (IDRi)        |     1
                      Responder (IDRr)        |     2
                      KMS (IDRkms)            |     3
                      Pre-Shared Key (IDRpsk) |     4
                      Application (IDRapp)    |     5

                            Table 6.11: ID Role

   IDRapp is intended to specify the authorized Application IDs (see
   Sections 5.1.3 and 6.10)

6.7.  Cert Hash Payload (CHASH)

   *  Hash func (8 bits): indicates the hash function that is used.
      Besides the hash functions already defined in [RFC3830], the
      following hash function may be used.

                      Hash func | Value | Hash Length
                      ----------+-------+------------
                      SHA-256   |     2 |    256 bits

                     Table 6.12: Hash func (Additions)

   The SHA-256 hash function is defined in [FIPS.180-3].

6.8.  RAND Payload with Role Indicator (RANDR)

   The RANDR payload uses all the fields from the standard RAND payload
   (RAND) but expands it with a new field describing the role (the
   generating entity) of the RAND.  The RANDR payload is intended to
   eliminate ambiguity when a MIKEY message contains several RAND
   payloads.

    0                   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 Role  !  RAND length  !     RAND      ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   *  RAND Role (8 bits): specifies the entity that generated the RAND.

Top      Up      ToC       Page 39 
                         RAND Role          | Value
                         -------------------+------
                         Initiator (RANDRi) |     1
                         Responder (RANDRr) |     2
                         KMS (RANDRkms)     |     3

                           Table 6.13: RAND Role

6.9.  Error Payload (ERR)

   For the key data sub-payload, new types of errors are defined.

   *  Error no (8 bits): indicates the type of error that was
      encountered.

            Error no       | Value | Comments
            ---------------+-------+----------------------------
            Invalid TICKET |    14 | Ticket Type not supported
            Invalid TPpar  |    15 | TP parameters not supported

                      Table 6.14: Error no (Additions)

6.10.  Ticket Policy Payload (TP) / Ticket Payload (TICKET)

   Note that the Ticket Policy payload (TP) and the Ticket Payload
   (TICKET) are two different payloads (having different payload
   identifiers).  However, as they share much of the payload structure,
   they are described in the same section.

   The Ticket Policy payload contains a desired Ticket Policy and does
   not include the Ticket Data length, Ticket Data, Initiator Data
   length, or Initiator Data fields.  The ticket payload contains the
   granted Ticket Policy as well as Ticket Data (the default ticket type
   is defined in Appendix A).  The Ticket Policy contains information
   intended for all parties involved whereas the Ticket Data is only
   intended for the party that resolves the ticket.  The Ticket Type
   provided in the Ticket Data is indicated in the Ticket Policy.  When
   key forking is used (I flag), the Initiator Data authenticates the
   Initiator.

   Note that the flags are not independent: NOT D implies L, G implies
   F, NOT G implies H, NOT H implies G, I implies E, K implies D, and M
   implies F.  The F flag SHALL be set to '1' when the I flag (key
   forking) is set to '1' and a TGK is encoded in the ticket.

Top      Up      ToC       Page 40 
    0                   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  !          Ticket Type          !    Subtype    !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !    Version    !   PRF Func  !D!E!F!G!H!I!J!K!L!M!N!O!   Res   !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !        TP Data length         !            TP Data            ~
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   !      Ticket Data length       !          Ticket Data          ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !     Initiator Data length     !   Initiator Data (OPTIONAL)   ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   *  Next Payload (8 bits): identifies the payload that is added after
      this payload.

   *  Ticket Type (16 bits): specifies the Ticket Type used.

           Ticket Type       | Value | Comments
           ------------------+-------+---------------------------
           MIKEY Base Ticket |     1 | Defined in Appendix A
           3GPP Base Ticket  |     2 | Used and specified by 3GPP

                          Table 6.15: Ticket Type

   Subtype = 0x01 and Version = 0x01 refers to MIKEY Base Ticket as
   defined in this document.

   *  Subtype (8 bits): specifies the ticket subtype used.

   *  Version (8 bits): specifies the ticket subtype version used.

   *  PRF Func (7 bits): specifies the PRF that SHALL be used for key
      forking.

   *  D (1 bit): flag to indicate whether the ticket was generated by
      the KMS ('1') or by the Initiator ('0').

   *  E (1 bit): flag to indicate whether the Ticket Resolve exchange is
      MANDATORY ('1') or if the Responder MAY resolve the ticket ('0').

   *  F (1 bit): flag to indicate whether the TRANSFER_RESP message
      SHALL be sent ('1') or if it SHALL NOT be sent ('0').

Top      Up      ToC       Page 41 
   *  G (1 bit): flag to indicate whether the Responder SHALL generate
      RANDRr ('1') or if the Responder SHALL NOT generate RANDRr ('0').

   *  H (1 bit): flag to indicate whether RANDRi SHALL be used when
      deriving keys from a TGK/GTGK ('1') or if RANDRi SHALL NOT be used
      ('0').

   *  I (1 bit): flag to indicate whether key forking SHALL be used
      ('1') or if key forking SHALL NOT be used ('0').

   *  J (1 bit): flag to indicate whether the ticket MAY be reused ('1')
      and therefore MAY be cached or if it SHALL NOT be reused ('0').

   *  K (1 bit): flag to indicate whether the KMS changed the desired
      Ticket Policy or the desired KEMAC ('1') or if it did not ('0').
      In the TP payload, it SHALL be set to '0' by the Initiator and
      ignored by the KMS.

   *  L (1 bit): flag to indicate whether the Initiator MAY supply
      session keys ('1') or if the Initiator SHALL NOT supply session
      keys ('0').

   *  M (1 bit): flag to indicate whether the Responder MAY supply
      session keys ('1') or if the Responder SHALL NOT supply session
      keys ('0').

   *  N (1 bit): flag to indicate whether an Initiator following this
      specification can initiate a TRANSFER_INIT message using the
      ticket ('1') or if additional processing is required ('0').  If
      the flag is set to '0', the Initiator SHOULD follow the processing
      in the specification of the received Ticket Type.

   *  O (1 bit): flag to indicate whether a Responder following this
      specification can process a TRANSFER_INIT message containing the
      ticket ('1') or if additional processing is required ('0').  If
      the flag is set to '0', the Responder SHOULD follow the processing
      in the specification of the received Ticket Type.

   *  Res (5 bits): reserved for future use.

   *  TP Data length (16 bits): length of TP Data (in bytes).

   *  TP Data (variable length): The first 8 bits identify the first
      payload.  The rest of TP Data SHALL be constructed of MIKEY
      payloads.  Unexpected payloads in the TP Data SHOULD be ignored.

             TP Data = First Payload, [IDRkms], [IDRi], [TRs],
                       [TRe], [TRr], [KEMAC], {IDRapp}, (IDRr)

Top      Up      ToC       Page 42 
      IDRkms contains the identity of a KMS that can resolve the ticket.

      IDRi contains the identity of the peer that requested or created
      the ticket.

      TRs is the start of the validity period.  TRs SHALL be interpreted
      as being in the range 1968-2104 as described in [RFC4330].  An
      omitted TRs means that the validity period has no defined
      beginning.

      TRe is the end of the validity period.  TRe SHALL be interpreted
      as being in the range 1968-2104 as described in [RFC4330].  An
      omitted TRe means that the validity period has no defined end.

      TRr indicates how often rekeying MUST be done.  TS Type SHALL be
      NTP-UTC-32 and the time between two rekeyings SHALL NOT be longer
      than the number of seconds in the integer part of the timestamp.
      How the rekeying is done is implementation specific.

      The KEMAC payload may be used to indicate the number of requested
      keys and specify other key information (key type, key length, and
      KV (key validity) data).  The KEMAC payload SHALL use the NULL
      encryption algorithm and the NULL authentication algorithm, as a
      MAC is included in the V payload.  The KEMAC is hence constructed
      as follows:

                           KEMAC = {TEK|TGK|GTGK}

   The Key Data fields SHALL be set to '0' by the Initiator and ignored
   by the KMS.  The KEMAC SHALL NOT be present in the granted Ticket
   Policy.

      IDRapp is an identifier for an authorized application ID.  The
      application IDs are implementation specific.  If no IDRapp
      payloads are supplied, all application IDs are authorized.

      IDRr is the identity of a responder or a group of responders that
      are authorized to resolve the ticket.  If there is more than one
      responder identity, each responder identity SHALL be included in a
      separate IDR payload.

   *  Ticket Data length (16 bits): the length of the Ticket Data field
      (in bytes).  Not present in the TP payload.

   *  Ticket Data (variable length): contains the Ticket Data.  Not
      present in the TP payload.

Top      Up      ToC       Page 43 
   *  Initiator Data length (16 bits): the length of the Initiator Data
      field (in bytes).  Not present in the TP payload.

   *  Initiator Data (variable length): Not present in the TP payload.
      SHALL be inserted by the Initiator if and only if key forking is
      used (I flag).  The first 8 bits identifies the first payload.
      The rest of Initiator Data SHALL be constructed of MIKEY payloads.
      Unexpected payloads in the Initiator Data SHOULD be ignored.

                   Initiator Data = First Payload, Vi, Vr

      The Vi payload SHALL be identical to the V payload in the
      TRANSFER_INIT message.

      The last payload (Vr) SHALL be a Verification payload where the
      MAC SHALL cover the entire Initiator Data field except the MAC
      field itself.  The authentication algorithm SHALL be the same as
      used for the Vi payload.  The authentication key (auth_key) SHALL
      be derived from MPKr (not forked) using the following parameters:

      inkey:     : MPKr
      inkey_len  : bit length of the inkey
      label      : constant || 0xFF || 0xFFFFFFFF || 0x04
      outkey_len : desired bit length of the outkey (encr_key,
                   auth_key, salt_key)

      The constant depends on the derived key type as defined in Section
      4.1.4 of [RFC3830].



(page 43 continued on part 3)

Next RFC Part