[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02 03 04 05 RFC 6043

Network Working Group                                        J. Mattsson
Internet-Draft                                                  Ericsson
Updates: 3830 (if approved)                                      T. Tian
Intended status: Informational                                       ZTE
Expires: August 3, 2010                                 January 30, 2010


          MIKEY-TICKET: An Additional Mode of Key Distribution
                 in Multimedia Internet KEYing (MIKEY)
                     draft-mattsson-mikey-ticket-01

Abstract

   The Multimedia Internet KEYing (MIKEY) specification describes a key
   management scheme for real-time applications.  In this document, we
   note that the currently defined MIKEY modes are insufficient to
   address deployment scenarios built around a centralized key
   management service.  Such deployments are gaining in interest.
   Therefore, a new MIKEY mode that works well in such scenarios is
   defined.  The new mode uses a trusted key management service and a
   ticket concept, similar to that in Kerberos.  The new mode also
   supports features required by many existing applications, e.g. so
   called forking where the exact identity of the other endpoint may not
   be known at the start of the communication session.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 3, 2010.




Mattsson & Tian          Expires August 3, 2010                 [Page 1]


Internet-Draft                MIKEY-TICKET                  January 2010


Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.1.  Definitions and Notation . . . . . . . . . . . . . . . . .  5
     2.2.  Abbreviations  . . . . . . . . . . . . . . . . . . . . . .  6
     2.3.  Payloads . . . . . . . . . . . . . . . . . . . . . . . . .  6
   3.  Design Considerations  . . . . . . . . . . . . . . . . . . . .  7
   4.  A New Mode: MIKEY-TICKET . . . . . . . . . . . . . . . . . . .  9
     4.1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . .  9
       4.1.1.  Modes  . . . . . . . . . . . . . . . . . . . . . . . . 12
     4.2.  Exchanges  . . . . . . . . . . . . . . . . . . . . . . . . 13
       4.2.1.  Ticket Request . . . . . . . . . . . . . . . . . . . . 13
       4.2.2.  Ticket Transfer  . . . . . . . . . . . . . . . . . . . 17
       4.2.3.  Ticket Resolve . . . . . . . . . . . . . . . . . . . . 19
   5.  Key Management Functions . . . . . . . . . . . . . . . . . . . 22
     5.1.  Key Derivation . . . . . . . . . . . . . . . . . . . . . . 22
       5.1.1.  Deriving Forked Keys . . . . . . . . . . . . . . . . . 24
       5.1.2.  Deriving Keys from an Envelope/Pre-Shared Key/MPK  . . 25
     5.2.  Deriving Keys from a TGK . . . . . . . . . . . . . . . . . 26
       5.2.1.  Deriving Keys from a GTGK  . . . . . . . . . . . . . . 26
     5.3.  CSB Updating . . . . . . . . . . . . . . . . . . . . . . . 26
     5.4.  Ticket Reuse . . . . . . . . . . . . . . . . . . . . . . . 27
     5.5.  MAC/Signature Coverage . . . . . . . . . . . . . . . . . . 28
   6.  Payload Encoding . . . . . . . . . . . . . . . . . . . . . . . 28
     6.1.  Common Header Payload (HDR)  . . . . . . . . . . . . . . . 29
     6.2.  Key Data Transport Payload (KEMAC) . . . . . . . . . . . . 30
     6.3.  Timestamp Payload (T)  . . . . . . . . . . . . . . . . . . 31
     6.4.  Timestamp Payload with Role Indicator (TR) . . . . . . . . 31
     6.5.  ID Payload (ID)  . . . . . . . . . . . . . . . . . . . . . 32
     6.6.  ID Payload with Role Indicator (IDR) . . . . . . . . . . . 32
     6.7.  Cert Hash Payload (CHASH)  . . . . . . . . . . . . . . . . 33



Mattsson & Tian          Expires August 3, 2010                 [Page 2]


Internet-Draft                MIKEY-TICKET                  January 2010


     6.8.  Error Payload (ERR)  . . . . . . . . . . . . . . . . . . . 33
     6.9.  Key Data Sub-Payload . . . . . . . . . . . . . . . . . . . 34
     6.10. Ticket Payload (TICKET)  . . . . . . . . . . . . . . . . . 34
     6.11. Ticket Policy Payload (TP) . . . . . . . . . . . . . . . . 35
   7.  Transport Protocols  . . . . . . . . . . . . . . . . . . . . . 37
   8.  Group Communication  . . . . . . . . . . . . . . . . . . . . . 37
     8.1.  Key Forking  . . . . . . . . . . . . . . . . . . . . . . . 38
   9.  Signaling Between Different KMSs . . . . . . . . . . . . . . . 39
   10. Adding New Ticket Types to MIKEY-TICKET  . . . . . . . . . . . 40
   11. Security Considerations  . . . . . . . . . . . . . . . . . . . 40
     11.1. General  . . . . . . . . . . . . . . . . . . . . . . . . . 41
     11.2. Denial of Service  . . . . . . . . . . . . . . . . . . . . 42
     11.3. Replay . . . . . . . . . . . . . . . . . . . . . . . . . . 42
     11.4. Forking  . . . . . . . . . . . . . . . . . . . . . . . . . 43
     11.5. Group Key Management . . . . . . . . . . . . . . . . . . . 43
   12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 44
   13. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 44
   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 46
     14.1. Normative References . . . . . . . . . . . . . . . . . . . 46
     14.2. Informative References . . . . . . . . . . . . . . . . . . 47
   Appendix A.  MIKEY Base Ticket . . . . . . . . . . . . . . . . . . 47
     A.1.  Components of the Ticket Data  . . . . . . . . . . . . . . 48
     A.2.  Deriving Keys from a TPK . . . . . . . . . . . . . . . . . 48
     A.3.  Deriving MPKi and MPKr . . . . . . . . . . . . . . . . . . 49
     A.4.  Ticket Header Payload (THDR) . . . . . . . . . . . . . . . 49
   Appendix B.  Alternative Use Cases . . . . . . . . . . . . . . . . 50
     B.1.  Compatibility Mode . . . . . . . . . . . . . . . . . . . . 50
     B.2.  Distribution of Pre-Encrypted Content  . . . . . . . . . . 50
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 51






















Mattsson & Tian          Expires August 3, 2010                 [Page 3]


Internet-Draft                MIKEY-TICKET                  January 2010


1.  Introduction

   Key management systems are either based on negotiation and exchange
   directly between peers (e.g.  Diffie-Hellman based schemes), pre-
   distribution of user credentials (shared secrets/certificates), or
   availability of a trusted Key Management Service (KMS).  The modes
   described in the Multimedia Internet KEYing (MIKEY) specification
   [RFC3830] and its extensions [RFC4650] [RFC4738] are all variants of
   the first two alternatives.

   In security systems serving a large number of users, a solution based
   on a key management service is often preferred.  With such a service
   in place, there is no need to pre-distribute credentials that
   directly can be used to establish security associations between peers
   for protected communication, as users can request such credentials
   when needed.  Solutions based on a trusted key management service
   also scale well when the number of users grows.

   This document introduces a set of new MIKEY modes that go under the
   common name MIKEY-TICKET.  It supports a ticket concept, similar to
   that in Kerberos [RFC4120], which is used to identify and deliver
   keys.  A high level outline of MIKEY-TICKET as defined herein is that
   the Initiator requests keys and a ticket from the KMS and sends the
   ticket containing a reference to the keys, or the enveloped keys, to
   the Responder.  The Responder then sends the ticket to the KMS, which
   returns the appropriate keys.

   MIKEY-TICKET is primarily designed to be used for media plane
   security in the 3GPP IP Multimedia Subsystem (IMS) [3GPP.33.328].
   This implies that some extensions to the basic Kerberos concept are
   needed.  For instance, the Initiator may not always know the exact
   identity of the Responder when the communication with the key
   management server is initiated; SIP forking (see [RFC3261]) is one
   such situation.

   This document updates [RFC3830] with the MIKEY-TICKET mode.  It
   defines a signaling framework enabling peers to request, transfer,
   and resolve various Ticket Types using a key management service.  A
   default Ticket Type is also defined.  To allow the use of 256-bit
   keys for users with high security requirements, additional
   encryption, authentication, and pseudo-random functions are defined.


2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].



Mattsson & Tian          Expires August 3, 2010                 [Page 4]


Internet-Draft                MIKEY-TICKET                  January 2010


   Definitions of terms and notation will, unless otherwise stated, be
   as defined in [RFC3830].

2.1.  Definitions and Notation

   Forking: In SIP, forking is the delivery of a request (e.g.  INVITE)
   to multiple endpoints.

   Key forking: When used in conjunction with forking, key forking
   refers to the process of modifying keys, making them
   cryptographically unique for each responder targeted by the forking.

   (Media) session: The communication session intended to be secured by
   the MIKEY-TICKET provided key(s).

   Session information: Information related to the security protocols
   used to protect the media session: keys, salts, algorithms, etc.

   Ticket: A Kerberos-like object used to identify and deliver keys over
   an untrusted network.

   Ticket Data: Ticket part with information intended only for the party
   that resolves the ticket (e.g. keys).

   Ticket Request: Exchange used by the Initiator to request keys and a
   ticket from a trusted KMS.

   Ticket Transfer: Exchange used to transfer the ticket as well as
   session information from the Initiator to the Responder.

   Ticket Resolve: Exchange used by the Responder to request the KMS to
   return the keys encoded in a ticket.

   Ticket Policy: Policy for ticket generation and resolution,
   authorized applications, key derivation, etc.

   Ticket Type: Defines ticket format and processing.  May further have
   subtype and version.

   Solid arrows  (----->) indicate mandatory messages.
   Dashed arrows (- - ->) indicate optional messages.

   E(k, p)   Encryption of p with the key k
   PKx       Public Key of entity x
   k'        The forked key k
   [p]       p is optional
   {p}       Zero or more occurrences of p
   (p)       One or more occurrences of p



