tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 6043

Informational
Pages: 58
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: ~sec-mikey

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

Part 1 of 3, p. 1 to 23
None       Next RFC Part

Updated by:    6309


Top       ToC       Page 1 
Internet Engineering Task Force (IETF)                       J. Mattsson
Request for Comments: 6043                                      Ericsson
Category: Informational                                          T. Tian
ISSN: 2070-1721                                                      ZTE
                                                              March 2011


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

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.  Interest in such deployments is increasing.
   Therefore, a set of new MIKEY modes that work well in such scenarios
   are defined.  The new modes use a trusted key management service and
   a ticket concept, similar to that in Kerberos.  The new modes also
   support features used by many existing applications, where the exact
   identity of the other endpoint may not be known at the start of the
   communication session.

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Not all documents
   approved by the IESG are a candidate for any level of Internet
   Standard; see Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc6043.

Page 2 
Copyright Notice

   Copyright (c) 2011 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 Simplified 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. 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 ....................................16
           4.2.3. Ticket Resolve .....................................19
   5. Key Management Functions .......................................23
      5.1. Key Derivation ............................................23
           5.1.1. Deriving Forked Keys ...............................25
           5.1.2. Deriving Keys from an Envelope Key/PSK/MPK .........26
           5.1.3. Deriving Keys from a TGK/GTGK ......................27
      5.2. CSB Updating ..............................................28
      5.3. Ticket Reuse ..............................................29
      5.4. Error Handling ............................................29
      5.5. MAC/Signature Coverage ....................................30
   6. Payload Encoding ...............................................31
      6.1. Common Header Payload (HDR) ...............................31
           6.1.1. The GENERIC-ID Map Type ............................33
      6.2. Key Data Transport Payload (KEMAC) ........................34
           6.2.1. Key Data Sub-Payload ...............................35
      6.3. Timestamp Payload (T) .....................................36
      6.4. Timestamp Payload with Role Indicator (TR) ................36
      6.5. ID Payload (ID) ...........................................37
      6.6. ID Payload with Role Indicator (IDR) ......................37

Top      ToC       Page 3 
      6.7. Cert Hash Payload (CHASH) .................................38
      6.8. RAND Payload with Role Indicator (RANDR) ..................38
      6.9. Error Payload (ERR) .......................................39
      6.10. Ticket Policy Payload (TP) / Ticket Payload (TICKET) .....39
   7. Transport Protocols ............................................43
   8. Pre-Encrypted Content ..........................................43
   9. Group Communication ............................................44
      9.1. Key Forking ...............................................45
   10. Signaling between Different KMSs ..............................45
   11. Adding New Ticket Types to MIKEY-TICKET .......................46
   12. Security Considerations .......................................47
      12.1. General ..................................................47
      12.2. Key Forking ..............................................48
      12.3. Denial of Service ........................................49
      12.4. Replay ...................................................49
      12.5. Group Key Management .....................................50
   13. Acknowledgements ..............................................50
   14. IANA Considerations ...........................................50
   15. References ....................................................53
      15.1. Normative References .....................................53
      15.2. Informative References ...................................53
   Appendix A.  MIKEY Base Ticket ....................................55
     A.1.  Components of the Ticket Data .............................55
     A.2.  Key Derivation ............................................56
       A.2.1.  Deriving Keys from a TPK ..............................56
       A.2.2.  Deriving MPKi and MPKr ................................57
     A.3.  Ticket Header Payload (THDR) ..............................57
   Appendix B.  Alternative Use Cases ................................58
     B.1.  Compatibility Mode ........................................58

Top      ToC       Page 4 
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.  The new modes support 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 to the Responder.  The ticket contains a reference
   to the keys, or the enveloped keys.  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 3rd Generation Partnership Project (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.

   This document 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 pseudorandom functions are
   defined.  And to eliminate the limitations with the existing SRTP-ID
   map type, a new CS ID map type called GENERIC-ID is 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].

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

