Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFsWorld Map

RFC 6043


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

Part 3 of 3, p. 43 to 58
Prev RFC Part


prevText      Top      Up      ToC       Page 43 
7.  Transport Protocols

   MIKEY messages are not tied to any specific transport protocols.  In
   [RFC4567], extensions for SDP and RTSP to carry MIKEY messages (and
   therefore MIKEY-TICKET messages) are defined.  The messages in the
   Ticket Transfer exchange (TRANSFER_INIT, TRANSFER_RESP) are
   preferably included in the session setup signaling (e.g., SIP INVITE
   and 200 OK).  However, it may not be suitable for the MIKEY-TICKET
   exchanges that do not establish keying material for media sessions
   (Ticket Request and Ticket Resolve) to be carried in SDP or RTSP.  If
   SDP or RTSP is not used, the transport protocol needs to be defined.
   In [3GPP.33.328], it is defined how the Ticket Request and Ticket
   Resolve exchanges are carried over HTTP.

8.  Pre-Encrypted Content

   The default setting is that the KMS supplies the session keys
   (encoded in the ticket).  This is not possible if the content is pre-
   encrypted (e.g., Video on Demand).  In such use cases, the key

Top      Up      ToC       Page 44 
   exchange is typically reversed and MAY be carried out as follows.
   The Initiator sends a ticket without encoded session keys to the
   Responder in a TRANSFER_INIT message.  The Responder has access to
   the TEKs used to protect the requested content, but may not be
   streaming the content.  The Responder includes the TEK in the
   TRANSFER_RESP message, which is sent to the Initiator.

   +---+                                                           +---+
   | I |                                                           | R |
   +---+                                                           +---+
                               TRANSFER_RESP {KEMAC}

              Figure 6: Distribution of pre-encrypted content

9.  Group Communication

   What has been discussed up to now can also be used for group
   communication.  The MIKEY signaling for multi-party sessions can be
   centralized as illustrated in Figure 7.

   +---+                           +---+                           +---+
   | A |                           | B |                           | C |
   +---+                           +---+                           +---+
              Ticket Transfer
     <------------------------------->        Ticket Transfer

              Figure 7: Centralized signaling around party A

   or decentralized as illustrated in Figure 8.

   +---+                           +---+                           +---+
   | A |                           | B |                           | C |
   +---+                           +---+                           +---+
              Ticket Transfer
     <------------------------------->        Ticket Transfer

                     Figure 8: Decentralized signaling

   In the decentralized scenario, the identities of B and C SHALL be
   used in the second Ticket Transfer exchange.  Independent of the how
   the MIKEY signaling is done, a group key may be used as session key.

Top      Up      ToC       Page 45 
   If a group key is used, the group key and session information may be
   pushed to all group members (similar to [RFC3830]), or distributed
   when requested (similar to [RFC4738]).  If a TGK/GTGK is used as a
   group key, the same RANDs MUST be used to derive the session keys in
   all Ticket Transfer exchanges.  Also note caveats with ticket reuse
   in group communication settings as discussed in Section 5.3.

9.1.  Key Forking

   When key forking is used, only the user that requested the ticket can
   initiate a Ticket Transfer exchange using that ticket, see
   Section 5.3.  So if a group key is to be distributed, the MIKEY
   signaling MUST be centralized to the party that initially requested
   the ticket, or different tickets needs to be used in each Ticket
   Transfer exchange and the group key needs to be sent in a KEMAC.

   Another consideration is that different users get different session
   keys if TGKs (encoded in the ticket) are used.

10.  Signaling between Different KMSs

   A user can in general only be expected to have a trust relation with
   a single KMS.  Different users might therefore use tickets issued by
   different KMSs using only locally known keys.  Thus, if users with
   trust relations to different KMSs are to be able to establish a
   secure session with each other, the KMSs involved have to cooperate
   and there has to be a trust relation between them.  The KMSs SHALL be
   mutually authenticated and signaling between them SHALL be integrity
   and confidentiality protected.  The technical means for the inter-KMS
   security is however outside the scope of this specification.  Under
   these assumptions, the following approach MAY be used.

   +---+               +---+              +-------+            +-------+
   | I |               | R |              | KMS R |            | KMS I |
   +---+               +---+              +-------+            +-------+
     -------------------->    RESOLVE_INIT
                         - - - - - - - - - - ->    RESOLVE_INIT
                                              - - - - - - - - - - ->
                              RESOLVE_RESP    <- - - - - - - - - - -
         TRANSFER_RESP   < - - - - - - -  - - -

                   Figure 9: Routing of resolve messages