Mattsson & Tian          Expires August 3, 2010                 [Page 5]


Internet-Draft                MIKEY-TICKET                  January 2010


   ||        Concatenation
   |         OR (selection operator)

2.2.  Abbreviations

   3GPP:     3rd Generation Partnership Project
   AAA:      Authentication, Authorization, and Accounting
   ACL:      Access Control List
   CA:       Certificate Authority
   CS:       Crypto Session
   CSB:      Crypto Session Bundle
   DDoS:     Distributed Denial of Service
   DoS:      Denial of Service
   EKT:      Encrypted Key Transport
   IMS:      IP Multimedia Subsystem
   GTGK:     Group TGK
   KDC:      Key Distribution Center
   KMS:      Key Management Service
   KTC:      Key Translation Center
   MAC:      Message Authentication Code
   MIKEY:    Multimedia Internet KEYing
   NSPS:     National Security and Public Safety
   MKI:      Master Key Identifier
   MPK:      MIKEY Protection Key
   NTP:      Network Time Protocol
   PET:      Privacy Enhancing Technologies
   PK:       Public-Key
   PRF:      Pseudo-Random Function
   PRNG:     Pseudo-Random Number Generator
   PSK:      Pre-Shared Key
   RTSP:     Real-Time Streaming Protocol
   SDP:      Session Description Protocol
   SIP:      Session Initiation Protocol
   SPI:      Security Parameters Index
   TEK:      Traffic Encryption Key
   TGK:      TEK Generation Key
   TPK:      Ticket Protection Key
   UTC:      Coordinated Universal Time

2.3.  Payloads

   CERTx:    Certificate of entity x
   CHASH:    Hash of the certificate used
   HDR:      Common Header payload
   ID:       Identity payload
   IDRx:     Identity of entity x
   IDRpsk:   Identifier for pre-shared key
   IDRapp:   Identifier for application/service



Mattsson & Tian          Expires August 3, 2010                 [Page 6]


Internet-Draft                MIKEY-TICKET                  January 2010


   KEMAC:    Key data transport payload
   PKE:      Encrypted envelope key
   RANDx:    Random value generated by entity x
   SIGNx:    Signature created using entity x's private key
   SP:       Security Policy payload
   T:        Timestamp payload
   TRy:      Timestamp payload with role indicator y
   THDR:     Ticket Header payload
   TICKET:   Ticket payload
   TP:       Ticket Policy payload
   V:        Verification payload

   where
      x is in the set {i, r, kms} (Initiator, Responder, KMS) and
      y is in the set {i, s, e, r} (time of Issue, Start time, End time,
         Reykeying interval).

   The IDR, TR, TICKET, and TP payloads are defined in Section 6.  Note
   that in [RFC3830], there is defined both a V payload (carrying the
   authentication tag) and a V flag in the HDR payload (indicating
   whether a response message is expected or not).


3.  Design Considerations

   As mentioned in the introduction, none of the previously defined
   MIKEY modes are based on a KMS.  The pre-shared key method and the
   public-key encryption method defined in [RFC3830] are examples of
   systems based on pre-distribution of user credentials.  The Diffie-
   Hellman method [RFC3830] is an example of a system based on
   negotiation and exchange directly between peers.

   In SIP, forking is the delivery of a request (e.g.  INVITE) to
   multiple endpoints.  This happens 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
   somebody@company.example, a group of users where only one is supposed
   to answer.  To prevent any form of eavesdropping, only the endpoint
   that answers should get access to the session keys.  The naive
   application of [RFC3830] where all endpoints share the same pre-
   shared/private key is not secure when it comes to forking as all
   endpoints get access to the session keys.  Conversely, having per-
   user unique pre-shared keys/certificates creates more fundamental
   problems with forking, as the initiator does not know which pre-
   shared key/certificate to use at session initiation.  Forking is
   described in [RFC5479] and the applicability of different MIKEY modes
   is discussed in [RFC5197].




Mattsson & Tian          Expires August 3, 2010                 [Page 7]


Internet-Draft                MIKEY-TICKET                  January 2010


   Deferred delivery of end-to-end protected content excludes all key
   management schemes that are based on some type of direct online
   negotiation between peers (e.g.  Diffie-Hellman based schemes) as the
   responder cannot rely on contacting the initiator to get access to
   keys.

   In security systems serving a large number of users, a solution based
   on a key management service is often preferred.  With such a service
   in place, there is no need to pre-distribute credentials that
   directly can be used to establish security associations between peers
   for protected communication, as users can request such credentials
   when needed.  In many applications, e.g.  National Security and
   Public Safety (NSPS), the controlling organization wants to enforce
   policies on the use of keys.  A trusted KMS fits these applications
   well as it makes it easier to enforce policies centrally.  Solutions
   based on a trusted KMS also scale well when the number of users
   grows.  A KMS based on symmetric keys has particular advantages as
   symmetric key algorithms are generally much less computationally
   intensive than asymmetric key algorithms.

   Systems based on a key management service require a signaling
   mechanism that allows peers to retrieve other peers' credentials.  A
   convenient way to implement such a signaling scheme is to use a
   ticket concept, similar to that in Kerberos [RFC4120], to identify
   and deliver keys.  The ticket can be forwarded in the signaling
   associated with the session setup.  The initiator requests a ticket
   from the key management service and sends the ticket to the
   responder.  The responder forwards the ticket to the key management
   service, which returns the corresponding keys.  It should here be
   noted that Kerberos typically does not require that the responder
   also contacts the key management service.  However, in order to
   support also the aforementioned forking scenarios it becomes
   necessary that the ticket is not bound to the exact identity (or
   credentials) of the responder until the final responder becomes fully
   determined.  Group and forking communication scenarios can also be
   improved from access control point of view if authorization to access
   the keys can be enforced with higher granularity at the responder
   side.

   The ticket can contain a reference to keys held by the key management
   system or it can hold the keys itself.  In the latter case, the
   ticket needs to be confidentiality and integrity protected
   (enveloped).  In the following, the term encoded keys will be used to
   describe both cases as well as keys derived from such keys.

   By using different Ticket Types and ticket policies, some allowing
   the initiator or responder to create or resolve the tickets without
   assistance from the KMS, a wide range of different security levels



Mattsson & Tian          Expires August 3, 2010                 [Page 8]


Internet-Draft                MIKEY-TICKET                  January 2010


   and use cases can be supported.  This has a number of advantages as
   it offers a framework which is flexible enough to satisfy users with
   a broad range of security and functional needs.  The authorization
   function in the KMS could also be used to help solve the key access
   problem in forking and retargeting scenarios.  The problems with
   retargeting are similar to forking.  The use of a ticket based system
   may also help in the handling of keys for deferred delivery of end-
   to-end protected content to currently off-line users.

   At the same time, it is also important to be aware that (centralized)
   key management services may introduce a single point of (security)
   failure.  The security requirements on the implementation and
   protection of the KMS may therefore in high security applications be
   more or less equivalent to the requirements of an AAA
   (Authentication, Authorization, and Accounting) server or a
   Certificate Authority (CA).


4.  A New Mode: MIKEY-TICKET

4.1.  Overview

   All previously defined MIKEY modes consist of a single (or half)
   round-trip between two peers.  MIKEY-TICKET differs from these modes
   as it consists of up to three different round-trips (Ticket Request,
   Ticket Transfer, and Ticket Resolve) involving three parties
   (Initiator, Responder, and KMS).  Since the number of round-trips and
   order of messages may vary, MIKEY-TICKET is actually the common name
   for a set of modes, all revolving around a ticket concept.  The third
   party, the KMS, is only involved in some of the MIKEY exchanges and
   not at all in the resulting secure media session.  The Ticket Request
   and Ticket Resolve exchanges are meant to be used in combination with
   the Ticket Transfer exchange and not on their own.  In Figure 1, the
   signaling for the full three round-trip MIKEY-TICKET mode is
   depicted.
















Mattsson & Tian          Expires August 3, 2010                 [Page 9]


Internet-Draft                MIKEY-TICKET                  January 2010


   +---+                          +-----+                          +---+
   | I |                          | KMS |                          | R |
   +---+                          +-----+                          +---+
               REQUEST_INIT
     -------------------------------->
               REQUEST_RESP
     <--------------------------------
                               TRANSFER_INIT
     ---------------------------------------------------------------->
                                                RESOLVE_INIT
                                     <--------------------------------
                                                RESOLVE_RESP
                                     -------------------------------->
                               TRANSFER_RESP
     <----------------------------------------------------------------

                 Figure 1: Full three round-trip signaling

   The Initiator (I) wants to establish a secure media session with the
   Responder (R).  The Initiator and the Responder do not share any
   credentials, instead they trust a third party, the KMS, with which
   they both have or can establish shared credentials.  The assumed
   trust model is illustrated in Figure 2.

      Pre-established trust relation   Pre-established trust relation
     <------------------------------> <------------------------------>
   +---+                          +-----+                          +---+
   | I |                          | KMS |                          | R |
   +---+                          +-----+                          +---+
     <--------------------------------------------------------------->
                   Security association based on ticket

                           Figure 2: Trust model

   Note that rather than a single KMS, multiple KMSs may be involved,
   e.g. one for the Initiator and one for the Responder; this is
   discussed in Section 9.

   The Initiator requests keys and a ticket (encoding the same keys)
   from the KMS by sending a REQUEST_INIT message.  The REQUEST_INIT
   message includes session information (e.g. identities of the
   authorized responders) and is integrity protected by a MAC based on a
   pre-shared key or by a signature (similar to the pre-shared key and
   public-key encryption modes in [RFC3830]).  If the request is
   authorized, the KMS generates the requested keys, encodes them in a
   ticket, and returns the keys and the ticket in a REQUEST_RESP
   message.  The Ticket Request exchange is optional (depending on the
   Ticket Type), and MAY be omitted if the Initiator can create the



