Network Working Group J. Mattsson Internet-Draft Ericsson Updates: 3830 (if approved) T. Tian Intended status: Standards Track ZTE Expires: April 22, 2010 October 19, 2009 MIKEY-TICKET: An Additional Mode of Key Distribution in Multimedia Internet KEYing (MIKEY) draft-mattsson-mikey-ticket-00 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 April 22, 2010. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract The Multimedia Internet KEYing (MIKEY) specification describes a key Mattsson & Tian Expires April 22, 2010 [Page 1] Internet-Draft MIKEY-TICKET October 2009 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 initiation of the communication session. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Definitions and Notation . . . . . . . . . . . . . . . . . 5 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5 2.3. Payloads . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Design Considerations . . . . . . . . . . . . . . . . . . . . 7 4. A New Mode: MIKEY-TICKET . . . . . . . . . . . . . . . . . . . 9 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1.1. Modes . . . . . . . . . . . . . . . . . . . . . . . . 11 4.2. Exchanges . . . . . . . . . . . . . . . . . . . . . . . . 12 4.2.1. Ticket Request . . . . . . . . . . . . . . . . . . . . 12 4.2.2. Ticket Transfer . . . . . . . . . . . . . . . . . . . 15 4.2.3. Ticket Resolve . . . . . . . . . . . . . . . . . . . . 17 5. Selected Key Management Functions . . . . . . . . . . . . . . 20 5.1. Key Derivation . . . . . . . . . . . . . . . . . . . . . . 20 5.1.1. Deriving Forking Keys . . . . . . . . . . . . . . . . 21 5.1.2. Deriving Keys from a TGK . . . . . . . . . . . . . . . 23 5.1.3. Deriving Keys from a MPK . . . . . . . . . . . . . . . 24 5.2. CSB Updating . . . . . . . . . . . . . . . . . . . . . . . 24 5.3. Ticket Reuse . . . . . . . . . . . . . . . . . . . . . . . 25 5.4. MAC/Signature Coverage . . . . . . . . . . . . . . . . . . 26 6. Payload Encoding . . . . . . . . . . . . . . . . . . . . . . . 26 6.1. Common Header Payload (HDR) . . . . . . . . . . . . . . . 26 6.2. Key Data Transport Payload (KEMAC) . . . . . . . . . . . . 28 6.3. Timestamp Payload (T) . . . . . . . . . . . . . . . . . . 28 6.4. Timestamp Payload with Role Indicator (TR) . . . . . . . . 28 6.5. ID Payload (ID) . . . . . . . . . . . . . . . . . . . . . 29 6.6. ID Payload with Role Indicator (IDR) . . . . . . . . . . . 29 6.7. Error Payload (ERR) . . . . . . . . . . . . . . . . . . . 30 6.8. Key Data Sub-Payload . . . . . . . . . . . . . . . . . . . 30 6.9. Ticket Payload (TICKET) . . . . . . . . . . . . . . . . . 31 6.10. Ticket Policy Payload (TP) . . . . . . . . . . . . . . . . 31 7. Transport Protocols . . . . . . . . . . . . . . . . . . . . . 34 8. Group Communication . . . . . . . . . . . . . . . . . . . . . 34 Mattsson & Tian Expires April 22, 2010 [Page 2] Internet-Draft MIKEY-TICKET October 2009 8.1. Key Forking . . . . . . . . . . . . . . . . . . . . . . . 34 9. Signaling Between Different KMSs . . . . . . . . . . . . . . . 35 10. Adding New Ticket Types to MIKEY-TICKET . . . . . . . . . . . 36 11. Security Considerations . . . . . . . . . . . . . . . . . . . 37 11.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 37 11.2. Denial of Service . . . . . . . . . . . . . . . . . . . . 38 11.3. Replay . . . . . . . . . . . . . . . . . . . . . . . . . . 39 11.4. Forking . . . . . . . . . . . . . . . . . . . . . . . . . 39 11.5. Group Key Management . . . . . . . . . . . . . . . . . . . 40 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 40 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42 14.1. Normative References . . . . . . . . . . . . . . . . . . . 42 14.2. Informative References . . . . . . . . . . . . . . . . . . 43 Appendix A. MIKEY Base Ticket . . . . . . . . . . . . . . . . . . 43 A.1. Components of the MIKEY Base Ticket . . . . . . . . . . . 43 A.2. Deriving Keys from a TPK . . . . . . . . . . . . . . . . . 44 A.3. Deriving MPKi and MPKr . . . . . . . . . . . . . . . . . . 45 A.4. Ticket Header Payload (THDR) . . . . . . . . . . . . . . . 45 Appendix B. Alternative Use Cases . . . . . . . . . . . . . . . . 46 B.1. Compatibility Mode . . . . . . . . . . . . . . . . . . . . 46 B.2. Distribution of Pre-Encrypted Content . . . . . . . . . . 46 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47 Mattsson & Tian Expires April 22, 2010 [Page 3] Internet-Draft MIKEY-TICKET October 2009 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 updates [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 fulfill the requirements for media plane security in the 3GPP IP Multimedia Subsystem (IMS). 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; forking 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. 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]. Definitions of terms and notation will, unless otherwise stated, be as defined in [RFC3830]. Mattsson & Tian Expires April 22, 2010 [Page 4] Internet-Draft MIKEY-TICKET October 2009 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 to 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 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, allowed 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 [p] p is optional {p} Zero or more occurrences of p (p) One or more occurrences of p || Concatenation | OR (selection operator) 2.2. Abbreviations 3GPP: 3rd Generation Partnership Project AAA: Authentication, Authorization, and Accounting Mattsson & Tian Expires April 22, 2010 [Page 5] Internet-Draft MIKEY-TICKET October 2009 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 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 Mattsson & Tian Expires April 22, 2010 [Page 6] Internet-Draft MIKEY-TICKET October 2009 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} (time of Issue, Start time, End time, Reykeying interval). The IDR, TR, TICKET, and TP payloads are defined in Section 6. 3. Design Considerations As mentioned in the introduction, none of the previously defined MIKEY modes are based on a trusted 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 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]. 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 Mattsson & Tian Expires April 22, 2010 [Page 7] Internet-Draft MIKEY-TICKET October 2009 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 key(s) 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. 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 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 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 Mattsson & Tian Expires April 22, 2010 [Page 8] Internet-Draft MIKEY-TICKET October 2009 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) roundtrip between two peers. MIKEY-TICKET differs from these modes as it consists of up to three different roundtrips (Ticket Request, Ticket Transfer, and Ticket Resolve) involving three parties (Initiator, Responder, and KMS). Since the number of roundtrips 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 roundtrip MIKEY-TICKET mode is depicted. +---+ +-----+ +---+ | I | | KMS | | R | +---+ +-----+ +---+ REQUEST_INIT --------------------------------> REQUEST_RESP <-------------------------------- TRANSFER_INIT ----------------------------------------------------------------> RESOLVE_INIT <-------------------------------- RESOLVE_RESP --------------------------------> TRANSFER_RESP <---------------------------------------------------------------- Figure 1: Full three roundtrip 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. 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) Mattsson & Tian Expires April 22, 2010 [Page 9] Internet-Draft MIKEY-TICKET October 2009 from the KMS by sending a REQUEST_INIT message. The REQUEST_INIT message includes session information (e.g. identities of the allowed responders) and is protected via a MAC based on a pre-shared key or via 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 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 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 via 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 via a MAC based on a pre-shared key (between Responder and KMS) or via 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, who sends a TRANSFER_RESP message to the Initiator as verification. The TRANSFER_RESP message might include information used for 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 KMS Domains 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 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 Mattsson & Tian Expires April 22, 2010 [Page 10] Internet-Draft MIKEY-TICKET October 2009 combination of the two alternatives. The format of the ticket data depends on the ticket type signaled in the ticket policy. A 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 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. 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 2. 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 2: Modes If the key protecting the ticket is shared between the Initiator and Mattsson & Tian Expires April 22, 2010 [Page 11] Internet-Draft MIKEY-TICKET October 2009 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. In mode 1 and 2 the Ticket Request can be omitted if the tickets 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 roundtrip is required for the Initiator to receive the ticket. The initiation message REQUEST_INIT comes in two variants corresponding to the pre-shared key (PSK) and public-key (PK) methods of [RFC3830]. As this message MUST ensure the identity of the Initiator to the KMS, it SHALL be integrity protected via a MAC based on a pre-shared key or via 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. Initiator KMS REQUEST_INIT_PSK = ----> HDR, T, RANDi, [IDRi], [IDRkms], TP, [KEMAC], <---- REQUEST_RESP = [IDRpsk], V HDR, T, [IDRkms], TICKET, KEMAC, V REQUEST_INIT_PK = ----> HDR, T, RANDi, [IDRi], {CERTi}, [IDRkms], TP, [KEMAC], <---- REQUEST_RESP = [CHASH], PKE, SIGNi HDR, T, [IDRkms], TICKET, KEMAC, V 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.9. Mattsson & Tian Expires April 22, 2010 [Page 12] Internet-Draft MIKEY-TICKET October 2009 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. The CSB ID (Crypto Session Bundle ID) SHALL be assigned as in [RFC3830]. The V flag (in the HDR payload) 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 stored 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.10). It includes for instance, the identities of allowed 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 salt key used to encrypt the KEMAC SHALL be derived from the pre- shared key (Initiator-KMS) (see Section 4.1.4 of [RFC3830] for key derivation specification). 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 (Initiator-KMS) (see Section 4.1.4 of [RFC3830] for key derivation Mattsson & Tian Expires April 22, 2010 [Page 13] Internet-Draft MIKEY-TICKET October 2009 specification). The MAC SHALL cover the entire message as well as the identities of the involved parties (see Section 5.4 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 allowed responder. The encr_key, salt_key, and auth_key SHALL be derived from the envelope key (see Section 4.1.4 of [RFC3830] for key derivation specification). 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.4 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 set to 0 by the KMS and ignored by the Initiator. Mattsson & Tian Expires April 22, 2010 [Page 14] Internet-Draft MIKEY-TICKET October 2009 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.9). 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. 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 MIKEY Protection Key (MPK) 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) two MPKs SHALL be included in the KEMAC. The first MPK (MPKi) SHALL be used to protect the TRANSFER_INIT message and the second MPK (MPKr) SHALL be used to verify the TRANSFER_RESP message. The KEMAC is hence constructed as follows: KEMAC = E(encr_key, MPK || [MPK] || {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 identities of the involved parties (see Section 5.4 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. 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 Mattsson & Tian Expires April 22, 2010 [Page 15] Internet-Draft MIKEY-TICKET October 2009 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 roundtrip 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). Initiator Responder TRANSFER_INIT = ----> HDR, T, RANDi, [IDRi], [IDRr], {SP}, TICKET, V < - - TRANSFER_RESP = HDR, T, [RANDr], [IDRr], [RANDkms], 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. 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 MPK (see Section 5.1.3 for key derivation specification). The MAC SHALL cover the entire message as well as the identities of the involved parties (see Section 5.4 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 SHOULD however check that both the ticket policy and the security policy (SP) are acceptable. If they are not, the Responder SHOULD reject without contacting the KMS. Mattsson & Tian Expires April 22, 2010 [Page 16] Internet-Draft MIKEY-TICKET October 2009 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 new (pseudo-)random byte string RANDr. RANDr is used to produce Responder freshness guarantee for the key derivation. If the Responder received 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 received 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 last payload SHALL be a Verification payload (V) where the authentication key (auth_key) is derived from the MPK. The MAC SHALL cover the entire message as well as the identities of the involved parties (see Section 5.4 for the exact definition). 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 Mattsson & Tian Expires April 22, 2010 [Page 17] Internet-Draft MIKEY-TICKET October 2009 roundtrip 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 initiation message RESOLVE_INIT comes in two variants corresponding to the pre-shared key (PSK) and public-key encryption (PK) methods of [RFC3830]. As this message MUST ensure the identity of the Responder to the KMS, it SHALL be protected via a MAC based on a pre-shared key or via 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. Responder KMS RESOLVE_INIT_PSK = ----> HDR, T, RANDr, [IDRr], [IDRkms], TICKET, <---- RESOLVE_RESP [IDRpsk], V HDR, T, [IDRkms], KEMAC, [IDRr], [RANDkms], V RESOLVE_INIT_PK = ----> HDR, T, RANDr, [IDRr], {CERTr}, [IDRkms], TICKET, <---- RESOLVE_RESP [CHASH], PKE, SIGNr HDR, T, [IDRkms], KEMAC, [IDRr], [RANDkms], V Upon receiving the RESOLVE_INIT message, the KMS verifies that the Responder is allowed to resolve the ticket. 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 (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. Mattsson & Tian Expires April 22, 2010 [Page 18] Internet-Draft MIKEY-TICKET October 2009 The TICKET payload contains the ticket 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.4 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. SIGNr is a signature covering the entire MIKEY message, using the Responder's signature key (see Section 5.4 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 Mattsson & Tian Expires April 22, 2010 [Page 19] Internet-Draft MIKEY-TICKET October 2009 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 KEMAC is hence constructed as follows: KEMAC = E(encr_key, MPK || [MPK] || {TGK|TEK}) If key forking (see Section 5.1.1) is used (determined by the ticket policy) two MPKs SHALL be included in the KEMAC. The first MPK (MPKi) SHALL be used by the Responder to verify the TRANSFER_INIT message and the second MPK (MPKr) SHALL be used by the Responder 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 new (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 identities of the involved parties (see Section 5.4 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 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. Selected 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 specified in [RFC3830]. As crypto sessions SHALL NOT be handled, further keying material (i.e. TEKs) Mattsson & Tian Expires April 22, 2010 [Page 20] Internet-Draft MIKEY-TICKET October 2009 SHALL NOT be derived. In the Ticket Transfer exchange, key forking MAY be used, in which case two different MPKs (MPKi and MPKr) are used to protect the TRANSFER_INIT and TRANSFER_RESP messages respectively. The KMS and the Initiator SHALL also fork the MPKr and the TGKs based on a modifier. In addition, the Responder MAY generate a RAND used to give Responder key freshness guarantee. In either case, different keys are used to protect the TRANSFER_INIT and TRANSFER_RESP messages. 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 3. The KEMAC is encoded in the TICKET payload. The illustrated key derivations are done by the Initiator and the Responder. +-----+-------------------+-----+------+ KEMAC | MPK |...................| TGK | SALT | +--+--+-------------------+--+--+--+---+ | | | v | | csb_id ----- auth_key | | +---------->| PRF |-----------------+ | | | cs_id ----- | | | | ^ | | | | | v | | +--+--+-------+---+---+--+--------+--+---+ | | TRANSFER_INIT | HDR |.......| RANDi |..| TICKET |..| V | | | +--+--+-------+---+---+--+--------+--+---+ | | | | | | | v | | | csb_id ----- | | +---------->| PRF |<---------------------+ | cs_id ----- | | | Security Protocol v TEK SALT v Figure 3: Key hierarchy without key forking and with a single RAND 5.1.1. Deriving Forking 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: Mattsson & Tian Expires April 22, 2010 [Page 21] Internet-Draft MIKEY-TICKET October 2009 inkey: : MPKr or TGK inkey_len : bit length of the inkey label : constant || 0xFE || 0xFFFFFFFF || ID Data || RANDkms outkey_len : desired bit length of the outkey where ID Data is taken from the IDRr payload sent in the RESOLVE_RESP and TRANSFER_RESP messages. The constant depends on the derived key type as summarized below. Derived key | Constant ------------+----------- Forked MPKr | 0x2B288856 Forked TGK | 0x1512B54A Table 5.1: Constants for forking key derivation The constants are taken from the decimal digits of e as described in [RFC3830]. The key hierarchy and its dependencies on TRANSFER_RESP message contents for the case with key forking and two RANDs are illustrated in Figure 4. The KEMAC is encoded in the TICKET payload (not shown). MOD is the modifier (IDRr, RANDkms). The two key derivations that produce forked keys are done by the Initiator and the KMS and the the remaining two key derivations are done by the Initiator and the Responder. The 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 3 with the exception that MPKi is used. Mattsson & Tian Expires April 22, 2010 [Page 22] Internet-Draft MIKEY-TICKET October 2009 +------+---------------------------+-----+------+ KEMAC | MPKr |...........................| TGK | SALT | +--+---+---------------------------+--+--+--+---+ | | | v | | ----- forked MPK | | | PRF |------------+ | | ----- | | | ^ v | | | csb_id ----- auth_key | | +--------)----------->| PRF |----------+ | | | | cs_id ----- | | | | | ^ | | | | | | v | | +--+--+--+--+--+--------+---+---+-------+---+ | | TRANSFER_RESP | HDR |..| MOD |........| RANDr |.......| V | | | +--+--+--+--+--+--------+---+---+-------+---+ | | | | ----- | | | | +---->| PRF |<--)------------------+ | | ----- | | | forked TGK | | | | v | | | csb_id ----- | | +------------->| PRF |<--+ | cs_id ----- | | | Security Protocol v TEK SALT v Figure 4: Key hierarchy with key forking and two RANDs 5.1.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 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: : (Forked) TGK inkey_len : bit length of the inkey label : constant || cs_id || csb_id || RANDi || [RANDr] outkey_len : bit length of the outkey where the constants are as defined in Section 4.1.3. of [RFC3830]. RANDr SHALL be included if it is present in the TRANSFER_RESP message. Note that the ticket may carry a salt. A security protocol in need Mattsson & Tian Expires April 22, 2010 [Page 23] Internet-Draft MIKEY-TICKET October 2009 of a salt key SHALL use the salt key carried in the ticket when present. If a salt is not included, it is possible to derive a salt key via the key derivation function. 5.1.2.1. Deriving Keys from a GTGK The same key derivation as in Section 5.1.2 SHALL be done, with the exceptions that the GTGK SHALL NOT be forked and the label SHALL NOT include RANDr. 5.1.3. Deriving Keys from a MPK This derivation is to form the keys used to protect the MIKEY messages in the Ticket Transfer exchange, the TRANSFER_INIT message SHALL be protected with the following keys derived from a MPK. If key forking is used, different MPKs (MPKi and a forked MPKr) SHALL be used to protect the TRANSFER_INIT and TRANSFER_RESP messages. Parameters for the default PRF are given below. inkey: : MPK or MPKi inkey_len : bit length of the inkey label : constant || 0xFF || csb_id || RANDi outkey_len : desired bit length of the output key where the constants are as defined in [RFC3830]. The parameters for the TRANSFER_RESP message are given below. inkey: : MPK or Forked MPKr inkey_len : bit length of the inkey label : constant || 0xFF || csb_id || RANDi || [RANDr] outkey_len : desired bit length of the output key RANDr SHALL be included if it is present in the TRANSFER_RESP message. 5.2. 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 new crypto session is needed. The CSB updating MAY be started by either the Initiator or the Responder. Mattsson & Tian Expires April 22, 2010 [Page 24] Internet-Draft MIKEY-TICKET October 2009 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. Unless a new MPK has been exchanged, both messages SHALL be protected with the keys that protected the TRANSFER_RESP message in the initial exchange. If a new MPK has been exchanged in a previous CSB updating, both messages SHALL be protected with keys derived from this MPK without forking key derivation. The KEMAC is hence constructed as follows: KEMAC = E(encr_key, [MPK] || {TGK|TEK}) 5.3. Ticket Reuse 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 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 Mattsson & Tian Expires April 22, 2010 [Page 25] Internet-Draft MIKEY-TICKET October 2009 communication.) Thus, if group dynamics are difficult to verify, the Initiator SHOULD NOT initiate ticket reuse. When key forking is used, only the user that requested the ticket has access to the encoded master keys (MPKr, TGKs). Because of this, no one else can initiate a Ticket Transfer exchange using the ticket. 5.4. MAC/Signature Coverage The MAC/Signature in the V/SIGN payloads covers the entire MIKEY message, except the MAC/Signature field itself. The identities (not whole payloads) of the involved parties 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). Exchange | MAC/Signature coverage ----------------+-------------------------------------------- Ticket Request | MIKEY message || Identity_i || Identity_kms Ticket Transfer | MIKEY message || Identity_i || Identity_r Ticket Resolve | MIKEY message || Identity_r || Identity_kms 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]. 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. Mattsson & Tian Expires April 22, 2010 [Page 26] Internet-Draft MIKEY-TICKET October 2009 Data Type | Value | Comment -----------------+-------+---------------------------------------- REQUEST_INIT_PSK | TBD1 | Ticket request initiation message (PSK) REQUEST_INIT_PK | TBD2 | Ticket request initiation message (PK) REQUEST_RESP | TBD3 | Ticket request response message | | TRANSFER_INIT | TBD4 | Ticket transfer initiation message TRANSFER_RESP | TBD5 | Ticket transfer response message | | RESOLVE_INIT_PSK | TBD6 | Ticket resolve initiation message (PSK) RESOLVE_INIT_PK | TBD7 | Ticket resolve initiation 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.9 TP | TBD12 | 6.10 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. * #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. Mattsson & Tian Expires April 22, 2010 [Page 27] Internet-Draft MIKEY-TICKET October 2009 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.10). Such keys SHALL be placed last, after all keys with Key Data supplied by the KMS. In the REQUEST_INIT message the KEMAC is used by the Initiator 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. 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 [RFC2030]. 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. [RFC2030] 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 | TDB13 | 32-bits Table 6.3: 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 April 22, 2010 [Page 28] Internet-Draft MIKEY-TICKET October 2009 Value, the TS Role describes the meaning of the timestamp itself. The TR payload are intended to eliminate ambiguity when a MIKEY message contain 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.4: TS Role 6.5. ID Payload (ID) For the ID payload, a new ID type 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 | TDB14 Table 6.5: 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 are intended to eliminate ambiguity when a MIKEY message contain several identity payloads. The IDR payload MUST be used instead of the ID payload in all MIKEY-TICKET messages. Mattsson & Tian Expires April 22, 2010 [Page 29] Internet-Draft MIKEY-TICKET October 2009 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.6: ID Role 6.7. Error Payload (ERR) For the key data sub-payload, new types of errors are defined. * Error no (8 bits): indicates the type of error that was encountered. Error no | Value | Comments ------------------+-------+---------------------------- Invalid TICKET | TBD15 | Ticket type not supported Invalid TPpar | TBD16 | TP parameters not supported Table 6.7: Error no (Additions) 6.8. 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. Mattsson & Tian Expires April 22, 2010 [Page 30] Internet-Draft MIKEY-TICKET October 2009 * Type (4 bits): indicates the type of key included in the payload. Type | Value | Comments ----------+-------+--------------------- GTGK | TBD17 | Group TGK GTGK+SALT | TBD18 | Group TGK + SALT MPK | TBD19 | MIKEY Protection Key Table 6.8: Key Data Type (Additions) 6.9. Ticket Payload (TICKET) The ticket payload contains a TP payload (see Section 6.10 ) 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 subpayload 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 ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * 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.10. 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. Mattsson & Tian Expires April 22, 2010 [Page 31] Internet-Draft MIKEY-TICKET October 2009 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.9: 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. * 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'). Mattsson & Tian Expires April 22, 2010 [Page 32] Internet-Draft MIKEY-TICKET October 2009 * 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'). * 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'). * 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) 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. AS the NTP timescale wraps around every 136 years, TRs SHALL be interpreted as the matching time closest to the current time. An omitted TRs means that the validity period has no bound in that direction. TRe is the end of the validity period. TRe SHALL be interpreted to be the first matching time that occur after TRs. If TRs is omitted TRe SHALL be interpreted as the matching time closest to the current time. This gives a maximum (finite) validity time of 136 years. An omitted TRe means that the validity period has no bound in that direction. IDRapp is an identifier for the allowed application. IDRr is the identity of a responder or a group of responders that should be allowed to resolve the ticket. If there is more than one responder identity, each responder identity SHALL be included in a separate IDR payload. Mattsson & Tian Expires April 22, 2010 [Page 33] Internet-Draft MIKEY-TICKET October 2009 7. Transport Protocols As the Ticket Transfer exchange terminates in at most one full roundtrip, 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 (C) or decentralized (D) as illustrated in Figure 5. In the decentralized scenario, B's and C's identities SHALL be used in the second Ticket Transfer exchange. +---+ +---+ +---+ | A | | B | | C | +---+ +---+ +---+ Ticket Transfer (C) <----------------------------> Ticket Transfer <---------------------------------------------------------> Ticket Transfer (D) <----------------------------> Ticket Transfer <----------------------------> Figure 5: Centralized and decentralized signaling 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.3. 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.3. Mattsson & Tian Expires April 22, 2010 [Page 34] Internet-Draft MIKEY-TICKET October 2009 +---+ +---+ +---+ | A | | B | | C | +---+ +---+ +---+ Ticket Transfer <----------------------------> Ticket Transfer <---------------------------------------------------------> Rekeying -----------------------------> Rekeying ----------------------------------------------------------> Figure 6: Multi-party rekeying Another consideration is that different users get different TEKs if TGKs (not GTGKs) are used, so if the audio mixing is decentralized, a new (non-forked) group key MUST be distributed before the session starts, see Figure 6. The rekeying does not need to be done with a CSB Updating exchange (see Section 5.2); 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 audio 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 and protected with different 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. Under these assumptions, the following approach MAY be used. Mattsson & Tian Expires April 22, 2010 [Page 35] Internet-Draft MIKEY-TICKET October 2009 +---+ +---+ +-------+ +-------+ | I | | R | | KMS R | | KMS I | +---+ +---+ +-------+ +-------+ TRANSFER_INIT --------------------> RESOLVE_INIT - - - - - - - - - - -> RESOLVE_INIT - - - - - - - - - - -> RESOLVE_RESP RESOLVE_RESP <- - - - - - - - - - - TRANSFER_RESP < - - - - - - - - - - <-------------------- Figure 7: 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 a RESOLVE_INIT message to the Responder's own 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 the issuing KMS). The signaling between different KMSs MAY be done with a Ticket Resolve exchange as illustrated in Figure 7. The IDRr and TICKET payloads from the previous RESOLVE_INIT message SHOULD be reused. 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. Other types of information may also require confidentiality protection due to privacy reasons. It may be preferable to include several encrypted Mattsson & Tian Expires April 22, 2010 [Page 36] Internet-Draft MIKEY-TICKET October 2009 ticket protection keys (similar to S/MIME) as this allows multiple peers to resolve the ticket. The ticket data MUST include information so that the resolving party can retrieve the encoded KEMAC. It MUST also be possible to verify the integrity of the TP 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 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 (allowed 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 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, e.g. 128 bits or more. Mattsson & Tian Expires April 22, 2010 [Page 37] Internet-Draft MIKEY-TICKET October 2009 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) 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 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 Mattsson & Tian Expires April 22, 2010 [Page 38] Internet-Draft MIKEY-TICKET October 2009 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 included in the MAC/Signature calculation. An attacker may also attempt to replay a ticket by inserting it into a new MIKEY message. A possible scenario is that Alice and Bob first communicate based on a ticket, which an attacker Mallory intercepts. Later, Mallory (acting as herself) invites Bob by inserting the ticket into her own TRANSFER_INIT message. 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, no one else can derive the session keys. Mattsson & Tian Expires April 22, 2010 [Page 39] Internet-Draft MIKEY-TICKET October 2009 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. 12. Acknowledgements The authors would like to thank Fredrik Ahlqvist, Rolf Blom, Yi Cheng, Lakshminath Dondeti, Vesa Lehtovirta, Fredrik Lindholm, Mats Naslund, Karl Norrman, 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, TS Type, ID Type, 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 TS Type (see Table 6.3) o ID Type (see Table 6.5) o Error no (see Table 6.7) o Key Data Type (see Table 6.8) 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. Mattsson & Tian Expires April 22, 2010 [Page 40] Internet-Draft MIKEY-TICKET October 2009 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: 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: Mattsson & Tian Expires April 22, 2010 [Page 41] Internet-Draft MIKEY-TICKET October 2009 Value Ticket Type ----------- ----------------- 0 Reserved 1 MIKEY base ticket 2 3GPP base ticket 3-61439 Unassigned 61440-65534 Private Use 65535 Reserved 14. References 14.1. Normative References [3GPP.33.828] 3GPP, "IP Multimedia Subsystem (IMS) media plane security", 3GPP TR 33.828 1.5.0, October 2009. [RFC2030] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI", RFC 2030, October 1996. [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. [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 Mattsson & Tian Expires April 22, 2010 [Page 42] Internet-Draft MIKEY-TICKET October 2009 IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. 14.2. Informative References [I-D.mcgrew-srtp-ekt] McGrew, D., Andreasen, F., Wing, D., and L. Dondeti, "Encrypted Key Transport for Secure RTP", draft-mcgrew-srtp-ekt-05 (work in progress), July 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. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004. [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. It SHALL be constructed as a MIKEY message protected via a MAC based on a pre-shared Ticket Protection Key (TPK). Which parties that shares the TPK depends on the mode. Ticket Data = THDR, T, RAND, KEMAC, [IDRpsk], V A.1. Components of the MIKEY Base Ticket The MIKEY base ticket MUST always begin with a Ticket Header payload (THDR). The ticket header is a new payload type, for definition see Appendix A.4. Mattsson & Tian Expires April 22, 2010 [Page 43] Internet-Draft MIKEY-TICKET October 2009 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. The KEMAC payload SHOULD use the NULL authentication algorithm, as a MAC is included in the V payload. The encryption key (encr_key) and salt 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. If key forking is used, MPKi and MPKr SHALL be derived from the MPK as defined in Appendix A.3. The KEMAC is hence constructed as follows: KEMAC = E(encr_key, MPK || {TGK|TEK}) 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 || 0xFD || 0xFFFFFFFF || RAND outkey_len : desired bit length of the outkey Where the constants are as defined in Section 4.1.4 of [RFC3830]. The key derivation and its dependencies on ticket data contents are illustrated in Figure 8. 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). Mattsson & Tian Expires April 22, 2010 [Page 44] Internet-Draft MIKEY-TICKET October 2009 +-----+ ----- auth_key | TPK |--------->| PRF |---------------------------------+ +-----+ | |----------------------+ | ^ ----- encr_key, salt_key | | : identify ^ | | : | v v Ticket +---+----+--------+--+---+-----------------+-------+----+---+ Data | IDRpsk |........| RAND |.................| KEMAC |....| V | +--------+--------+------+-----------------+-------+----+---+ Figure 8: 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 || 0xFC || 0xFFFFFFFF || RAND outkey_len : desired bit length of the outkey where 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. 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 ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Mattsson & Tian Expires April 22, 2010 [Page 45] Internet-Draft MIKEY-TICKET October 2009 * 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-roundtrip 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 9: 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- 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 Mattsson & Tian Expires April 22, 2010 [Page 46] Internet-Draft MIKEY-TICKET October 2009 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 10: 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 April 22, 2010 [Page 47]