Top      Up      ToC       Page 46 
   If the Responder cannot directly resolve a ticket, the ticket SHOULD
   be included in a RESOLVE_INIT message sent to a KMS.  If the
   Responder does not have a shared credential with the KMS that issued
   the ticket (KMS I) or if the Responder does not know which KMS issued
   the ticket, the Responder SHOULD send the RESOLVE_INIT message to one
   of the Responder's trusted KMSs (KMS R).  If KMS R did not issue the
   ticket, KMS R would normally be unable to directly resolve the ticket
   and must hence ask another KMS to resolve it (typically the issuing

   The signaling between different KMSs MAY be done with a Ticket
   Resolve exchange as illustrated in Figure 9.  The IDRr and TICKET
   payloads from the previous RESOLVE_INIT message SHOULD be reused.
   Note that IDRr cannot be used to look up the pre-shared key/

11.  Adding New Ticket Types to MIKEY-TICKET

   The Ticket Data (in the TICKET payload) could be a reference to
   information (keys, etc.) stored by the key management service, it
   could contain all the information itself, or it could be a
   combination of the two alternatives.  For systems serving many users,
   it is not ideal to use the reference-only ticket approach as this
   would force the key management service to keep state of all issued
   tickets that are still valid.  Tickets may carry many different types
   of information helping to enforce usage policies.  The policies may
   be group policies or per-user policies.

   Tickets may either be transparent, meaning they can be resolved
   without contacting the KMS that generated them, or opaque, meaning
   that the original KMS must be contacted.  The ticket information
   SHOULD typically be integrity protected and certain fields need
   confidentiality protection, in particular, the keys if explicitly
   included.  Other types of information may also require
   confidentiality protection due to privacy reasons.  In mode 2 (see
   Section 4.1.1), it may be preferable to include several encrypted
   ticket protection keys (similar to Secure/Multipurpose Internet Mail
   Extensions (S/MIME)) as this may allow multiple peers to resolve the

   The Ticket Data MUST include information so that the resolving party
   can retrieve an encoded KEMAC.  It MUST also be possible to verify
   the integrity of the TICKET payload.  It is RECOMMENDED that future
   specifications use the recommended payload order and do not add any
   additional payloads or processing.  New Ticket Types SHOULD NOT
   change the processing for the Responder.  If a new Ticket Type

Top      Up      ToC       Page 47 
   requires additional processing, it MUST be indicated in the Ticket
   Policy (N and O flags).  New specifications MUST specify which modes
   are supported and if any additional security considerations apply.

12.  Security Considerations

   Unless otherwise stated, the security considerations in [RFC3830]
   still apply and contain notes on the security properties of the MIKEY
   protocol, key derivation functions, and other components.  As some
   security properties depend on the specific Ticket Type, only generic
   security considerations concerning the MIKEY-TICKET framework are

   This specification includes a large number of optional features,
   which adds complexity to the general case.  Protocol designers are
   strongly encouraged to establish strict profiles defining MIKEY-
   TICKET options (e.g., exchanges or message fields) that SHOULD or
   MUST be supported.  Such profiles should preclude unexpected
   consequences from compliant implementations with wildly differing
   option sets.

12.1.  General

   In addition to the Ticket Policy, the KMS MAY have its own set of
   policies (authorized key lengths, algorithms, etc.) that in some way
   are shared with the peers.  The KMS MAY also provide keying material
   to authorized intermediate nodes performing various network functions
   (e.g., transcoding services, recording services, conference bridges).
   The key management service can enforce end-to-end security by only
   distributing the keys to authorized end-users.  As in [RFC3830], the
   user identities are not confidentiality protected.  If user privacy
   is needed, some kind of Privacy Enhancing Technologies (PET) like
   anonymous or temporary credentials MAY be used.

   In the standard MIKEY modes [RFC3830], the keys are generated by the
   Initiator (or by both peers in the Diffie-Hellman scheme).  If a bad
   PRNG (Pseudorandom Number Generator) is used, this is likely to make
   any key management protocol sensitive to different kinds of attacks,
   and MIKEY is no exception.  As the choice of the PRNG is
   implementation specific, the easiest (and often bad) choice is to use
   the PRNG supplied by the operating system.  In MIKEY-TICKET's default
   mode of operation, the key generation is mostly done by the KMS,
   which can be assumed to be less likely to use a bad random number
   generator.  All keys (including keys used to protect the ticket) MUST
   have adequate strength/length, i.e., 128 bits or more.

Top      Up      ToC       Page 48 
   The use of random nonces (RANDs) in the key derivation is of utmost
   importance to counter offline pre-computation attacks and other
   generic attacks.  A key of length n, using RANDs of length r, has
   effective key entropy of (n + r) / 2 against a birthday attack.
   Therefore, the sum of the lengths of RANDRi and RANDRr MUST at least
   be equal to the size of the longest pre-shared key/envelope key/MPK/
   TGK/GTGK, RANDRkms MUST at least be as long as the longest MPKr/TGK,
   and the RAND in the MIKEY base ticket MUST at least be as long as the
   longest of TPK and MPK.

   Note that the CSB Updating messages reuse the old RANDs.  This means
   that the total effective key entropy (relative to pre-computation
   attacks) for k consecutive key updates, assuming the TGKs are each n
   bits long, is still no more than n bits.  In other words, the time
   and memory needed by an attacker to get all k n-bit keys are
   proportional to 2^n.  While this might seem like a defect, this is in
   practice (for all reasonable values of k) not better than brute
   force, which on average requires k * 2^(n-1) work (even if different
   RANDs would be used).  A birthday attack would only require 2^(n/2)
   work, but would need access to 2^(n/2) sessions protected with
   equally many different keys using a single pair of RANDs.  This is,
   for typical values of n, clearly totally infeasible.  The success
   probability of such an attack can be controlled by limiting the
   number of updates correspondingly.  As stated in [RFC3830], the fact
   that more than one key can be compromised in a single attack is
   inherent to any solution using secret- or public-key algorithms.  An
   attacker always gets access to all the exchanged keys by doing an
   exhaustive search on the pre-shared key/envelope key/MPK.  This
   requires 2^m work, where m is the effective size of the key.

   As the Responder MAY generate a RAND, the Ticket Transfer exchange
   can provide mutual freshness guarantee for all derived keys.

   The new algorithms PRF-HMAC-SHA-256, AES-CM-256, and HMAC-SHA-256-256
   use 256-bit keys and offer a higher security level than the
   previously defined algorithms.  If one of the 256-bit algorithms are
   supported, the other two algorithms SHALL also be supported.  The
   256-bit algorithms SHOULD be used together, and they SHALL NOT be
   mixed with algorithms using key sizes less than 256 bits.  If session
   keys (TEK/TGK/GTGK) longer than 128 bits are used, 128-bit algorithms
   SHALL NOT be used.

12.2.  Key Forking

   In some situations, the TRANSFER_INIT message may be delivered to
   multiple endpoints.  For example, when a Responder is registered on
   several devices (e.g., mobile phone, fixed phone, and computer) or
   when an invite is being made to addresses of the type

Top      Up      ToC       Page 49, a group of users where only one is supposed
   to answer.  The Initiator may not even always know exactly who the
   authorized group members are.  To prevent all forms of eavesdropping,
   entities other than the endpoint that answers MUST NOT get access to
   the session keys.

   When key forking is not used, keys are accessible by everyone that
   can resolve the ticket.  When key forking is used, some keys (MPKr
   and TGKs encoded in the ticket) are modified, making them
   cryptographically unique for each responder targeted by the forking.
   As only the Initiator and the KMS have access to the master TGKs, it
   is infeasible for anyone else to derive the session keys.

   When key forking is used, some keys (MPKi and TEKs and GTGK encoded
   in the ticket) are still accessible by everyone that can resolve the
   ticket and should be used with this in mind.  This also concerns
   session keys transferred in a KEMAC in the first TRANSFER_INIT (as
   they are protected with MPKi).

12.3.  Denial of Service

   This protocol is resistant to denial-of-service attacks against the
   KMS in the sense that it does not construct any state (at the key
   management protocol level) before it has authenticated the Initiator
   or Responder.  Since the Responder, in general, cannot verify the
   validity of a TRANSFER_INIT message without first contacting the KMS,
   denial of service may be launched against the Responder and/or the
   KMS via the Responder.  Typical prevention methods such as rate-
   limiting and ACL (Access Control List) capability SHOULD therefore be
   implemented in the KMS as well as the clients.  If something in the
   signaling is suspicious, the Responder SHOULD abort before attempting
   a RESOLVE_INIT with the KMS.  The types and amount of prevention
   needed depends on how critical the system is and may vary depending
   on the Ticket Type.

12.4.  Replay

   In a replay attack, an attacker may intercept and later retransmit
   the whole or part of a MIKEY message, attempting to trick the
   receiver (Responder or KMS) into undesired operations, e.g., leading
   to a lack of key freshness.  MIKEY-TICKET implements several
   mechanisms to prevent and detect such attacks.  Timestamps together
   with a replay cache efficiently stop the replay of entire MIKEY
   messages.  Parts of the received messages (or their hashes) can be
   saved in the replay cache until their timestamp is outdated.  To
   prevent replay attacks, the sender's (Initiator or Responder) and the
   receiver's (Responder or KMS) identity is always (explicitly or
   implicitly) included in the MAC/Signature calculation.