Mattsson & Tian          Expires August 3, 2010                [Page 10]


Internet-Draft                MIKEY-TICKET                  January 2010


   ticket without assistance from the KMS.

   The Initiator next includes the ticket in a TRANSFER_INIT message,
   which is sent to the Responder.  The TRANSFER_INIT message is
   protected by a MAC based on a MPK (MIKEY Protection Key) encoded in
   the ticket.  If the Responder finds the proposed Ticket Policy and
   session security policies acceptable, the Responder forwards the
   ticket to the KMS.  This is done with a RESOLVE_INIT message, which
   asks the KMS to return the keys encoded in the ticket.  The
   RESOLVE_INIT message is protected by a MAC based on a pre-shared key
   (between Responder and KMS) or by a signature.  The Ticket Resolve
   exchange is optional (depending on the Ticket Policy), and SHOULD
   only be used when the Responder is unable to resolve the ticket
   without assistance from the KMS.

   The KMS resolves the ticket.  If the Responder is authorized to
   receive the keys encoded in the ticket, the KMS retrieves the keys
   and other information.  If key forking is used, the keys are modified
   (bound to the Responder) by the KMS, see Section 5.1.1.  The keys and
   additional information are then sent in a RESOLVE_RESP message to the
   Responder.  The Responder then sends a TRANSFER_RESP message to the
   Initiator as verification.  The TRANSFER_RESP message might include
   information used for further key derivation.

   The use case and signaling described above is the full three exchange
   mode but other modes are allowed, see Section 4.1.1.  Group
   communication is discussed in Section 8 and signaling between
   different KMSs is discussed in Section 9.  Some alternative use cases
   are discussed in Appendix B.

   MIKEY-TICKET offers a framework which is flexible enough to satisfy
   users with a broad range of security and functional needs.  The
   framework consists of the three exchanges for which different Ticket
   Types can be defined.  The ticket consists of a Ticket Policy as well
   as Ticket Data.  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 Data 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.  The format of the Ticket Data
   depends on the Ticket Type signaled in the Ticket Policy.  The Ticket
   Data corresponding to the Ticket Type called MIKEY base ticket is
   given in Appendix A and requirements regarding new Ticket Types are
   given in Section 10.

   As MIKEY-TICKET is based on [RFC3830], the same terminology,
   processing and considerations still apply unless otherwise stated.
   Just like in [RFC3830], the messages are integrity protected and



Mattsson & Tian          Expires August 3, 2010                [Page 11]


Internet-Draft                MIKEY-TICKET                  January 2010


   encryption is only applied to the keys and not to the entire
   messages.  Depending on the mode, the KMS might operate as a KDC (Key
   Distribution Center) and supply the keys, as a KTC (Key Translation
   Center) and re-encode and forward keys supplied by the Initiator, or
   as a combination of the two (see [HBOAC]).

4.1.1.  Modes

   Depending on the Ticket Type and the Ticket Policy, some of the
   exchanges might be optional or not used at all, see Figure 3.  If the
   ticket protection is based on a key known only by the KMS, both the
   Initiator and the Responder have to contact the KMS to request/
   resolve tickets (mode 1).  If the key used to protect the ticket is
   shared between the KMS and the Responder, the Ticket Resolve exchange
   can be omitted (similar to Kerberos), as the Responder can resolve
   the ticket without assistance from the KMS (mode 2).

      +---+                       +-----+                       +---+
      | I |                       | KMS |                       | R |
      +---+                       +-----+                       +---+
                Ticket Request
   (1)  <---------------------------->       Ticket Transfer
        <--------------------------------------------------------->
                                     <---------------------------->
                                             Ticket Resolve
                Ticket Request
   (2)  <---------------------------->       Ticket Transfer
        <--------------------------------------------------------->

                              Ticket Transfer
   (3)  <--------------------------------------------------------->
                                     <---------------------------->
                                             Ticket Resolve

                              Ticket Transfer
   (4)  <--------------------------------------------------------->

                              Figure 3: Modes

   If the key protecting the ticket is shared between the Initiator and
   the KMS, the Ticket Request exchange can be omitted (similar to the
   Otway-Rees protocol [Otway-Rees]), as the Initiator can create the
   ticket without assistance from the KMS (mode 3).  If the key
   protecting the ticket is shared between the Initiator and the
   Responder, both the Ticket Request and Ticket Resolve exchanges can
   be omitted (mode 4).  This can be seen as a variation of the pre-
   shared key method of [RFC3830] with mutual key freshness guarantee.




Mattsson & Tian          Expires August 3, 2010                [Page 12]


Internet-Draft                MIKEY-TICKET                  January 2010


   In mode 1 and 2 the Ticket Request can be omitted if the tickets and
   the corresponding keys are distributed in some other way.

4.2.  Exchanges

4.2.1.  Ticket Request

   This exchange is used by the Initiator to request keys and a ticket
   from a trusted KMS, with which the Initiator has pre-shared
   credentials.  The request contains information (e.g. participant
   identities, etc.) describing the session the ticket is intended to
   protect.  A full round-trip is required for the Initiator to receive
   the ticket.  The initial message REQUEST_INIT comes in two variants.
   The first variant corresponds to the pre-shared key (PSK) method of
   [RFC3830].

   Initiator                               KMS

   REQUEST_INIT_PSK =              ---->
   HDR, T, RANDi, [IDRi],
      [IDRkms], TP, [KEMAC],        <----  REQUEST_RESP =
      [IDRpsk], V                          HDR, T, [IDRkms],
                                              TICKET, KEMAC, V

   The second variant corresponds to the public-key (PK) method of
   [RFC3830].

   Initiator                               KMS

   REQUEST_INIT_PK =               ---->
   HDR, T, RANDi, [IDRi], {CERTi},
      [IDRkms], TP, [KEMAC],        <----  REQUEST_RESP =
      [CHASH], PKE, SIGNi                  HDR, T, [IDRkms],
                                              TICKET, KEMAC, V

   As the REQUEST_INIT message MUST ensure the identity of the Initiator
   to the KMS, it SHALL be integrity protected by a MAC based on a pre-
   shared key or by a signature.  The response message REQUEST_RESP is
   the same for the two variants and SHALL be protected by using the
   pre-shared/envelope key indicated in the REQUEST_INIT message.

   In addition to the ticket, the Initiator receives keys, which it does
   not already know.  The ticket contains both session information and
   information needed to resolve the ticket later, see Section 6.10.







Mattsson & Tian          Expires August 3, 2010                [Page 13]


Internet-Draft                MIKEY-TICKET                  January 2010


4.2.1.1.  Common Components of the REQUEST_INIT Messages

   The REQUEST_INIT message MUST always include the Header (HDR),
   Timestamp (T), and RANDi payloads.

   In HDR the CSB ID (Crypto Session Bundle ID) SHALL be assigned as in
   [RFC3830].  The V flag MUST be set to '1' but SHALL be ignored by the
   KMS as a response is MANDATORY.  As Crypto Sessions (CS) SHALL NOT be
   handled, the #CS MUST be set to 0 and the CS ID map type SHALL be the
   "Empty map" as defined in [RFC4563].

   IDRi contains the identity of the Initiator.  This identity SHOULD be
   included in the granted Ticket Policy (TP).

   IDRkms contains the identity of the KMS.  It SHOULD be included, but
   it MAY be left out when it can be expected that the KMS has a single
   identity.

   TP contains the desired Ticket Policy (see Section 6.11).  It
   includes for instance, the identities of authorized responders.

   The KEMAC payload is used by the Initiator to indicate the number of
   requested keys, specify other key information (key type, key length,
   KV (key validity) data [RFC3830]), and specify the Key Data itself.
   Initiator specified Key Data in a KMS generated ticket SHOULD NOT be
   used unless the Initiator has pre-encrypted content and specific TEKs
   (Traffic Encryption Keys) need to be included in the ticket.  See
   Section 6.2 and Appendix B.2 for details.

4.2.1.2.  Components of the REQUEST_INIT_PSK Message

   The IDRi payload SHOULD be included but MAY be left out when it can
   be expected that the KMS can identify the Initiator by other means.

   The KEMAC payload SHOULD use the NULL authentication algorithm, as a
   MAC is included in the V payload.  The encryption key (encr_key) and
   salting key used to encrypt the KEMAC SHALL be derived from the pre-
   shared key (Initiator-KMS) (see Section 5.1.2 for key derivation
   specification).  The salting key goes into the IV as defined in
   [RFC3830].  The KEMAC is hence constructed as follows:

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

   The IDRpsk payload is used to indicate the pre-shared key used.  It
   MAY be omitted if the KMS can find the pre-shared key by other means.

   The last payload SHALL be a Verification payload (V) where the
   authentication key (auth_key) is derived from the pre-shared key



Mattsson & Tian          Expires August 3, 2010                [Page 14]


Internet-Draft                MIKEY-TICKET                  January 2010


   (Initiator-KMS) (see Section 5.1.2 for key derivation specification).
   The MAC SHALL cover the entire message as well as the identities of
   the involved parties (see Section 5.5 for the exact definition).