2.1.  Definitions and Notation

   Forking: The delivery of a request to multiple endpoints (multiple
   devices owned by a single user or multiple users).

   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

Top      ToC       Page 6 
   ||        Concatenation
   |         OR (selection operator)

2.2.  Abbreviations

   3GPP:     3rd Generation Partnership Project
   AAA:      Authentication, Authorization, and Accounting
   ACL:      Access Control List
   AES:      Advanced Encryption Standard
   CA:       Certification Authority
   CS:       Crypto Session
   CSB:      Crypto Session Bundle
   IMS:      IP Multimedia Subsystem
   GTGK:     Group TGK
   HMAC:     Hash-based Message Authentication Code
   KMS:      Key Management Service
   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:      Pseudorandom Function
   PRNG:     Pseudorandom Number Generator
   PSK:      Pre-Shared Key
   RTSP:     Real Time Streaming Protocol
   SDP:      Session Description Protocol
   SHA:      Secure Hash Algorithm
   SIP:      Session Initiation Protocol
   SPI:      Security Parameters Index
   SRTP:     Secure Realtime Transport Protocol
   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:     Identifier for entity x
   IDRpsk:   Identifier for pre-shared key
   IDRapp:   Identifier for application/service
   KEMAC:    Key data transport payload

Top      ToC       Page 7 
   PKE:      Encrypted envelope key
   RAND:     RAND payload
   RANDRx:   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,
         Rekeying interval).

   The IDR, RANDR, 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 or not a response message is expected).

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 some situations, a request may be delivered to multiple endpoints.
   The endpoints may be multiple devices owned by a single user (e.g.,
   mobile phone, fixed phone, and computer), or multiple users (e.g.,
   IT-support@example.com, a group of users where only one is supposed
   to answer).  In the following, the term "forking" will be used to
   describe all such cases.  One example of delivery to multiple
   endpoints is forking and retargeting in SIP [RFC3261].  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.  SIP-signaled media protection is described in
   [RFC5479] and the applicability of different MIKEY modes is discussed
   in [RFC5197].

Top      ToC       Page 8 
   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 KMS 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 KMS and sends the
   ticket to the responder.  The responder forwards the ticket to the
   KMS, which returns the corresponding keys.

   It should be noted that Kerberos does not require that the responder
   also contact the KMS.  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
   mechanism specified in this document is useful for any system where
   the initial message may be transferred to arbitrarily many potential
   responders and where the set of responders may change at any time.
   In addition to being able to meet the requirements just described,
   the mechanism specified in this document also supports group key
   management.

   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

Top      ToC       Page 9 
   and use cases can be supported.  This has a number of advantages, as
   it offers a framework that is flexible enough to satisfy users with a
   broad range of security and functional needs.

   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 offline users.  Such scenarios exclude 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.

   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
   Certification Authority (CA).

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

Top      ToC       Page 10 
   +---+                          +-----+                          +---+
   | 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.  These pre-
   established trust relations are used to establish a security
   association between I and R.  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 10.

   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

Top      ToC       Page 11 
   message.  The Ticket Request exchange is OPTIONAL (depending on the
   Ticket Type), and MAY be omitted if the Initiator can create the
   ticket without assistance from the KMS (see mode 3 of Section 4.1.1).

   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 an MPK (MIKEY Protection Key) encoded in
   the ticket.  If the Responder finds the 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 (see mode 2 of Section 4.1.1).

   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 round-
   trip mode, but other modes are allowed, see Section 4.1.1.  Pre-
   encrypted content is discussed in Section 8, group communication is
   discussed in Section 9, and signaling between different KMSs is
   discussed in Section 10.  An alternative use case is discussed in
   Appendix B.

   The session keys are normally generated/supplied by the KMS (encoded
   in the ticket), but in certain use cases (see Section 8) the session
   key may be supplied by the Initiator or Responder (sent in a separate
   KEMAC protected with keys derived from the MPK).

   MIKEY-TICKET offers a framework that 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