Top      Up      ToC       Page 50 
   An attacker may also attempt to replay a ticket by inserting it into
   a new MIKEY message.  A possible scenario is that Alice and Bob first
   communicate based on a ticket, which an attacker Mallory intercepts.
   Later, Mallory (acting as herself) invites Bob by inserting the
   ticket into her own TRANSFER_INIT message.  If key forking is used,
   such replays will always be detected when Bob has resolved the
   ticket.  If key forking is not used, such replays will be detected
   unless Mallory has knowledge of the MPKi.  And if Mallory has
   knowledge of the MPKi (i.e., she is authorized to resolve the ticket)
   and key forking is not used, there is no attack.  For the reasons
   explained above, it is RECOMMENDED to use key forking.

12.5.  Group Key Management

   In a group scenario, only authorized group members must have access
   to the keys.  In some situation, the communication may be initiated
   by the Initiator using a group identity and the Initiator may not
   even know exactly who the authorized group members are.  Moreover,
   group membership may change over time due to leaves/joins.  In such a
   situation, it is foremost the responsibility of the KMS to reject
   ticket resolution requests from unauthorized responders, implying
   that the KMS needs to be able to map an individual's identity
   (carried in the RESOLVE_INIT message) to group membership (where the
   group identity is carried in the ticket).

   As noted, reuse of tickets, which bypasses the KMS, is NOT
   RECOMMENDED when the Initiator is not fully ensured about group
   membership status.