4.2.1.3.  Components of the REQUEST_INIT_PK Message

   The identity IDRi and certificate CERTi SHOULD be included, but they
   MAY be left out when it can be expected that the KMS can obtain the
   certificate in some other manner.  If a certificate chain is to be
   provided, each certificate in the chain SHOULD be included in a
   separate CERT payload.

   PKE contains the encrypted envelope key: PKE = E(PKkms, env_key).  It
   is encrypted using the KMS's public key (PKkms).  If the KMS
   possesses several public keys, the Initiator can indicate the key
   used in the CHASH payload.

   The KEMAC payload MUST include an identity payload (IDRi) and a MAC
   calculated over the KEMAC.  The identity MUST be equal to the
   identity specified in the certificate.  The reason to bind the
   identity to the keys is to stop a man-in-the-middle-attack where an
   attacker includes the KEMAC and PKE payloads in a new REQUEST_INIT
   message with herself as an authorized responder.  The encr_key,
   salt_key, and auth_key SHALL be derived from the envelope key (see
   Section 5.1.2 for key derivation specification).  The salting key
   goes into the IV as defined in [RFC3830].  The KEMAC is hence
   constructed as follows:

               KEMAC = E(encr_key, IDRi || (TGK|TEK)) || MAC

   SIGNi is a signature covering the entire MIKEY message, using the
   Initiator's signature key (see Section 5.5 for the exact definition).

4.2.1.4.  Processing the REQUEST_INIT Message

   If the KMS can verify the integrity of the received message, the
   message can be correctly parsed, and the Initiator is authorized to
   receive the requested ticket, possibly with a modified Ticket Policy,
   the KMS MUST send a REQUEST_RESP message.  Otherwise the KMS SHOULD
   send an appropriate Error message.  In case of a REQUEST_INIT_PK
   message, the KMS MUST ensure that the identity in the KEMAC payload
   is equal to the identity specified in the certificate.

4.2.1.5.  Components of the REQUEST_RESP Message

   The Header payload SHOULD be identical to the Header payload in the
   REQUEST_INIT message with the exception of data type, next payload,
   and V flag.  The V flag has no meaning in this context.  It SHALL be



Mattsson & Tian          Expires August 3, 2010                [Page 15]


Internet-Draft                MIKEY-TICKET                  January 2010


   set to 0 by the KMS and ignored by the Initiator.

   The timestamp type and value SHALL be identical to the one used in
   the REQUEST_INIT message.

   The TICKET payload carries the granted TP payload and Ticket Data
   (see Section 6.10).  As the KMS decides which Ticket Policy to use,
   this may not be the same Ticket Policy as the Initiator requested.
   The Ticket Type and the Ticket Data depend on the granted Ticket
   Policy.

   The KEMAC payload SHOULD use the NULL authentication algorithm, as a
   MAC is included in the V payload.  Depending on the type of
   REQUEST_INIT message, either the pre-shared key or the envelope key
   SHALL be used to derive the encr_key and salt_key.  The salting key
   goes into the IV as defined in [RFC3830].  If the REQUEST_INIT
   message does not contain a KEMAC, it is RECOMMENDED that the KMS's
   default KEMAC includes a single TGK.  The KEMAC SHALL include a MPK
   (MIKEY Protection Key), MPKi, used as a pre-shared key to protect the
   messages in the Ticket Transfer exchange.  If key forking (see
   Section 5.1.1) is used (determined by the Ticket Policy) a second
   MPK, MPKr, SHALL be included in the KEMAC.  Then MPKi SHALL be used
   to protect the TRANSFER_INIT message and MPKr SHALL be used to verify
   the TRANSFER_RESP message.  The KEMAC is hence constructed as
   follows:

              KEMAC = E(encr_key, MPKi || [MPKr] || (TGK|TEK))

   The last payload SHALL be a Verification payload (V).  Depending on
   the type of REQUEST_INIT message, either the pre-shared key or the
   envelope key SHALL be used to derive the auth_key.  The MAC SHALL
   cover the entire message as well as the INIT message (see Section 5.5
   for the exact definition).

4.2.1.6.  Processing the REQUEST_RESP Message

   If the Initiator can verify the integrity of the received message and
   the message can be correctly parsed, the ticket and the associated
   session information SHOULD be stored.  Otherwise the Initiator SHOULD
   silently discard the message.

   Before using the received ticket, the Initiator SHOULD check that the
   granted Ticket Policy is acceptable.  If not, the Initiator SHALL
   either silently discard or send a new REQUEST_INIT message suggesting
   a different Ticket Policy than before.






Mattsson & Tian          Expires August 3, 2010                [Page 16]


Internet-Draft                MIKEY-TICKET                  January 2010


4.2.2.  Ticket Transfer

   This exchange is used to transfer a ticket as well as session
   information from the Initiator to a Responder.  The exchange is
   modeled after the pre-shared key mode [RFC3830], and the session
   information is forwarded in the same way with the exception that the
   keys are encoded in a TICKET payload instead of a KEMAC payload.  As
   the motive for this exchange is to setup a shared secret key between
   Initiator and Responder, the Responder cannot check the authenticity
   of the message before the ticket is resolved (by KMS or Responder).
   A full round-trip is required if Responder key confirmation and
   freshness guarantee are needed.  The messages are preferably included
   in the session setup signaling (e.g.  SIP INVITE and 200 OK).

   Initiator                               Responder

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

4.2.2.1.  Components of the TRANSFER_INIT Message

   The TRANSFER_INIT message MUST always include the Header (HDR),
   Timestamp (T), and RANDi payloads.

   In HDR, the CSB ID (Crypto Session Bundle ID) SHALL be assigned as in
   [RFC3830].  The value of the V flag SHALL agree with the Ticket
   Policy (TP) and it SHALL be ignored by the Responder.

   The IDRi and IDRr payloads SHOULD be included but they MAY be left
   out when it can be expected that the Responder has a single identity
   and can identify the Initiator by other means.

   The use of the SP (Security Policy) payload is identical to that in
   [RFC3830].

   The TICKET payload contains the Ticket Policy to be applied when
   resolving the ticket as well as the Ticket Data.

   The last payload SHALL be a Verification payload (V) where the
   authentication key (auth_key) is derived from the MPKi (see
   Section 5.1.2 for key derivation specification).  The MAC SHALL cover
   the entire message as well as the identities of the involved parties
   (see Section 5.5 for the exact definition).




Mattsson & Tian          Expires August 3, 2010                [Page 17]


Internet-Draft                MIKEY-TICKET                  January 2010


4.2.2.2.  Processing the TRANSFER_INIT Message

   As the Initiator and Responder do not have any pre-shared keys, the
   Responder cannot check the authenticity of the message before the
   ticket is resolved.  The Responder SHOULD however check that both the
   Ticket Policy (TP) and the security policy (SP) are acceptable.  If
   they are not, the Responder SHOULD reject without contacting the KMS.
   This is an early reject mechanism to avoid unnecessary KMS signaling
   when the Responder can conclude from the information at hand that it
   will not accept the connection.  After the ticket has been resolved
   the parsing of the TRANSFER_INIT message continues and SHALL be done
   as in [RFC3830].

4.2.2.3.  Components of the TRANSFER_RESP Message

   The Header payload SHOULD be identical to the Header payload in the
   TRANSFER_INIT message with the exception that the V flag has no
   meaning in this context.  It SHALL be set to 0 by the Responder and
   ignored by the Initiator.

   The timestamp type and value SHALL be identical to the one used in
   the TRANSFER_INIT message.

   If indicated by the Ticket Policy, the Responder SHALL generate a
   fresh (pseudo-)random byte string RANDr.  RANDr is used to produce
   Responder freshness guarantee in key derivations.

   If the Responder receives an IDRr payload in the RESOLVE_RESP
   message, the same identity MUST be sent in an IDRr payload in the
   TRANSFER_RESP message.  The identity sent in the IDRr payload in the
   TRANSFER_RESP message (e.g. user1@company.example) MAY differ from
   the one sent in the IDRr payload in the TRANSFER_INIT message (e.g.
   somebody@company.example).

   If the Responder receives a RANDkms payload in the RESOLVE_RESP
   message, the same RAND MUST be sent in a RANDkms payload in the
   TRANSFER_RESP message.  The RANDkms payload MUST be placed after the
   RANDr payload to avoid ambiguity.

   The SP and KEMAC payloads SHALL be processed exactly as if they were
   received in a later CSB update Section 5.3.

   The last payload SHALL be a Verification payload (V) where the
   authentication key (auth_key) is derived from MPKi or MPKr'
   (depending on if key forking is used).  The MAC SHALL cover the
   entire message as well as the TRANSFER_INIT message (see Section 5.5
   for the exact definition).




Mattsson & Tian          Expires August 3, 2010                [Page 18]


Internet-Draft                MIKEY-TICKET                  January 2010


4.2.2.4.  Processing the TRANSFER_RESP Message

   If the Initiator cannot verify the integrity of the received message
   or the message cannot be parsed the Initiator SHOULD silently discard
   the message.