Top      ToC       Page 12 
   depends on the Ticket Type signaled in the Ticket Policy.  The Ticket
   Data corresponding to the default Ticket Type, called MIKEY base
   ticket, is defined in Appendix A and requirements regarding new
   Ticket Types are given in Section 11.

   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
   encryption is only applied to the keys and not to the entire
   messages.

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

Top      ToC       Page 13 
   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 a mutual key-freshness guarantee.

   In modes 1 and 2, the Ticket Request exchange can be omitted if the
   tickets and the corresponding keys are distributed from the KMS to
   the Initiator in some other way.  In addition, as tickets may be
   reused (see Section 5.3), a single Ticket Request exchange may be
   followed by several Ticket Transfer exchanges.

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, RANDRi, [IDRi],
      [IDRkms], TP,                 <----  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, RANDRi, [IDRi],
      {CERTi}, [IDRkms], TP,        <----  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 using the pre-
   shared/envelope key indicated in the REQUEST_INIT message.

Top      ToC       Page 14 
   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.

4.2.1.1.  Common Components of the REQUEST_INIT Messages

   The REQUEST_INIT message MUST always include the Header (HDR),
   Timestamp (T), and RANDRi 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 (CSs) 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.

   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.

   The Ticket Policy payload (TP) contains the desired Ticket Policy.
   It includes for instance, the ticket's validity period, the number of
   requested keys, and the identities of authorized responders (see
   Section 6.10).

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 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
   shared by the Initiator and the KMS (see Section 5.1.2 for key
   derivation specification).  The MAC SHALL cover the entire
   REQUEST_INIT_PSK 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

Top      ToC       Page 15 
   separate CERT payload.  The Initiator's certificate MUST come first.
   Each following certificate MUST directly certify the one preceding
   it.

   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.

   SIGNi is a signature covering the entire REQUEST_INIT_PK 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 and the
   message can be correctly parsed, the KMS MUST check the Initiator's
   authorization.  If the Initiator is authorized to receive the
   requested ticket, possibly with a modified Ticket Policy, the KMS
   MUST send a REQUEST_RESP message.  Unexpected payloads in the
   REQUEST_INIT message SHOULD be ignored.  Errors are handled as
   described in Section 5.4.

4.2.1.5.  Components of the REQUEST_RESP Message

   The version, PRF func and CSB ID, #CS, and CS ID map type fields in
   the HDR payload SHALL be identical to the corresponding fields in the
   REQUEST_INIT message.  The V flag has no meaning in this context.  It
   SHALL be set to '0' by the KMS and ignored by the Initiator.

   If one of the NTP timestamp types is used, the KMS SHALL generate a
   fresh timestamp value (unlike [RFC3830]), which may be used for clock
   synchronization.  If the COUNTER timestamp type (see Section 6.6 of
   [RFC3830]) is used, the timestamp value MAY be equal to the one in
   the REQUEST_INIT message.

   The TICKET payload carries the granted Ticket Policy and the 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 SHALL 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).  Depending on
   the encryption algorithm, the salting key may go into the IV (see
   [RFC3830]).  If the TP payload in the REQUEST_INIT message does not

Top      ToC       Page 16 
   contain a KEMAC, it is RECOMMENDED that the KMS's default KEMAC
   include a single TGK.  The KEMAC SHALL include an 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] || {TEK|TGK|GTGK})

   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 REQUEST_RESP message as well as the REQUEST_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 SHALL be stored.  Unexpected payloads in the
   REQUEST_RESP message SHOULD be ignored.  Errors are handled as
   described in Section 5.4.

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

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], but instead of a
   pre-shared key, an MPK encoded in the ticket is used.  The session
   keys are also encoded in the TICKET payload, but in some use cases
   (see Section 8) they need to be sent in a separate KEMAC payload.
   The session information may be sent from the Initiator to the
   Responder (similar to [RFC3830]) or from the Responder to the
   Initiator (similar to [RFC4738]).  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.