13.  Acknowledgements

   The authors would like to thank Fredrik Ahlqvist, Rolf Blom, Yi
   Cheng, Lakshminath Dondeti, Vesa Lehtovirta, Fredrik Lindholm, Mats
   Naslund, Karl Norrman, Oscar Ohlsson, Brian Rosenberg, Bengt Sahlin,
   Wei Yinxing, and Zhu Yunwen for their support and valuable comments.

14.  IANA Considerations

   This document defines several new values for the namespaces Data
   Type, Next Payload, PRF func, CS ID map type, Encr alg, MAC alg, TS
   Type, ID Type, Hash func, Error no, and Key Data Type defined in
   [RFC3830].  The following IANA assignments were added to the MIKEY
   Payload registry (in parentheses is a reference to the table
   containing the registered values):

   o  Data Type (see Table 6.1)

   o  Next Payload (see Table 6.2)

Top      Up      ToC       Page 51 
   o  PRF func (see Table 6.3)

   o  CS ID map type (see Table 6.4)

   o  Encr alg (see Table 6.5)

   o  MAC alg (see Table 6.6)

   o  TS Type (see Table 6.7)

   o  ID Type (see Table 6.9)

   o  Hash func (see Table 6.11)

   o  Error no (see Table 6.13)

   o  Key Data Type (see Table 6.14)

   The TR payload defines an 8-bit TS Role field for which IANA has
   created and will maintain a new namespace in the MIKEY Payload
   registry.  Assignments consist of a TS Role name and its associated
   value.  Values in the range 1-239 SHOULD be approved by the process
   of Specification Required, values in the range 240-254 are Reserved
   for Private Use, and the values 0 and 255 are Reserved according to
   [RFC5226].  The initial contents of the registry are as follows:

                  Value    TS Role
                  -------  ------------------------------
                  0        Reserved
                  1        Time of issue (TRi)
                  2        Start of validity period (TRs)
                  3        End of validity period (TRe)
                  4        Rekeying interval (TRr)
                  5-239    Unassigned
                  240-254  Reserved for Private Use
                  255      Reserved

   The IDR payload defines an 8-bit ID Role field for which IANA has
   created and will maintain a new namespace in the MIKEY Payload
   registry.  Assignments consist of an ID Role name and its associated
   value.  Values in the range 1-239 SHOULD be approved by the process
   of Specification Required, values in the range 240-254 are Reserved
   for Private Use, and the values 0 and 255 are Reserved according to
   [RFC5226].  The initial contents of the registry are as follows:

Top      Up      ToC       Page 52 
                     Value    ID Role
                     -------  -----------------------
                     0        Reserved
                     1        Initiator (IDRi)
                     2        Responder (IDRr)
                     3        KMS (IDRkms)
                     4        Pre-Shared Key (IDRpsk)
                     5        Application (IDRapp)
                     6-239    Unassigned
                     240-254  Reserved for Private Use
                     255      Reserved

   The RANDR payload defines an 8-bit RAND Role field for which IANA has
   created and will maintain a new namespace in the MIKEY Payload
   registry.  Assignments consist of a RAND Role name and its associated
   value.  Values in the range 1-239 SHOULD be approved by the process
   of Specification Required, values in the range 240-254 are Reserved
   for Private Use, and the values 0 and 255 are Reserved according to
   [RFC5226].  The initial contents of the registry are as follows:

                     Value    RAND Role
                     -------  ------------------
                     0        Reserved
                     1        Initiator (RANDRi)
                     2        Responder (RANDRr)
                     3        KMS (RANDRkms)
                     4-239    Unassigned
                     240-254  Reserved for Private Use
                     255      Reserved

   The TP/TICKET payload defines a 16-bit Ticket Type field for which
   IANA has created and will maintain a new namespace in the MIKEY
   Payload registry.  Assignments consist of a Ticket Type name and its
   associated value.  Values in the range 1-61439 SHOULD be approved by
   the process of Specification Required, values in the range 61440-
   65534 are Reserved for Private Use, and the values 0 and 65535 are
   Reserved according to [RFC5226].  The initial contents of the
   registry are as follows:

                   Value        Ticket Type
                   -----------  -----------------
                   0            Reserved
                   1            MIKEY base ticket
                   2            3GPP base ticket
                   3-61439      Unassigned
                   61440-65534  Reserved for Private Use
                   65535        Reserved

Top      Up      ToC       Page 53 
15.  References

15.1.  Normative References

   [FIPS.180-3]   National Institute of Standards and Technology,
                  "Secure Hash Standard (SHS)", FIPS PUB 180-3,
                  October 2008, <

   [RFC2104]      Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:
                  Keyed-Hashing for Message Authentication", RFC 2104,
                  February 1997.

   [RFC2119]      Bradner, S., "Key words for use in RFCs to Indicate
                  Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3830]      Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and
                  K. Norrman, "MIKEY: Multimedia Internet KEYing",
                  RFC 3830, August 2004.

   [RFC4330]      Mills, D., "Simple Network Time Protocol (SNTP)
                  Version 4 for IPv4, IPv6 and OSI", RFC 4330,
                  January 2006.

   [RFC4563]      Carrara, E., Lehtovirta, V., and K. Norrman, "The Key
                  ID Information Type for the General Extension Payload
                  in Multimedia Internet KEYing (MIKEY)", RFC 4563,
                  June 2006.

   [RFC4567]      Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and
                  E. Carrara, "Key Management Extensions for Session
                  Description Protocol (SDP) and Real Time Streaming
                  Protocol (RTSP)", RFC 4567, July 2006.

   [RFC4738]      Ignjatic, D., Dondeti, L., Audet, F., and P. Lin,
                  "MIKEY-RSA-R: An Additional Mode of Key Distribution
                  in Multimedia Internet KEYing (MIKEY)", RFC 4738,
                  November 2006.

   [RFC5226]      Narten, T. and H. Alvestrand, "Guidelines for Writing
                  an IANA Considerations Section in RFCs", BCP 26,
                  RFC 5226, May 2008.