4.2.3.  Ticket Resolve

   This exchange is used by the Responder to request the KMS to return
   the keys encoded in a ticket.  The KMS does not need to be the same
   KMS that originally issued the ticket, see Section 9.  A full round-
   trip is required for the Responder to receive the keys.  The Ticket
   Resolve exchange is optional (depending on the Ticket Policy), and
   SHOULD only be used when the Responder is unable to resolve the
   ticket without assistance from the KMS.  The initial message
   RESOLVE_INIT comes in two variants (independent from the used
   REQUEST_INIT variant).  The first variant corresponds to the pre-
   shared key (PSK) method of [RFC3830].

   Responder                               KMS

   RESOLVE_INIT_PSK =              ---->
   HDR, T, RANDr, [IDRr],
      [IDRkms], TICKET,             <----  RESOLVE_RESP
      [IDRpsk], V                          HDR, T, [IDRkms], KEMAC,
                                              [IDRr], [RANDkms], V

   The second variant corresponds to the public-key (PK) method of
   [RFC3830].

   Responder                               KMS

   RESOLVE_INIT_PK =               ---->
   HDR, T, RANDr, [IDRr], {CERTr},
      [IDRkms], TICKET,             <----  RESOLVE_RESP
      [CHASH], PKE, SIGNr                  HDR, T, [IDRkms], KEMAC,
                                              [IDRr], [RANDkms], V

   As the RESOLVE_INIT message MUST ensure the identity of the Responder
   to the KMS, it SHALL be protected by a MAC based on a pre-shared key
   or by a signature.  The response message RESOLVE_RESP is the same for
   the two variants and SHALL be protected by using the pre-shared/
   envelope key indicated in the RESOLVE_INIT message.

   Upon receiving the RESOLVE_INIT message, the KMS verifies that the
   Responder is authorized to resolve the ticket based on ticket and KMS
   policies.  The KMS extracts the session information from the ticket
   and returns this to the Responder.  Since the KMS resolved the



Mattsson & Tian          Expires August 3, 2010                [Page 19]


Internet-Draft                MIKEY-TICKET                  January 2010


   ticket, the Responder is assured of the integrity of the Ticket
   Policy (TP), which contains the identity of the peer that requested
   or created the ticket.  The Responder can complete the session
   information it got from the Initiator with the additional session
   information received from the KMS.

4.2.3.1.  Common Components of the RESOLVE_INIT Messages

   The RESOLVE_INIT message MUST always include the Header (HDR),
   Timestamp (T), and RANDr payloads.

   The CSB ID (Crypto Session Bundle ID) SHALL be assigned as in
   [RFC3830].  The V flag MUST be set to '1' but SHALL be ignored by the
   KMS as a response is MANDATORY.  As crypto sessions SHALL NOT be
   handled, the #CS MUST be set to 0 and the CS ID map type SHALL be the
   "Empty map" as defined in [RFC4563].

   IDRkms SHOULD be included, but it MAY be left out when it can be
   expected that the KMS has a single identity.

   The TICKET payload contains the Ticket Policy and Ticket Data that
   the Responder wants to have resolved.

4.2.3.2.  Components of the RESOLVE_INIT_PSK Message

   IDRr contains the identity of the Responder.  IDRr SHOULD be
   included, but it MAY be left out when it can be expected that the KMS
   can identify the Responder in some other manner.

   The IDRpsk payload is used to indicate the pre-shared key used.  It
   MAY be omitted if the KMS can find the pre-shared key by other means.

   The last payload SHALL be a Verification payload (V) where the
   authentication key (auth_key) is derived from the pre-shared key.
   The MAC SHALL cover the entire message as well as the identities of
   the involved parties (see Section 5.5 for the exact definition).

4.2.3.3.  Components of the RESOLVE_INIT_PK Message

   The identity IDRr and certificate CERTr SHOULD be included, but they
   MAY be left out when it can be expected that the KMS can obtain the
   certificate in some other manner.  If a certificate chain is to be
   provided, each certificate in the chain SHOULD be included in a
   separate CERT payload.

   PKE contains the encrypted envelope key: PKE = E(PKkms, env_key).  It
   is encrypted using PKkms.  If the KMS possesses several public keys,
   the Responder can indicate the key used in the CHASH payload.



Mattsson & Tian          Expires August 3, 2010                [Page 20]


Internet-Draft                MIKEY-TICKET                  January 2010


   SIGNr is a signature covering the entire MIKEY message, using the
   Responder's signature key (see Section 5.5 for the exact definition).

4.2.3.4.  Processing the RESOLVE_INIT Message

   If the KMS can verify the integrity of the received message and
   Ticket Policy, the message can be correctly parsed, and the Responder
   is authorized to resolve the ticket, the KMS MUST send an
   RESOLVE_RESP message.  Otherwise the KMS SHOULD send an appropriate
   Error message.