Top      ToC       Page 17 
   Initiator                               Responder

   TRANSFER_INIT =                 ---->
   HDR, T, RANDRi, [IDRi],
      [IDRr], {SP}, TICKET,         < - -  TRANSFER_RESP =
      [KEMAC], V                           HDR, T, [RANDRr],
                                              [IDRr], [RANDRkms],
                                              {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 RANDRi 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 F flag in
   the Ticket Policy and it SHALL be ignored by the Responder.

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

   Multiple SP payloads MAY be used both to indicate supported security
   policies for a specific crypto session (similar to [RFC4738]) and to
   specify security policies for different crypto sessions (similar to
   [RFC3830]).

   The ticket payload (see Section 6.10) contains the Ticket Policy (see
   Section 6.10), Ticket Data (the default ticket type is defined in
   Appendix A), and Initiator 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 Type provided in the Ticket Data is indicated in the Ticket
   Policy.  The Initiator Data authenticates the Initiator when key
   forking (I flag) is used.

   The KEMAC payload is handled in the same way as if it were sent in a
   later CSB update (see Section 5.2), with the only difference that the
   encr_key is always derived from MPKi and therefore accessible by all
   responders authorized to resolve the ticket.  Initiator-specified
   keys MAY be used if the Initiator has pre-encrypted content and
   specific TEKs (Traffic Encryption Keys) need to be used (see
   Section 8).  If indicated by the Ticket Policy (L flag), a KEMAC
   payload SHALL NOT be included.

Top      ToC       Page 18 
   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 TRANSFER_INIT message as well as the identities of the
   involved parties (see Section 5.5 for the exact definition).

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 SHALL however check that both the
   Ticket Policy and the security policies are acceptable.  If they are
   not, the Responder SHALL 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.  Unexpected payloads
   in the TRANSFER_INIT message SHOULD be ignored.  Errors are handled
   as described in Section 5.4.  If the F flag in the Ticket Policy is
   set, the Responder MUST send a TRANSFER_RESP message.

4.2.2.3.  Components of the TRANSFER_RESP Message

   The version, PRF func and CSB ID fields in the HDR payload SHALL be
   identical to the corresponding fields in the TRANSFER_INIT message.
   The V flag has no meaning in this context.  It SHALL be set to '0' by
   the Responder and ignored by the Initiator.  The Responder SHALL
   update the CS ID map info so that each crypto session has exactly one
   security policy indicated.  The Responder MUST provide Session Data
   (at least for SRTP) and SPI for each crypto session for which the
   Initiator has not supplied Session Data and SPI.  If needed, the
   Responder MAY update Session Data and SPI provided by the Initiator.
   If the Responder adds crypto sessions, the #CS SHALL be updated.

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

   If indicated by the Ticket Policy (G flag), the Responder SHALL
   generate a fresh (pseudo-)random byte string RANDRr.  RANDRr 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

Top      ToC       Page 19 
   TRANSFER_RESP message (e.g., user1@example.com) MAY differ from the
   one sent in the IDRr payload in the TRANSFER_INIT message (e.g.,
   IT-support@example.com).

   If the Responder receives a RANDRkms payload in the RESOLVE_RESP
   message, the same RAND MUST be sent in a RANDRkms payload in the
   TRANSFER_RESP message.

   The Responder MAY provide additional Security Policy payloads.  The
   Responder SHOULD NOT resend SP payloads, which the Initiator
   supplied.

   The KEMAC payload SHALL be handled exactly as if it was sent in a
   later CSB update, see Section 5.2.  Responder-specified keys MAY be
   used if Responder has pre-encrypted content and specific TEKs
   (Traffic Encryption Keys) need to be used (see Section 8).  If
   indicated by the Ticket Policy (M flag), a KEMAC payload SHALL NOT be
   included.

   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 TRANSFER_RESP message as well as the TRANSFER_INIT message
   (see Section 5.5 for the exact definition).

4.2.2.4.  Processing the TRANSFER_RESP Message

   If the Initiator can verify the integrity of the received message and
   the message can be correctly parsed, the Initiator MUST check that
   any Responder-generated security policies are acceptable.  If not,
   the Initiator SHALL discard and MAY send a new TRANSFER_INIT message
   to indicate supported security policies.  Unexpected payloads in the
   TRANSFER_RESP message SHOULD be ignored.  Errors are handled as
   described in Section 5.4.

4.2.3.  Ticket Resolve

   This exchange is used by the Responder to request that the KMS return
   the keys encoded in a ticket.  The KMS does not need to be the same
   KMS that originally issued the ticket, see Section 10.  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].