15.2.   Informative References

   [3GPP.33.328]  3GPP, "IP Multimedia Subsystem (IMS) media plane
                  security", 3GPP TS 33.328 9.3.0, December 2010.

Top      Up      ToC       Page 54 
   [Otway-Rees]   Otway, D., and O. Rees, "Efficient and Timely Mutual
                  Authentication", ACM SIGOPS Operating Systems
                  Review v.21 n.1, p.8-10, January 1987.

   [RFC3261]      Rosenberg, J., Schulzrinne, H., Camarillo, G.,
                  Johnston, A., Peterson, J., Sparks, R., Handley, M.,
                  and E. Schooler, "SIP: Session Initiation Protocol",
                  RFC 3261, June 2002.

   [RFC4120]      Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
                  Kerberos Network Authentication Service (V5)",
                  RFC 4120, July 2005.

   [RFC4650]      Euchner, M., "HMAC-Authenticated Diffie-Hellman for
                  Multimedia Internet KEYing (MIKEY)", RFC 4650,
                  September 2006.

   [RFC5197]      Fries, S. and D. Ignjatic, "On the Applicability of
                  Various Multimedia Internet KEYing (MIKEY) Modes and
                  Extensions", RFC 5197, June 2008.

   [RFC5479]      Wing, D., Fries, S., Tschofenig, H., and F. Audet,
                  "Requirements and Analysis of Media Security
                  Management Protocols", RFC 5479, April 2009.

Top      Up      ToC       Page 55 
Appendix A.  MIKEY Base Ticket

   The MIKEY base ticket MAY be used in any of the modes described in
   Section 4.1.1.  The Ticket Data SHALL be constructed of MIKEY
   payloads and SHALL be protected by a MAC based on a pre-shared Ticket
   Protection Key (TPK).  The parties that shares the TPK depends on the
   mode.  Unexpected payloads in the Ticket Data SHOULD be ignored.

              Ticket Data = THDR, T, RAND, KEMAC, [IDRpsk], V

A.1.  Components of the Ticket Data

   The Ticket Data MUST always begin with a Ticket Header payload
   (THDR).  The ticket header is a new payload type; for the definition,
   see Appendix A.3.

   T is a timestamp containing the time of issue or a counter.  It MAY
   be used in the IV (Initialization Vector) formation (e.g., Section
   4.2.3 of [RFC3830]).

   RAND is used as input to the key derivation function when keys are
   derived from the TPK and the MPK (see Appendices A.2.1 and A.2.2).

   The KEMAC payload SHALL use the NULL authentication algorithm, as a
   MAC is included in the V payload.  The encryption key (encr_key) and
   salting key (salt_key) SHALL be derived from the TPK (see
   Appendix A.2.1).  Depending on the encryption algorithm, the salting
   key be used in the IV creation (see Section 4.2.3 of [RFC3830]).  If
   CSB ID is needed in the IV creation it SHALL be set to '0xFFFFFFFF'.
   The KEMAC is hence constructed as follows:

                 KEMAC = E(encr_key, MPK || {TEK|TGK|GTGK})

   MPKi and MPKr are derived from the MPK as defined in Appendix A.2.2.

   IDRpsk contains an identifier that enables the KMS/Responder to
   retrieve the TPK.  It MAY be omitted when the TPK can be retrieved

   The last payload SHALL be a Verification payload (V) where the
   authentication key (auth_key) is derived from the TPK.  The MAC SHALL
   be calculated over the entire TICKET payload except the Next Payload
   field (in the TICKET payload), the Initiator Data length field, the
   Initiator Data field, and the MAC field itself.