4.2.3.5.  Components of the RESOLVE_RESP Message

   The Header payload SHOULD be identical to the Header payload in the
   RESOLVE_INIT message with the exception of data type, next payload,
   and V flag.  The V flag has no meaning in this context.  It SHALL be
   set to 0 by the KMS and ignored by the Responder.

   The timestamp type and value SHALL be identical to the one used in
   the RESOLVE_INIT message.

   The KEMAC payload SHOULD use the NULL authentication algorithm, as a
   MAC is included in the V payload.  Depending on the type of
   RESOLVE_INIT message, either the pre-shared key or the envelope key
   SHALL be used to derive the encr_key and salt_key.  The salting key
   goes into the IV as defined in [RFC3830].  The KEMAC SHALL include a
   MPK (MPKi), used as a pre-shared key to protect the messages in the
   Ticket Transfer exchange.  The KEMAC is hence constructed as follows:

             KEMAC = E(encr_key, MPKi || [MPKr'] || (TGK|TEK))

   If key forking (see Section 5.1.1) is used (determined by the Ticket
   Policy) a second MPK (MPKr') SHALL be included in the KEMAC.  Then
   MPKi SHALL be used to verify the TRANSFER_INIT message and MPKr'
   SHALL be used to protect the TRANSFER_RESP message.  The KMS SHALL
   also fork the MPKr and the TGKs.  The modifier used to derive the
   forked keys SHALL be included in the IDRr and RANDkms payloads, where
   IDRr is the identity of the endpoint that answered and RANDkms is a
   fresh (pseudo-)random byte string generated by the KMS.  The reason
   that the KMS MAY adjust the Responder's identity is so that it
   matches an identity encoded in the ticket.

   The last payload SHALL be a Verification payload (V).  Depending on
   the type of RESOLVE_INIT message, either the pre-shared key or the
   envelope key SHALL be used to derive the auth_key.  The MAC SHALL
   cover the entire message as well as the INIT message (see Section 5.5
   for the exact definition).




Mattsson & Tian          Expires August 3, 2010                [Page 21]


Internet-Draft                MIKEY-TICKET                  January 2010


4.2.3.6.  Processing the RESOLVE_RESP Message

   If the Responder can verify the integrity of the received message and
   the message can be correctly parsed, the Responder SHOULD verify the
   TRANSFER_INIT message with the MPK received from the KMS.  Otherwise
   the Responder SHOULD silently discard the message.

   If the Responder cannot verify the integrity of the received message
   or the message cannot be parsed the Responder SHOULD silently discard
   the message.


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 the pre-
   shared key or the envelope key.  As crypto sessions SHALL NOT be
   handled, further keying material (i.e.  TEKs) SHALL NOT be derived.

   In the Ticket Transfer exchange, the keys used to protect the MIKEY
   messages are derived from a MPK.  If key forking is used, the KMS and
   the Initiator SHALL fork the MPKr and the TGKs 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 with a single RAND are
   illustrated in Figure 4.  The KEMAC shown is the KEMAC sent from the
   KMS.  The illustrated key derivations are done by the Initiator and
   the Responder.


















Mattsson & Tian          Expires August 3, 2010                [Page 22]


Internet-Draft                MIKEY-TICKET                  January 2010


                                +------+------------------+-----+------+
   KEMAC                        | MPKi |..................| TGK | SALT |
                                +--+---+------------------+--+--+--+---+
                                   | MPKi                    |     |
                                   v                         |     |
                       csb_id    -----    auth_key    -----  |     |
                    +---------->| PRF |------------->| MAC | |     |
                    |   cs_id    -----                -----  |     |
                    |              ^                MAC |    |     |
                    |              | RANDi              v    |     |
                 +--+--+-------+---+---+--+--------+--+---+  |     |
   TRANSFER_INIT | HDR |.......| RANDi |..| TICKET |..| V |  |     |
                 +--+--+-------+---+---+--+--------+--+---+  |     |
                    |              | RANDi                   |     |
                    |              v                         |     |
                    |  csb_id    -----           TGK         |     |
                    +---------->| PRF |<---------------------+     |
                        cs_id    -----                             |
                                   |                               |
                                   v TEK                      SALT v
                                ---------------------------------------
                               |      Security Protocol e.g. SRTP      |
                                ---------------------------------------

    Figure 4: Key hierarchy without key forking and with a single RAND

   The key hierarchy and its dependencies on TRANSFER_RESP message
   contents for the case with key forking and two RANDs are illustrated
   in Figure 5.  The KEMAC shown is the KEMAC sent from the KMS to the
   Initiator.  MOD is the modifier (IDRr, RANDkms).  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 RANDi from the
   TRANSFER_INIT message is also used as input to the derivation of the
   auth_key and the TEK, but this is omitted from the figure.  The
   protection of the TRANSFER_INIT message is done as in Figure 4.















Mattsson & Tian          Expires August 3, 2010                [Page 23]


Internet-Draft                MIKEY-TICKET                  January 2010


                       +------+---------------------------+-----+------+
KEMAC                  | MPKr |...........................| TGK | SALT |
                       +--+---+---------------------------+--+--+--+---+
                          | MPKr                             |     |
                          v                                  |     |
                        -----     MPKr'                      |     |
                       | PRF |------------+                  |     |
                        -----             |                  |     |
                          ^               v                  |     |
                          |   csb_id    -----  auth_key      |     |
                 +--------)----------->| PRF |----------+    |     |
                 |        |    cs_id    -----           v    |     |
                 |        |               ^           -----  |     |
                 |        |               |          | MAC | |     |
                 |        | IDRr,         | RANDr     -----  |     |
                 |        | RANDkms       |         MAC |    |     |
                 |        |               |             v    |     |
              +--+--+--+--+--+--------+---+---+-------+---+  |     |
TRANSFER_RESP | HDR |..| MOD |........| RANDr |.......| V |  |     |
              +--+--+--+--+--+--------+---+---+-------+---+  |     |
                 |        |      -----    |                  |     |
                 |        +---->| PRF |<--)------------------+     |
                 |               -----    |        TGK             |
                 |            TGK' |      |                        |
                 |                 v      | RANDr                  |
                 |   csb_id      -----    |                        |
                 +------------->| PRF |<--+                        |
                      cs_id      -----                             |
                                   |                               |
                                   v TEK                      SALT v
                                ---------------------------------------
                               |      Security Protocol e.g. SRTP      |
                                ---------------------------------------

          Figure 5: Key hierarchy with key forking and two RANDs

5.1.1.  Deriving Forked Keys

   When key forking is used (determined by the Ticket Policy), the MPKr
   and TGKs 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 (Pseudo-Random Function) indicated in the
   Ticket Policy (TP).  The parameters for the default PRF are:

   inkey:     : MPKr or TGK
   inkey_len  : bit length of the inkey
   label      : constant || 0xFF || 0xFFFFFFFF || 0x02 ||
                length ID Data || ID Data || length RANDkms || RANDkms



Mattsson & Tian          Expires August 3, 2010                [Page 24]


Internet-Draft                MIKEY-TICKET                  January 2010


   outkey_len : desired bit length of the outkey (MPKr', TGK')

   where ID Data is taken from the IDRr payload sent in the RESOLVE_RESP
   and TRANSFER_RESP messages.  Length ID Data is the length of ID Data
   in bytes as a 16-bit integer.  Length RANDkms is the length of
   RANDkms in bytes as an 8-bit 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/Pre-Shared Key/MPK

   This derivation is 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 the pre-
   shared key or the envelope key.  For the Ticket Transfer exchange,
   the keys are derived from a 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
   the keys derived using the parameters given below.

   inkey:     : envelope key, pre-shared key, or MPKi
   inkey_len  : bit length of the inkey
   label      : constant || 0xFF || csb_id || 0x03 ||
                length RANDi || RANDi
   outkey_len : desired bit length of the output key

   where the constants are as defined in [RFC3830].  The parameters for
   the response messages are given below.

   inkey:     : envelope key, pre-shared key, MPKi, or MPKr'
   inkey_len  : bit length of the inkey
   label      : constant || 0xFF || csb_id || 0x04 ||
                length RANDi || RANDi || length RANDr || [RANDr]
   outkey_len : desired bit length of the output key

   RANDr SHALL be included in the derivation of the keys used to protect
   TRANSFER_RESP if the Ticket Policy determines that it shall be
   present in the TRANSFER_RESP message.  Length RANDi is the length of
   RANDi in bytes as an 8-bit integer.  Length RANDr is the length of



Mattsson & Tian          Expires August 3, 2010                [Page 25]


Internet-Draft                MIKEY-TICKET                  January 2010


   RANDr in bytes as an 8-bit integer.  If RANDr is omitted, lenght
   RANDr SHALL be 0.

5.2.  Deriving Keys from a TGK

   This only affects the Ticket Transfer exchange.  In the following, we
   describe how keying material is derived from a TGK.  If key forking
   is used, 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 default PRF are given below.

   inkey:     : TGK or TGK'
   inkey_len  : bit length of the inkey
   label      : constant || cs_id || csb_id || 0x05 ||
                length Application ID || Application ID ||
                length RANDi || RANDi || length RANDr || [RANDr]
   outkey_len : bit length of the outkey

   where the constants are as defined in Section 4.1.3. of [RFC3830].
   Application ID is an identifier for the security protocol in which
   the derived keys will be used.  Currently, the only defined
   Application ID is "SRTP".  To support other security protocols in
   MIKEY-TICKET, new Application IDs have to be defined.  If the Ticket
   Policy includes one or more IDRapp payloads, Application ID MUST
   correspond to one of them.  RANDr SHALL be included if the Ticket
   Policy determines that it shall be present in the TRANSFER_RESP
   message.  Length ID Data is the length of ID Data in bytes as a 16-
   bit integer.  Length RANDi is the length of RANDi in bytes as an
   8-bit integer.  Length RANDr is the length of RANDr in bytes as an
   8-bit integer.  If RANDr is omitted, lenght RANDr SHALL be 0.

   Note that the ticket may carry a salt.  A security protocol in need
   of a salting key SHALL use the salting key carried in the ticket when
   present.  If a salt is not included, it is possible to derive a
   salting key by using the constant defined in [RFC3830].

5.2.1.  Deriving Keys from a GTGK

   The same key derivation as in Section 5.2 SHALL be done, with the
   exceptions that the GTGK SHALL NOT be forked and the label SHALL NOT
   include RANDr.

5.3.  CSB Updating

   Similar to [RFC3830], MIKEY-TICKET provides a means of updating the
   CSB (Crypto Session Bundle), e.g. transporting new TGK/TEK 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



Mattsson & Tian          Expires August 3, 2010                [Page 26]


Internet-Draft                MIKEY-TICKET                  January 2010


   new crypto session is needed.  The CSB updating MAY be started by
   either the Initiator or the Responder.

   Initiator                               Responder

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


   Responder                               Initiator

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

   The new message exchange MUST use the same CSB ID as the initial
   exchange, but MUST use a new timestamp.  The ticket and other static
   payloads that were provided in the initial exchange SHOULD NOT be
   included.  New RANDs MUST NOT be included in the message exchange
   (the RANDs will only have effect in the initial exchange).  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.

   New keying material SHOULD be sent in a KEMAC payload.  The KEMAC
   SHOULD use the NULL authentication algorithm, as a MAC is included in
   the V payload.  Both messages SHALL be protected with the keys that
   protected the TRANSFER_RESP message in the initial exchange.  If a
   new TGK is exchanged in a CSB update, the new TGK SHALL NOT be
   forked.  The KEMAC is hence constructed as follows:

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

5.4.  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 another user
   and then for a specified time period use this ticket to protect calls
   to 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
   (RANDi, RANDr).  If the Responder has resolved the ticket before, the



Mattsson & Tian          Expires August 3, 2010                [Page 27]


Internet-Draft                MIKEY-TICKET                  January 2010


   Responder does not need to resolve the ticket again.  In that case,
   the same modifier (IDRr, RANDkms) SHALL be used.  If the Ticket
   Policy forbids reuse, 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.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.  Note that in the Transfer Exchange,
   Identity_r in TRANSFER_RESP (e.g. user1@company.example) MAY differ
   from that appearing in TRANSFER_INIT (e.g. somebody@company.example).
   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).

        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

                     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, TICKET,
   and TP 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].




Mattsson & Tian          Expires August 3, 2010                [Page 28]


Internet-Draft                MIKEY-TICKET                  January 2010


6.1.  Common Header Payload (HDR)

   For the Common Header Payload, new values are added to the Data Type
   and the Next Payload name spaces.

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

      Data Type        | Value | Comment
      -----------------+-------+-------------------------------------
      REQUEST_INIT_PSK |  TBD1 | Ticket request initial message (PSK)
      REQUEST_INIT_PK  |  TBD2 | Ticket request initial message (PK)
      REQUEST_RESP     |  TBD3 | Ticket request response message
                       |       |
      TRANSFER_INIT    |  TBD4 | Ticket transfer initial message
      TRANSFER_RESP    |  TBD5 | Ticket transfer response message
                       |       |
      RESOLVE_INIT_PSK |  TBD6 | Ticket resolve initial message (PSK)
      RESOLVE_INIT_PK  |  TBD7 | Ticket resolve initial message (PK)
      RESOLVE_RESP     |  TBD8 | Ticket resolve response message

                     Table 6.1: Data Type (Additions)

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

                       Next Payload | Value | Section
                       -------------+-------+--------
                       TR           | TBD9  | 6.4
                       IDR          | TBD10 | 6.6
                       TICKET       | TBD11 | 6.10
                       TP           | TBD12 | 6.11

                    Table 6.2: Next Payload (Additions)

   *  V (1 bits): flag to indicate whether a response message is
      expected or not.  The V flag SHALL be set to 1 in the REQUEST_INIT
      and RESOLVE_INIT messages and agree with the Ticket Policy in the
      TRANSFER_INIT message.  It SHALL be set to 0 in the response
      messages.  It SHALL be ignored in all messages.

   *  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 | Comments
                    -----------------+-------+---------
                    PRF-HMAC-SHA-256 | TBD13 |




Mattsson & Tian          Expires August 3, 2010                [Page 29]


Internet-Draft                MIKEY-TICKET                  January 2010


                      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 that will be
      handled within the CBS.  It SHALL be set to 0 in the Ticket
      Request and Ticket Resolve exchanges, as crypto sessions SHALL NOT
      be handled.

   *  CS ID map type (8 bits): specifies the method of uniquely mapping
      crypto sessions to the security protocol sessions.  In the Ticket
      Request and Ticket Resolve exchanges, the CS ID map type SHALL be
      the "Empty map" (defined in [RFC4563]) as crypto sessions SHALL
      NOT be handled.

6.2.  Key Data Transport Payload (KEMAC)

   The key data transport payload contains encrypted key data sub-
   payloads.  The keys MAY be supplied by the Initiator or the KMS.  The
   number of keys with Key Data supplied by the Initiator SHALL be
   indicated in the Ticket Policy (see Section 6.11).  Such keys SHALL
   be placed last, after all keys with Key Data supplied by the KMS.

   If the Initiator require something else than the default, the
   Initiator may use the KEMAC in the REQUEST_INIT to indicate the
   number of keys, specify other key information (key type, key length,
   KV data), and specify the Key Data itself.  Initiator specified Key
   Data in a KMS generated ticket SHOULD NOT be used unless the
   Initiator has pre-encrypted content and specific TEKs must be
   included in the ticket.  For keys where the KMS should supply Key
   Data, the Key Data field SHALL be set to 0 by the Initiator and
   ignored by the KMS.

   *  Encr alg (8 bits): besides the algorithms already defined in
      [RFC3830], this specification defines the following additional
      encryption algorithm that may be used to encrypt the Encr data
      field.

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

                      Table 6.4: Encr alg (Additions)