Top      ToC       Page 20 
   Responder                               KMS

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

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

   Responder                               KMS

   RESOLVE_INIT_PK =               ---->
   HDR, T, RANDRr, [IDRr],
      {CERTr}, [IDRkms], TICKET,    <----  RESOLVE_RESP
      [CHASH], PKE, SIGNr                  HDR, T, [IDRkms], KEMAC,
                                              [IDRr], [RANDRkms], 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
   ticket, the Responder is assured of the integrity of the Ticket
   Policy, which contains the identity of the peer that requested or
   created the ticket.  If key forking is used (I flag), the Responder
   is also assured that the peer that requested or created the ticket
   also sent the TRANSFER_INIT message.  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 RANDRr 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].

Top      ToC       Page 21 
   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
   shared by the Responder and the KMS.  The MAC SHALL cover the entire
   RESOLVE_INIT_PSK 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.  The Responder's certificate MUST come first.
   Each following certificate MUST directly certify the one preceding
   it.

   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.

   SIGNr is a signature covering the entire RESOLVE_INIT_PK 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, the
   message can be correctly parsed, and the Responder is authorized to
   resolve the ticket, the KMS MUST send a RESOLVE_RESP message.  If key
   forking is used (I flag), the KMS SHALL also verify the integrity of
   the Initiator Data field in the TICKET payload.  Unexpected payloads
   in the RESOLVE_INIT message SHOULD be ignored.  Errors are handled as
   described in Section 5.4.

Top      ToC       Page 22 
4.2.3.5.  Components of the RESOLVE_RESP Message

   The version, PRF func and CSB ID, #CS, and CS ID map type fields in
   the HDR payload SHALL be identical to the corresponding fields in the
   RESOLVE_INIT message.  The V flag has no meaning in this context.  It
   SHALL be set to '0' by the KMS and ignored by the Responder.

   If one of the NTP timestamp types is used, the KMS SHALL generate a
   fresh timestamp value (unlike [RFC3830]), which may be used for clock
   synchronization.  If the COUNTER timestamp type (see Section 6.6 of
   [RFC3830]) is used, the timestamp value MAY be equal to the one in
   the RESOLVE_INIT message.

   The KEMAC payload SHALL 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).  Depending on
   the encryption algorithm, the salting key may go into the IV (see
   [RFC3830]).  The KEMAC SHALL include an 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'] || {TEK|TGK|GTGK})

   If key forking (see Section 5.1.1) is used (determined by the I flag
   in 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 RANDRkms
   payloads, where IDRr is the identity of the endpoint that answered
   and RANDRkms 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 RESOLVE_RESP message as well as the RESOLVE_INIT
   message (see Section 5.5 for the exact definition).

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 MUST verify the
   TRANSFER_INIT message with the MPKi received from the KMS.  If key
   forking is used, the Responder SHALL also verify that the MAC field
   in the V payload in the TRANSFER_INIT message is identical to the MAC

Top      ToC       Page 23 
   field in the Vi payload in the Initiator Data field in the TICKET
   payload.  Unexpected payloads in the RESOLVE_RESP message SHOULD be
   ignored.  Errors are handled as described in Section 5.4.



(page 23 continued on part 2)

Next RFC Part