Top      Up      ToC       Page 56 
A.2.  Key Derivation

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

A.2.1.  Deriving Keys from a TPK

   In the following, we describe how keying material is derived from a
   TPK.  The key derivation method SHALL be executed using the PRF
   indicated in the Ticket Policy.  The parameters for the PRF are:

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

   Length RAND is the length of RAND in bytes as an 8-bit unsigned
   integer.  The constants are as defined in Section 4.1.4 of [RFC3830].
   The key derivation and its dependencies on Ticket Data contents when
   AES-CM is used are illustrated in Figure 10.  The key derivation is
   done by the party that creates the ticket (KMS or Initiator) and by
   the party that resolves the ticket (KMS or Responder).  The
   encryption key and the IV are used to encrypt the KEMAC.

                                 -----          auth_key        ------
              -----     TPK     |     |----------------------->| AUTH |
             | TPK |----------->|     |       encr_key          ------
              -----             | PRF |--------------------+       |
                ^           +-->|     |     salt_key       |       |
                :           |   |     |----------------+   |       |
                :           |    -----                 |   |       |
                :           |                          v   |       |
       identify :      RAND |            TS value    ----  |       | MAC
                :           |         +------------>| IV | |       |
                :           |         |              ----  |       |
                :           |         |             IV |   |       |
                :           |         |                v   v       v
   Ticket   +---+----+---+--+---+---+-+-+------------+-------+---+---+
    Data    | IDRpsk |...| RAND |...| T |............| KEMAC |...| V |

                    Figure 10: Deriving keys from a TPK

Top      Up      ToC       Page 57 
A.2.2.  Deriving MPKi and MPKr

   In the following, we describe how MPKi and MPKr are derived from the
   MPK in the KEMAC payload.  The key derivation method SHALL be
   executed using the PRF indicated in the Ticket Policy.  The
   parameters for the PRF are:

   inkey:     : MPK
   inkey_len  : bit length of the inkey
   label      : constant || 0xFF || 0xFFFFFFFF || 0x06 ||
                length RAND || RAND
   outkey_len : desired bit length of the outkey (MPKi, MPKr)
                SHALL be equal to inkey_len

   Length RAND is the length of RAND in bytes as an 8-bit unsigned
   integer.  The constant depends on the derived key type as summarized

                          Derived key | Constant
                          MPKi        | 0x220E99A2
                          MPKr        | 0x1F4D675B

                Table A.1: Constants for MPK key derivation

   The constants are taken from the decimal digits of e as described in

A.3.  Ticket Header Payload (THDR)

   The ticket header payload contains an indicator of the next payload
   as well as implementation-specific data.

    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  !        THDR Data length       !   THDR Data   ~

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

   *  THDR Data length (16 bits): the length of the THDR Data field (in

   *  THDR Data (variable length): implementation specific data that
      SHOULD be ignored if it is not expected.

Top      Up      ToC       Page 58 
Appendix B.  Alternative Use Cases

B.1.  Compatibility Mode

   MIKEY-TICKET can be used to define a Ticket Type compatible with
   [RFC3830] or any other half-round-trip key management protocol.  The
   Initiator requests and gets a ticket from the KMS where the Ticket
   Data is a [RFC3830] message protected with a pre-shared key
   (KMS-Responder) or with the Responder's certificate.  The Ticket Data
   is then sent to the Responder according to [RFC3830].  In this way,
   the Initiator can communicate with a Responder that only supports
   [RFC3830] and with whom the Initiator do not have any shared

   +---+                          +-----+                          +---+
   | I |                          | KMS |                          | R |
   +---+                          +-----+                          +---+
                                3830 MIKEY

                       Figure 11: Compatibility mode

Authors' Addresses

   John Mattsson
   Ericsson AB
   SE-164 80 Stockholm

   Phone: +46 10 71 43 501

   Tian Tian
   ZTE Corporation
   4F, RD Building 2, Zijinghua Road
   Yuhuatai District, Nanjing 210012
   P.R. China

   Phone: +86-025-5287-7867