Mattsson & Tian          Expires August 3, 2010                [Page 30]


Internet-Draft                MIKEY-TICKET                  January 2010


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

   *  MAC alg (8 bits): besides the algorithms already defined in
      [RFC3830], this specification defines that the following
      additional authentication algorithm may be used.

                  MAC alg          | Value | Length (bits)
                  -----------------+-------+--------------
                  HMAC-SHA-256-256 | TBD15 |           256

                     Table 6.5: MAC alg (Additions)

      The new authentication algorithm is Hash-based Message
      Authentication Code (HMAC) [RFC2104] in conjunction with SHA-256
      [FIPS.180-3].  It SHOULD be used with a 256-bit authentication
      key.  Note that the MAC coverage depends on the method used.

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 contain
   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 of TS value
                  -----------+-------+-------------------
                  NTP-UTC-32 | TDB16 |            32-bits

                      Table 6.6: TS Type (Additions)

   Note: NTP-UTC-32 SHALL be padded to a 64-bit NTP-UTC timestamp (with
   zeroes in the fractional second part) when used as input for a PRF
   requiring a 64-bit timestamp.

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



Mattsson & Tian          Expires August 3, 2010                [Page 31]


Internet-Draft                MIKEY-TICKET                  January 2010


   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.

    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   ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   *  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
                   Reykeying interval (TRr)       |     4

                          Table 6.7: 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.

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

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

                       Table 6.8: ID Type (Additions)

6.6.  ID Payload with Role Indicator (IDR)

   The IDR payload uses all the fields as 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.







Mattsson & Tian          Expires August 3, 2010                [Page 32]


Internet-Draft                MIKEY-TICKET                  January 2010


    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                    ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   *  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.9: ID Role

      IDRapp is intended to specify the authorized Application IDs (see
      Section 5.2 and Section 6.11)

6.7.  Cert Hash Payload (CHASH)

   *  Hash func (8 bits): besides the algorithms already defined in
      [RFC3830], this specification defines that the following hah
      function algorithm may be used.

                   Hash func | Value | Hash Length (bits)
                   ----------+-------+-------------------
                   SHA-256   | TDB18 |                256

                     Table 6.10: Hash func (Additions)

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

6.8.  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.








Mattsson & Tian          Expires August 3, 2010                [Page 33]


Internet-Draft                MIKEY-TICKET                  January 2010


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

                     Table 6.11: Error no (Additions)

6.9.  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 differences that
   it SHALL NOT be forked and that RANDr SHALL NOT be used when deriving
   keys from it.  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], it is however not known by the Responder before the ticket
   has been resolved.

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

                  Type      | Value | Comments
                  ----------+-------+---------------------
                  GTGK      | TBD21 | Group TGK
                  GTGK+SALT | TBD22 | Group TGK + SALT
                  MPK       | TBD23 | MIKEY Protection Key

                   Table 6.12: Key Data Type (Additions)

6.10.  Ticket Payload (TICKET)

   The ticket payload contains a TP payload (see Section 6.11 ) as well
   as Ticket Data (see Appendix A for an example).  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 TP
   payload.  The Next Payload field in the TP sub-payload SHALL be set
   to Last payload.

    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  !           TP length           !       TP      ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !       Ticket Data length      !          Ticket Data          ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+





Mattsson & Tian          Expires August 3, 2010                [Page 34]


Internet-Draft                MIKEY-TICKET                  January 2010


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

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

   *  TP (variable length): the granted Ticket Policy.

   *  Ticket Data length (16 bits): the length of the Ticket Data field
      (in bytes).

   *  Ticket Data (variable length): The Ticket Data.

6.11.  Ticket Policy Payload (TP)

   The Ticket Policy payload contains a desired or granted Ticket
   Policy.  Note that the flags are not independent as D implies C, F
   implies B, and F implies C.

    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    !   #IGenKeys   !   PRF Func  !A!B!C!D!E!F!G!H!I!
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ! First Payload !          TP Data len          !    TP Data    ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   *  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 |

                          Table 6.13: Ticket Type

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

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

   *  #IGenKeys (8 bits): specifies the number of traffic keys (i.e. not
      MPK) with Key Data supplied by the Initiator encoded in the Ticket
      Data.  The value '255' means 255 or more keys.  This is included
      to give the Responder possibility to reject Initiator generated



Mattsson & Tian          Expires August 3, 2010                [Page 35]


Internet-Draft                MIKEY-TICKET                  January 2010


      keys.

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

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

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

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

   *  D (1 bit): flag to indicate whether the Responder SHALL generate
      RANDr ('1') or if the Responder SHALL NOT generate RANDr ('0').

   *  E (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').

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

   *  G (1 bit): flag to indicate whether the KMS changed the desired
      Ticket Policy or the desired KEMAC ('1') or if it did not ('0').

   *  H (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.

   *  I (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.

   *  First Payload (8 bits): identifies the first payload in TP Data.

   *  TP Data len (16 bits): length of TP Data.

   *  TP Data (variable length): [IDRkms], [IDRi], [TRs], [TRe], [TRr],
      {IDRapp}, (IDRr)







Mattsson & Tian          Expires August 3, 2010                [Page 36]


Internet-Draft                MIKEY-TICKET                  January 2010


      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 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 SHOULD be done.  How the rekeying
      is done is implementation specific.

      IDRapp is an identifier for an authorized application ID.  Zero
      IDRapp payloads means that 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.


7.  Transport Protocols

   As the Ticket Transfer exchange terminates in at most one full round-
   trip, it is applicable for integration into two-way handshake session
   or call signaling protocols such as SIP/SDP and RTSP.  Such
   integration of MIKEY within SIP/SDP and RTSP is defined in [RFC4567].
   Although any such transport protocol defined for general MIKEY
   messages can be used for MIKEY-TICKET, it may not be suitable for the
   MIKEY-TICKET exchanges that do not establish keying material for
   media sessions (Ticket Request and Ticket Resolve), in which case it
   has to be defined how MIKEY is transported over the transport
   protocol in question.


8.  Group Communication

   What has been discussed up to now can also be used to distribute
   group keys for small-size interactive groups.  The MIKEY signaling
   for multi-party sessions can either be centralized as illustrated in
   Figure 6






Mattsson & Tian          Expires August 3, 2010                [Page 37]


Internet-Draft                MIKEY-TICKET                  January 2010


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

                      Figure 6: Centralized signaling

   or decentralized as illustrated in Figure 7.

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

                     Figure 7: Decentralized signaling

   In the decentralized scenario, B's and C's identities SHALL be used
   in the second Ticket Transfer exchange.

   If a (G)TGK is used a group key, the same RANDi MUST be used in all
   TRANSFER_INIT messages and in the case of a TGK, RANDr MUST NOT be
   used in the TRANSFER_RESP message.  Note also caveats with ticket
   reuse in group communication settings as discussed in Section 5.4.

8.1.  Key Forking

   When key forking is used, the MIKEY signaling MUST be centralized to
   the party that initially requested the ticket.  Decentralized
   signaling does not work, as only the user that requested the ticket
   could initiate the Ticket Transfer exchange, see Section 5.4.

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

                      Figure 8: Multi-party rekeying

   Another consideration is that different users get different TEKs if



Mattsson & Tian          Expires August 3, 2010                [Page 38]


Internet-Draft                MIKEY-TICKET                  January 2010


   TGKs (not GTGKs) are used, so if the media mixing (e.g. in a voice
   conference) is decentralized, a new (non-forked) group key MUST be
   distributed before the session starts, see Figure 8.  The rekeying
   does not need to be done with a CSB Updating exchange (see
   Section 5.3); it can be done with any appropriate rekeying mechanism,
   e.g.  EKT (Encrypted Key Transport) [I-D.mcgrew-srtp-ekt].

   Using a group key might also be preferred when centralized media
   mixing is used; the mixer does not have to re-encrypt, which
   minimizes CPU and memory use, and means that an untrusted
   conferencing server can be used.


9.  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
   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 |
   +---+               +---+              +-------+            +-------+
         TRANSFER_INIT
     -------------------->    RESOLVE_INIT
                         - - - - - - - - - - ->    RESOLVE_INIT
                                              - - - - - - - - - - ->
                                                   RESOLVE_RESP
                              RESOLVE_RESP    <- - - - - - - - - - -
         TRANSFER_RESP   < - - - - - - -  - - -
     <--------------------

                   Figure 9: Routing of resolve messages

   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 that
   issued the ticket, the Responder SHOULD send the RESOLVE_INIT message
   to one of the Responder's trusted KMS (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



Mattsson & Tian          Expires August 3, 2010                [Page 39]


Internet-Draft                MIKEY-TICKET                  January 2010


   the issuing KMS).

   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/
   certificate.


10.  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 S/MIME) as this may allow multiple
   peers to resolve the ticket.

   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
   requires additional processing, it MUST be indicated in the TP
   payload.  New specifications MUST specify which modes are supported
   and if any additional security considerations apply.


11.  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



Mattsson & Tian          Expires August 3, 2010                [Page 40]


Internet-Draft                MIKEY-TICKET                  January 2010


   security properties depend on the specific Ticket Type, only generic
   security considerations concerning the MIKEY-TICKET framework are
   discussed.

11.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
   random 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 random number generator
   is implementation specific, the easiest (and often bad) choice is to
   use the PRNG (Pseudo-Random Number Generator) 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.

   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 length of RAND generated by the Initiator MUST at
   least be equal to the length of the pre-shared key/envelope key and
   the sum of the lengths of the RANDs (RANDi, RANDr) MUST at least be
   equal to the key size of the longest TGK.

   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, a 2^n work
   enables an attacker to get all k n-bit keys.  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)



Mattsson & Tian          Expires August 3, 2010                [Page 41]


Internet-Draft                MIKEY-TICKET                  January 2010


   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.

11.2.  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.  Typical prevention methods such as rate-limiting and
   ACL (Access Control List) capability SHOULD be implemented in the KMS
   as well as the clients.  The types and amount of prevention needed
   depends on how critical the system is and may vary depending on the
   Ticket Type.

   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.  The Responder SHOULD therefore implement additional
   protection such as early abort if the Initiator's identity is
   suspicious, if the policy is not acceptable, etc., before attempting
   a RESOLVE_INIT with the KMS.

11.3.  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, leading e.g. to 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 identity
   (Responder or KMS) is always (explicitly or implicitly) included in
   the MAC/Signature calculation.

   An attacker may also attempt to replay a ticket by inserting it into



Mattsson & Tian          Expires August 3, 2010                [Page 42]


Internet-Draft                MIKEY-TICKET                  January 2010


   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.  Unless Mallory has
   knowledge of the MPK encoded in the ticket, such replays will be
   detected when Bob has resolved the ticket.  If Mallory has knowledge
   of the MPK (i.e. she is authorized to resolve the ticket) and key
   forking is used together with a TGK, Mallory will not be able to
   communicate with Bob due to her inability to deduce the session keys.
   If key forking is not used or a TEK or GTGK is used, the session key
   is a group key and there is no attack.  For the reasons explained
   above, it is RECOMMENDED to use key forking and TGKs unless required
   by the use case.

11.4.  Forking

   Forking occurs 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 somebody@company.example, 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, only the endpoint that answers
   should get access to the session keys.

   When key forking is used together with TGKs, the keys 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.

11.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.





Mattsson & Tian          Expires August 3, 2010                [Page 43]


Internet-Draft                MIKEY-TICKET                  January 2010


12.  Acknowledgements

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


13.  IANA Considerations

   This document defines several new values for the namespaces Data
   Type, Next Payload, PRF func, 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 bracket is a reference to the table containing the registered
   values):

   o  Data Type (see Table 6.1)

   o  Next Payload (see Table 6.2)

   o  PRF func (see Table 6.3)

   o  Encr alg (see Table 6.4)

   o  MAC alg (see Table 6.5)

   o  TS Type (see Table 6.6)

   o  ID Type (see Table 6.8)

   o  Hash func (see Table 6.10)

   o  Error no (see Table 6.11)

   o  Key Data Type (see Table 6.12)

   The TR payload defines an 8-bit TS Role field for which IANA is to
   create and 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 for Private
   Use, and the values 0 and 255 are Reserved according to [RFC5226].
   The initial contents of the registry should be as follows:







Mattsson & Tian          Expires August 3, 2010                [Page 44]


Internet-Draft                MIKEY-TICKET                  January 2010


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

   The IDR payload defines an 8-bit ID Role field for which IANA is to
   create and 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 for Private
   Use, and the values 0 and 255 are Reserved according to [RFC5226].
   The initial contents of the registry should be as follows:

                      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  Private Use
                      255      Reserved

   The TP payload defines an 16-bit Ticket Type field for which IANA is
   to create and 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 for
   Private Use, and the values 0 and 65535 are Reserved according to
   [RFC5226].  The initial contents of the registry should be as
   follows:

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



Mattsson & Tian          Expires August 3, 2010                [Page 45]


Internet-Draft                MIKEY-TICKET                  January 2010


14.  References

14.1.  Normative References

   [FIPS.180-3]
              National Institute of Standards and Technology, "Secure
              Hash Standard (SHS)", FIPS PUB 180-3, October 2008, <http:
              //csrc.nist.gov/publications/fips/fips180-3/
              fips180-3_final.pdf>.

   [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.

   [RFC4650]  Euchner, M., "HMAC-Authenticated Diffie-Hellman for
              Multimedia Internet KEYing (MIKEY)", RFC 4650,
              September 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.






Mattsson & Tian          Expires August 3, 2010                [Page 46]


Internet-Draft                MIKEY-TICKET                  January 2010


14.2.   Informative References

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

   [HBOAC]    Menezes, A., Van Oorschot, P., and Vanstone S., "Handbook
              of Applied Cryptography", CRC Press , August 2001.

   [I-D.mcgrew-srtp-ekt]
              McGrew, D., Andreasen, F., Wing, D., and L. Dondeti,
              "Encrypted Key Transport for Secure RTP",
              draft-mcgrew-srtp-ekt-06 (work in progress), October 2009.

   [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.

   [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.


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 as a MIKEY
   message protected by a MAC based on a pre-shared Ticket Protection
   Key (TPK).  The parties that shares the TPK depends on the mode.

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





Mattsson & Tian          Expires August 3, 2010                [Page 47]


Internet-Draft                MIKEY-TICKET                  January 2010


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 definition see
   Appendix A.4.

   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 Sections A.2 and A.3).

   The KEMAC payload SHOULD use the NULL authentication algorithm, as a
   MAC is included in the V payload.  The encryption key (encr_key) and
   salting key SHALL be derived from the TPK (see Appendix A.2).  If CSB
   ID is needed in the IV formation it SHALL be set to 0xFFFFFFFF.  The
   KEMAC is hence constructed as follows:

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

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

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

   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) and the MAC field itself.

A.2.  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 (TP).  The parameters for the default
   PRF are given below.

   inkey:     : TPK
   inkey_len  : bit length of the inkey
   label      : constant || 0xFF || 0xFFFFFFFF || 0x00 ||
                length RAND || RAND
   outkey_len : desired bit length of the outkey

   Length RAND is the length of RAND in bytes as an 8-bit integer.  The
   constants are as defined in Section 4.1.4 of [RFC3830].  The key
   derivation and its dependencies on Ticket Data contents are



Mattsson & Tian          Expires August 3, 2010                [Page 48]


Internet-Draft                MIKEY-TICKET                  January 2010


   illustrated in Figure 10.  The illustrated 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
   salting key are used to encrypt the KEMAC.

            +-----+   TPK    -----           auth_key            -----
            | TPK |-------->| PRF |---------------------------->| MAC |
            +-----+         |     |----------------------+       -----
               ^             -----   encr_key, salt_key  |         |
               : identify      ^                         |         | MAC
               :               | RAND                    v         v
   Ticket  +---+----+-------+--+---+-----------------+-------+---+---+
    Data   | IDRpsk |.......| RAND |.................| KEMAC |...| V |
           +--------+-------+------+-----------------+-------+---+---+

                    Figure 10: Deriving keys from a TPK

A.3.  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 (TP).  The
   parameters for the default PRF are given below.

   inkey:     : MPK
   inkey_len  : bit length of the inkey
   label      : constant || 0xFF || 0xFFFFFFFF || 0x01 ||
                length RAND || RAND
   outkey_len : desired bit length of the outkey

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

                          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
   [RFC3830].

A.4.  Ticket Header Payload (THDR)

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




Mattsson & Tian          Expires August 3, 2010                [Page 49]


Internet-Draft                MIKEY-TICKET                  January 2010


    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
      bytes).

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


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
   credentials.

   +---+                          +-----+                          +---+
   | I |                          | KMS |                          | R |
   +---+                          +-----+                          +---+
               REQUEST_INIT
     -------------------------------->
               REQUEST_RESP
     <--------------------------------
                                3830 MIKEY
     ---------------------------------------------------------------->

                       Figure 11: Compatibility mode

B.2.  Distribution of Pre-Encrypted Content

   The default setting is that the KMS operates as a KDC (Key
   Distribution Center) and supplies keys.  This is not possible if the
   Initiator has pre-encrypted content (e.g.  Video on Demand).  In this
   case the KMS has to operate as a KTC (Key Translation Center) and re-



Mattsson & Tian          Expires August 3, 2010                [Page 50]


Internet-Draft                MIKEY-TICKET                  January 2010


   encode and forward the keys that the Initiator supplied.

   In such use cases, the exchange is typically reversed and MAY be
   carried out as follows.  The Responder sends a message (e.g.  SIP
   INVITE) to the Initiator requesting delivery of certain content.  The
   Initiator includes the TEKs used to protect the requested content in
   a REQUEST_INIT message, which is sent to the KMS.  The KMS encodes
   the TEKs in a ticket and replies with a REQUEST_RESP message
   containing the requested ticket, which is forwarded to the Responder
   in a TRANSFER_INIT message.

   +---+                          +-----+                          +---+
   | I |                          | KMS |                          | R |
   +---+                          +-----+                          +---+
                               Media request
     <----------------------------------------------------------------
           REQUEST_INIT {KEMAC}
     -------------------------------->
               REQUEST_RESP
     <--------------------------------
                               TRANSFER_INIT
     ---------------------------------------------------------------->

             Figure 12: Distribution of pre-encrypted content


Authors' Addresses

   John Mattsson
   Ericsson AB
   SE-164 80 Stockholm
   Sweden

   Phone: +46 10 71 43 501
   Email: john.mattsson@ericsson.com


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

   Phone: +86-025-5287-7867
   Email: tian.tian1@zte.com.cn






Mattsson & Tian          Expires August 3, 2010                [Page 51]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/