idnits 2.17.1 draft-mattsson-mikey-ticket-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (June 8, 2010) is 5063 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'IDRi' is mentioned on line 1847, but not defined == Missing Reference: 'IDRkms' is mentioned on line 1847, but not defined == Missing Reference: 'IDRpsk' is mentioned on line 2402, but not defined == Missing Reference: 'CHASH' is mentioned on line 888, but not defined == Missing Reference: 'MPKr' is mentioned on line 697, but not defined == Missing Reference: 'IDRr' is mentioned on line 1231, but not defined == Missing Reference: 'KEMAC' is mentioned on line 1847, but not defined == Missing Reference: 'RANDRr' is mentioned on line 1193, but not defined == Missing Reference: 'RANDRkms' is mentioned on line 889, but not defined == Missing Reference: 'RANDRi' is mentioned on line 1193, but not defined == Missing Reference: 'V' is mentioned on line 1315, but not defined == Missing Reference: 'TRs' is mentioned on line 1847, but not defined == Missing Reference: 'TRe' is mentioned on line 1847, but not defined == Missing Reference: 'TRr' is mentioned on line 1847, but not defined ** Obsolete normative reference: RFC 4330 (Obsoleted by RFC 5905) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 2 errors (**), 0 flaws (~~), 16 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Mattsson 3 Internet-Draft Ericsson 4 Intended status: Informational T. Tian 5 Expires: December 10, 2010 ZTE 6 June 8, 2010 8 MIKEY-TICKET: Ticket Based Modes of Key Distribution 9 in Multimedia Internet KEYing (MIKEY) 10 draft-mattsson-mikey-ticket-05 12 Abstract 14 The Multimedia Internet KEYing (MIKEY) specification describes a key 15 management scheme for real-time applications. In this document, we 16 note that the currently defined MIKEY modes are insufficient to 17 address deployment scenarios built around a centralized key 18 management service. Such deployments are gaining in interest. 19 Therefore, a set of new MIKEY modes that work well in such scenarios 20 are defined. The new modes use a trusted key management service and 21 a ticket concept, similar to that in Kerberos. The new modes also 22 support features used by many existing applications, where the exact 23 identity of the other endpoint may not be known at the start of the 24 communication session. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on December 10, 2010. 43 Copyright Notice 45 Copyright (c) 2010 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2.1. Definitions and Notation . . . . . . . . . . . . . . . . . 5 63 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 6 64 2.3. Payloads . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 3. Design Considerations . . . . . . . . . . . . . . . . . . . . 7 66 4. MIKEY-TICKET . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 4.1.1. Modes . . . . . . . . . . . . . . . . . . . . . . . . 12 69 4.2. Exchanges . . . . . . . . . . . . . . . . . . . . . . . . 13 70 4.2.1. Ticket Request . . . . . . . . . . . . . . . . . . . . 13 71 4.2.2. Ticket Transfer . . . . . . . . . . . . . . . . . . . 16 72 4.2.3. Ticket Resolve . . . . . . . . . . . . . . . . . . . . 19 73 5. Key Management Functions . . . . . . . . . . . . . . . . . . . 22 74 5.1. Key Derivation . . . . . . . . . . . . . . . . . . . . . . 22 75 5.1.1. Deriving Forked Keys . . . . . . . . . . . . . . . . . 24 76 5.1.2. Deriving Keys from an Envelope/Pre-Shared Key/MPK . . 25 77 5.1.3. Deriving Keys from a TGK/GTGK . . . . . . . . . . . . 26 78 5.2. CSB Updating . . . . . . . . . . . . . . . . . . . . . . . 26 79 5.3. Ticket Reuse . . . . . . . . . . . . . . . . . . . . . . . 28 80 5.4. Error Handling . . . . . . . . . . . . . . . . . . . . . . 28 81 5.5. MAC/Signature Coverage . . . . . . . . . . . . . . . . . . 29 82 6. Payload Encoding . . . . . . . . . . . . . . . . . . . . . . . 30 83 6.1. Common Header Payload (HDR) . . . . . . . . . . . . . . . 30 84 6.1.1. The GENERIC-ID map type . . . . . . . . . . . . . . . 31 85 6.2. Key Data Transport Payload (KEMAC) . . . . . . . . . . . . 33 86 6.2.1. Key Data Sub-Payload . . . . . . . . . . . . . . . . . 34 87 6.3. Timestamp Payload (T) . . . . . . . . . . . . . . . . . . 35 88 6.4. Timestamp Payload with Role Indicator (TR) . . . . . . . . 35 89 6.5. ID Payload (ID) . . . . . . . . . . . . . . . . . . . . . 36 90 6.6. ID Payload with Role Indicator (IDR) . . . . . . . . . . . 36 91 6.7. Cert Hash Payload (CHASH) . . . . . . . . . . . . . . . . 37 92 6.8. RAND payload with Role Indicator (RANDR) . . . . . . . . . 37 93 6.9. Error Payload (ERR) . . . . . . . . . . . . . . . . . . . 38 94 6.10. Ticket Policy Payload (TP) / Ticket Payload (TICKET) . . . 38 95 7. Transport Protocols . . . . . . . . . . . . . . . . . . . . . 42 96 8. Pre-Encrypted Content . . . . . . . . . . . . . . . . . . . . 42 97 9. Group Communication . . . . . . . . . . . . . . . . . . . . . 42 98 9.1. Key Forking . . . . . . . . . . . . . . . . . . . . . . . 43 99 10. Signaling Between Different KMSs . . . . . . . . . . . . . . . 43 100 11. Adding New Ticket Types to MIKEY-TICKET . . . . . . . . . . . 44 101 12. Security Considerations . . . . . . . . . . . . . . . . . . . 45 102 12.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 45 103 12.2. Key Forking . . . . . . . . . . . . . . . . . . . . . . . 47 104 12.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 47 105 12.4. Replay . . . . . . . . . . . . . . . . . . . . . . . . . . 47 106 12.5. Group Key Management . . . . . . . . . . . . . . . . . . . 48 107 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 48 108 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 109 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 51 110 15.1. Normative References . . . . . . . . . . . . . . . . . . . 51 111 15.2. Informative References . . . . . . . . . . . . . . . . . . 52 112 Appendix A. MIKEY Base Ticket . . . . . . . . . . . . . . . . . . 52 113 A.1. Components of the Ticket Data . . . . . . . . . . . . . . 53 114 A.2. Key Derivation . . . . . . . . . . . . . . . . . . . . . . 53 115 A.2.1. Deriving Keys from a TPK . . . . . . . . . . . . . . . 53 116 A.2.2. Deriving MPKi and MPKr . . . . . . . . . . . . . . . . 54 117 A.3. Ticket Header Payload (THDR) . . . . . . . . . . . . . . . 55 118 Appendix B. Alternative Use Cases . . . . . . . . . . . . . . . . 55 119 B.1. Compatibility Mode . . . . . . . . . . . . . . . . . . . . 55 120 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 56 122 1. Introduction 124 Key management systems are either based on negotiation and exchange 125 directly between peers (e.g. Diffie-Hellman based schemes), pre- 126 distribution of user credentials (shared secrets/certificates), or 127 availability of a trusted Key Management Service (KMS). The modes 128 described in the Multimedia Internet KEYing (MIKEY) specification 129 [RFC3830] and its extensions [RFC4650] [RFC4738] are all variants of 130 the first two alternatives. 132 In security systems serving a large number of users, a solution based 133 on a key management service is often preferred. With such a service 134 in place, there is no need to pre-distribute credentials that 135 directly can be used to establish security associations between peers 136 for protected communication, as users can request such credentials 137 when needed. Solutions based on a trusted key management service 138 also scale well when the number of users grows. 140 This document introduces a set of new MIKEY modes that go under the 141 common name MIKEY-TICKET. It supports a ticket concept, similar to 142 that in Kerberos [RFC4120], which is used to identify and deliver 143 keys. A high level outline of MIKEY-TICKET as defined herein is that 144 the Initiator requests keys and a ticket from the KMS and sends the 145 ticket to the Responder. The ticket contains a reference to the 146 keys, or the enveloped keys. The Responder then sends the ticket to 147 the KMS, which returns the appropriate keys. 149 MIKEY-TICKET is primarily designed to be used for media plane 150 security in the 3GPP IP Multimedia Subsystem (IMS) [3GPP.33.328]. 151 This implies that some extensions to the basic Kerberos concept are 152 needed. For instance, the Initiator may not always know the exact 153 identity of the Responder when the communication with the key 154 management server is initiated. 156 This document defines a signaling framework enabling peers to 157 request, transfer, and resolve various Ticket Types using a key 158 management service. A default Ticket Type is also defined. To allow 159 the use of 256-bit keys for users with high security requirements, 160 additional encryption, authentication, and pseudo-random functions 161 are defined. 163 2. Terminology 165 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 166 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 167 document are to be interpreted as described in [RFC2119]. 169 Definitions of terms and notation will, unless otherwise stated, be 170 as defined in [RFC3830]. 172 2.1. Definitions and Notation 174 Forking: The delivery of a request to multiple endpoints (multiple 175 devices owned by a single user or multiple users). 177 Key forking: When used in conjunction with forking, key forking 178 refers to the process of modifying keys, making them 179 cryptographically unique for each responder targeted by the forking. 181 (Media) session: The communication session intended to be secured by 182 the MIKEY-TICKET provided key(s). 184 Session information: Information related to the security protocols 185 used to protect the media session: keys, salts, algorithms, etc. 187 Ticket: A Kerberos-like object used to identify and deliver keys over 188 an untrusted network. 190 Ticket Data: Ticket part with information intended only for the party 191 that resolves the ticket (e.g. keys). 193 Ticket Request: Exchange used by the Initiator to request keys and a 194 ticket from a trusted KMS. 196 Ticket Transfer: Exchange used to transfer the ticket as well as 197 session information from the Initiator to the Responder. 199 Ticket Resolve: Exchange used by the Responder to request the KMS to 200 return the keys encoded in a ticket. 202 Ticket Policy: Policy for ticket generation and resolution, 203 authorized applications, key derivation, etc. 205 Ticket Type: Defines ticket format and processing. May further have 206 subtype and version. 208 Solid arrows (----->) indicate mandatory messages. 209 Dashed arrows (- - ->) indicate optional messages. 211 E(k, p) Encryption of p with the key k 212 PKx Public Key of entity x 213 k' The forked key k 214 [p] p is optional 215 {p} Zero or more occurrences of p 216 (p) One or more occurrences of p 217 || Concatenation 218 | OR (selection operator) 220 2.2. Abbreviations 222 3GPP: 3rd Generation Partnership Project 223 AAA: Authentication, Authorization, and Accounting 224 ACL: Access Control List 225 AES: Advanced Encryption Standard 226 CA: Certification Authority 227 CS: Crypto Session 228 CSB: Crypto Session Bundle 229 IMS: IP Multimedia Subsystem 230 GTGK: Group TGK 231 HMAC: Hash-based Message Authentication Code 232 KMS: Key Management Service 233 MAC: Message Authentication Code 234 MIKEY: Multimedia Internet KEYing 235 NSPS: National Security and Public Safety 236 MKI: Master Key Identifier 237 MPK: MIKEY Protection Key 238 NTP: Network Time Protocol 239 PET: Privacy Enhancing Technologies 240 PK: Public-Key 241 PRF: Pseudo-Random Function 242 PRNG: Pseudo-Random Number Generator 243 PSK: Pre-Shared Key 244 RTSP: Real-Time Streaming Protocol 245 SDP: Session Description Protocol 246 SHA: Secure Hash Algorithm 247 SIP: Session Initiation Protocol 248 SPI: Security Parameters Index 249 SRTP: Secure Real-time Transport Protocol 250 TEK: Traffic Encryption Key 251 TGK: TEK Generation Key 252 TPK: Ticket Protection Key 253 UTC: Coordinated Universal Time 255 2.3. Payloads 257 CERTx: Certificate of entity x 258 CHASH: Hash of the certificate used 259 HDR: Common Header payload 260 ID: Identity payload 261 IDRx: Identifier for entity x 262 IDRpsk: Identifier for pre-shared key 263 IDRapp: Identifier for application/service 264 KEMAC: Key data transport payload 265 PKE: Encrypted envelope key 266 RAND: RAND payload 267 RANDRx: Random value generated by entity x 268 SIGNx: Signature created using entity x's private key 269 SP: Security Policy payload 270 T: Timestamp payload 271 TRy: Timestamp payload with role indicator y 272 THDR: Ticket Header payload 273 TICKET: Ticket payload 274 TP: Ticket Policy payload 275 V: Verification payload 277 where 278 x is in the set {i, r, kms} (Initiator, Responder, KMS) and 279 y is in the set {i, s, e, r} (time of Issue, Start time, End time, 280 Rekeying interval). 282 The IDR, RANDR, TR, TICKET, and TP payloads are defined in Section 6. 283 Note that in [RFC3830], there is defined both a V payload (carrying 284 the authentication tag) and a V flag in the HDR payload (indicating 285 whether a response message is expected or not). 287 3. Design Considerations 289 As mentioned in the introduction, none of the previously defined 290 MIKEY modes are based on a KMS. The pre-shared key method and the 291 public-key encryption method defined in [RFC3830] are examples of 292 systems based on pre-distribution of user credentials. The Diffie- 293 Hellman method [RFC3830] is an example of a system based on 294 negotiation and exchange directly between peers. 296 In some situations, a request may be delivered to multiple endpoints. 297 The endpoints may be multiple devices owned by a single user (e.g. 298 mobile phone, fixed phone, and computer), or multiple users (e.g. 299 IT-support@example.com, a group of users where only one is supposed 300 to answer). In the following, the term forking will be used to 301 describe all such cases. One example of delivery to multiple 302 endpoints is forking and retargeting in SIP [RFC3261]. To prevent 303 any form of eavesdropping, only the endpoint that answers should get 304 access to the session keys. The naive application of [RFC3830] where 305 all endpoints share the same pre-shared/private key is not secure 306 when it comes to forking as all endpoints get access to the session 307 keys. Conversely, having per-user unique pre-shared keys/ 308 certificates creates more fundamental problems with forking, as the 309 initiator does not know which pre-shared key/certificate to use at 310 session initiation. SIP-signaled media protection is described in 311 [RFC5479] and the applicability of different MIKEY modes is discussed 312 in [RFC5197]. 314 In security systems serving a large number of users, a solution based 315 on a key management service is often preferred. With such a service 316 in place, there is no need to pre-distribute credentials that 317 directly can be used to establish security associations between peers 318 for protected communication, as users can request such credentials 319 when needed. In many applications, e.g. National Security and 320 Public Safety (NSPS), the controlling organization wants to enforce 321 policies on the use of keys. A trusted KMS fits these applications 322 well as it makes it easier to enforce policies centrally. Solutions 323 based on a trusted KMS also scale well when the number of users 324 grows. A KMS based on symmetric keys has particular advantages as 325 symmetric key algorithms are generally much less computationally 326 intensive than asymmetric key algorithms. 328 Systems based on a KMS require a signaling mechanism that allows 329 peers to retrieve other peers' credentials. A convenient way to 330 implement such a signaling scheme is to use a ticket concept, similar 331 to that in Kerberos [RFC4120], to identify and deliver keys. The 332 ticket can be forwarded in the signaling associated with the session 333 setup. The initiator requests a ticket from the KMS and sends the 334 ticket to the responder. The responder forwards the ticket to the 335 KMS, which returns the corresponding keys. 337 It should be noted that Kerberos does not require that the responder 338 also contacts the KMS. However, in order to support also the 339 aforementioned forking scenarios it becomes necessary that the ticket 340 is not bound to the exact identity (or credentials) of the responder 341 until the final responder becomes fully determined. Group and 342 forking communication scenarios can also be improved from access 343 control point of view if authorization to access the keys can be 344 enforced with higher granularity at the responder side. The 345 mechanism specified in this document is useful for any system where 346 the initial message may be transferred to arbitrarily many potential 347 responders, and where the set of responders may change at any time. 348 In addition to being able to meet the requirements just described, 349 the mechanism specified in this document also supports group key 350 management. 352 The ticket can contain a reference to keys held by the key management 353 system or it can hold the keys itself. In the latter case, the 354 ticket needs to be confidentiality and integrity protected 355 (enveloped). In the following, the term encoded keys will be used to 356 describe both cases as well as keys derived from such keys. 358 By using different Ticket Types and ticket policies, some allowing 359 the initiator or responder to create or resolve the tickets without 360 assistance from the KMS, a wide range of different security levels 361 and use cases can be supported. This has a number of advantages as 362 it offers a framework which is flexible enough to satisfy users with 363 a broad range of security and functional needs. 365 The use of a ticket based system may also help in the handling of 366 keys for deferred delivery of end-to-end protected content to 367 currently off-line users. Such scenarios exclude all key management 368 schemes that are based on some type of direct online negotiation 369 between peers (e.g. Diffie-Hellman based schemes) as the responder 370 cannot rely on contacting the initiator to get access to keys. 372 At the same time, it is also important to be aware that (centralized) 373 key management services may introduce a single point of (security) 374 failure. The security requirements on the implementation and 375 protection of the KMS may therefore in high security applications be 376 more or less equivalent to the requirements of an AAA 377 (Authentication, Authorization, and Accounting) server or a 378 Certificate Authority (CA). 380 4. MIKEY-TICKET 382 4.1. Overview 384 All previously defined MIKEY modes consist of a single (or half) 385 round-trip between two peers. MIKEY-TICKET differs from these modes 386 as it consists of up to three different round-trips (Ticket Request, 387 Ticket Transfer, and Ticket Resolve) involving three parties 388 (Initiator, Responder, and KMS). Since the number of round-trips and 389 order of messages may vary, MIKEY-TICKET is actually the common name 390 for a set of modes, all revolving around a ticket concept. The third 391 party, the KMS, is only involved in some of the MIKEY exchanges and 392 not at all in the resulting secure media session. The Ticket Request 393 and Ticket Resolve exchanges are meant to be used in combination with 394 the Ticket Transfer exchange and not on their own. In Figure 1, the 395 signaling for the full three round-trip MIKEY-TICKET mode is 396 depicted. 398 +---+ +-----+ +---+ 399 | I | | KMS | | R | 400 +---+ +-----+ +---+ 401 REQUEST_INIT 402 --------------------------------> 403 REQUEST_RESP 404 <-------------------------------- 405 TRANSFER_INIT 406 ----------------------------------------------------------------> 407 RESOLVE_INIT 408 <-------------------------------- 409 RESOLVE_RESP 410 --------------------------------> 411 TRANSFER_RESP 412 <---------------------------------------------------------------- 414 Figure 1: Full three round-trip signaling 416 The Initiator (I) wants to establish a secure media session with the 417 Responder (R). The Initiator and the Responder do not share any 418 credentials, instead they trust a third party, the KMS, with which 419 they both have or can establish shared credentials. These pre- 420 established trust relations are used to establish a security 421 association between I and R. The assumed trust model is illustrated 422 in Figure 2. 424 Pre-established trust relation Pre-established trust relation 425 <------------------------------> <------------------------------> 426 +---+ +-----+ +---+ 427 | I | | KMS | | R | 428 +---+ +-----+ +---+ 429 <---------------------------------------------------------------> 430 Security association based on ticket 432 Figure 2: Trust model 434 Note that rather than a single KMS, multiple KMSs may be involved, 435 e.g. one for the Initiator and one for the Responder; this is 436 discussed in Section 10. 438 The Initiator requests keys and a ticket (encoding the same keys) 439 from the KMS by sending a REQUEST_INIT message. The REQUEST_INIT 440 message includes session information (e.g. identities of the 441 authorized responders) and is integrity protected by a MAC based on a 442 pre-shared key or by a signature (similar to the pre-shared key and 443 public-key encryption modes in [RFC3830]). If the request is 444 authorized, the KMS generates the requested keys, encodes them in a 445 ticket, and returns the keys and the ticket in a REQUEST_RESP 446 message. The Ticket Request exchange is OPTIONAL (depending on the 447 Ticket Type), and MAY be omitted if the Initiator can create the 448 ticket without assistance from the KMS (see mode 3 of Section 4.1.1). 450 The Initiator next includes the ticket in a TRANSFER_INIT message, 451 which is sent to the Responder. The TRANSFER_INIT message is 452 protected by a MAC based on a MPK (MIKEY Protection Key) encoded in 453 the ticket. If the Responder finds the Ticket Policy and session 454 security policies acceptable, the Responder forwards the ticket to 455 the KMS. This is done with a RESOLVE_INIT message, which asks the 456 KMS to return the keys encoded in the ticket. The RESOLVE_INIT 457 message is protected by a MAC based on a pre-shared key (between 458 Responder and KMS) or by a signature. The Ticket Resolve exchange is 459 OPTIONAL (depending on the Ticket Policy), and SHOULD only be used 460 when the Responder is unable to resolve the ticket without assistance 461 from the KMS (see mode 2 of Section 4.1.1). 463 The KMS resolves the ticket. If the Responder is authorized to 464 receive the keys encoded in the ticket, the KMS retrieves the keys 465 and other information. If key forking is used, the keys are modified 466 (bound to the Responder) by the KMS, see Section 5.1.1. The keys and 467 additional information are then sent in a RESOLVE_RESP message to the 468 Responder. The Responder then sends a TRANSFER_RESP message to the 469 Initiator as verification. The TRANSFER_RESP message might include 470 information used for further key derivation. 472 The use case and signaling described above is the full three round- 473 trip mode but other modes are allowed, see Section 4.1.1. Group 474 communication is discussed in Section 9, Pre-Encrypted Content is 475 discussed in Section 8, and signaling between different KMSs is 476 discussed in Section 10. An alternative use case is discussed in 477 Appendix B. 479 The session keys are normally generated/supplied by the KMS (encoded 480 in the ticket), but in certain use cases (see Section 8) the session 481 key may be supplied by the Initiator or Responder (sent in a separate 482 KEMAC protected with keys derived from the MPK). 484 MIKEY-TICKET offers a framework which is flexible enough to satisfy 485 users with a broad range of security and functional needs. The 486 framework consists of the three exchanges for which different Ticket 487 Types can be defined. The ticket consists of a Ticket Policy as well 488 as Ticket Data. The Ticket Policy contains information intended for 489 all parties involved, whereas the Ticket Data is only intended for 490 the party that resolves the ticket. The Ticket Data could be a 491 reference to information (keys etc.) stored by the key management 492 service, it could contain all the information itself, or it could be 493 a combination of the two alternatives. The format of the Ticket Data 494 depends on the Ticket Type signaled in the Ticket Policy. The Ticket 495 Data corresponding to the default Ticket Type called MIKEY base 496 ticket is given in Appendix A and requirements regarding new Ticket 497 Types are given in Section 11. 499 As MIKEY-TICKET is based on [RFC3830], the same terminology, 500 processing and considerations still apply unless otherwise stated. 501 Just like in [RFC3830], the messages are integrity protected and 502 encryption is only applied to the keys and not to the entire 503 messages. 505 4.1.1. Modes 507 Depending on the Ticket Type and the Ticket Policy, some of the 508 exchanges might be optional or not used at all, see Figure 3. If the 509 ticket protection is based on a key known only by the KMS, both the 510 Initiator and the Responder have to contact the KMS to request/ 511 resolve tickets (mode 1). If the key used to protect the ticket is 512 shared between the KMS and the Responder, the Ticket Resolve exchange 513 can be omitted (similar to Kerberos), as the Responder can resolve 514 the ticket without assistance from the KMS (mode 2). 516 +---+ +-----+ +---+ 517 | I | | KMS | | R | 518 +---+ +-----+ +---+ 519 Ticket Request 520 (1) <------------------------------> Ticket Transfer 521 <-------------------------------------------------------------> 522 <------------------------------> 523 Ticket Resolve 524 Ticket Request 525 (2) <------------------------------> Ticket Transfer 526 <-------------------------------------------------------------> 528 Ticket Transfer 529 (3) <-------------------------------------------------------------> 530 <------------------------------> 531 Ticket Resolve 533 Ticket Transfer 534 (4) <-------------------------------------------------------------> 536 Figure 3: Modes 538 If the key protecting the ticket is shared between the Initiator and 539 the KMS, the Ticket Request exchange can be omitted (similar to the 540 Otway-Rees protocol [Otway-Rees]), as the Initiator can create the 541 ticket without assistance from the KMS (mode 3). If the key 542 protecting the ticket is shared between the Initiator and the 543 Responder, both the Ticket Request and Ticket Resolve exchanges can 544 be omitted (mode 4). This can be seen as a variation of the pre- 545 shared key method of [RFC3830] with mutual key freshness guarantee. 547 In mode 1 and 2 the Ticket Request exchange can be omitted if the 548 tickets and the corresponding keys are distributed from the KMS to 549 the Initiator in some other way. In addition, as tickets may be 550 reused (see Section 5.3), a single Ticket Request exchange may be 551 followed by several Ticket Transfer exchanges. 553 4.2. Exchanges 555 4.2.1. Ticket Request 557 This exchange is used by the Initiator to request keys and a ticket 558 from a trusted KMS, with which the Initiator has pre-shared 559 credentials. The request contains information (e.g. participant 560 identities, etc.) describing the session the ticket is intended to 561 protect. A full round-trip is required for the Initiator to receive 562 the ticket. The initial message REQUEST_INIT comes in two variants. 563 The first variant corresponds to the pre-shared key (PSK) method of 564 [RFC3830]. 566 Initiator KMS 568 REQUEST_INIT_PSK = ----> 569 HDR, T, RANDRi, [IDRi], 570 [IDRkms], TP, <---- REQUEST_RESP = 571 [IDRpsk], V HDR, T, [IDRkms], 572 TICKET, KEMAC, V 574 The second variant corresponds to the public-key (PK) method of 575 [RFC3830]. 577 Initiator KMS 579 REQUEST_INIT_PK = ----> 580 HDR, T, RANDRi, [IDRi], 581 {CERTi}, [IDRkms], TP, <---- REQUEST_RESP = 582 [CHASH], PKE, SIGNi HDR, T, [IDRkms], 583 TICKET, KEMAC, V 585 As the REQUEST_INIT message MUST ensure the identity of the Initiator 586 to the KMS, it SHALL be integrity protected by a MAC based on a pre- 587 shared key or by a signature. The response message REQUEST_RESP is 588 the same for the two variants and SHALL be protected by using the 589 pre-shared/envelope key indicated in the REQUEST_INIT message. 591 In addition to the ticket, the Initiator receives keys, which it does 592 not already know. The ticket contains both session information and 593 information needed to resolve the ticket later, see Section 6.10. 595 4.2.1.1. Common Components of the REQUEST_INIT Messages 597 The REQUEST_INIT message MUST always include the Header (HDR), 598 Timestamp (T), and RANDRi payloads. 600 In HDR the CSB ID (Crypto Session Bundle ID) SHALL be assigned as in 601 [RFC3830]. The V flag MUST be set to '1' but SHALL be ignored by the 602 KMS as a response is MANDATORY. As Crypto Sessions (CS) SHALL NOT be 603 handled, the #CS MUST be set to 0 and the CS ID map type SHALL be the 604 "Empty map" as defined in [RFC4563]. 606 IDRi contains the identity of the Initiator. This identity SHOULD be 607 included in the granted Ticket Policy. 609 IDRkms contains the identity of the KMS. It SHOULD be included, but 610 it MAY be left out when it can be expected that the KMS has a single 611 identity. 613 The Ticket Policy payload (TP) contains the desired Ticket Policy. 614 It includes for instance, the ticket's validity period, the number of 615 requested keys, and the identities of authorized responders (see 616 Section 6.10). 618 4.2.1.2. Components of the REQUEST_INIT_PSK Message 620 The IDRi payload SHOULD be included but MAY be left out when it can 621 be expected that the KMS can identify the Initiator by other means. 623 The IDRpsk payload is used to indicate the pre-shared key used. It 624 MAY be omitted if the KMS can find the pre-shared key by other means. 626 The last payload SHALL be a Verification payload (V) where the 627 authentication key (auth_key) is derived from the pre-shared key 628 shared by the Initiator and the KMS (see Section 5.1.2 for key 629 derivation specification). The MAC SHALL cover the entire 630 REQUEST_INIT_PSK message as well as the identities of the involved 631 parties (see Section 5.5 for the exact definition). 633 4.2.1.3. Components of the REQUEST_INIT_PK Message 635 The identity IDRi and certificate CERTi SHOULD be included, but they 636 MAY be left out when it can be expected that the KMS can obtain the 637 certificate in some other manner. If a certificate chain is to be 638 provided, each certificate in the chain SHOULD be included in a 639 separate CERT payload. The Initiator's certificate MUST come first. 640 Each following certificate MUST directly certify the one preceding 641 it. 643 PKE contains the encrypted envelope key: PKE = E(PKkms, env_key). It 644 is encrypted using the KMS's public key (PKkms). If the KMS 645 possesses several public keys, the Initiator can indicate the key 646 used in the CHASH payload. 648 SIGNi is a signature covering the entire REQUEST_INIT_PK message, 649 using the Initiator's signature key (see Section 5.5 for the exact 650 definition). 652 4.2.1.4. Processing the REQUEST_INIT Message 654 If the KMS can verify the integrity of the received message and the 655 message can be correctly parsed, the KMS MUST check the Initiator's 656 authorization. If the Initiator is authorized to receive the 657 requested ticket, possibly with a modified Ticket Policy, the KMS 658 MUST send a REQUEST_RESP message. Unexpected payloads in the 659 REQUEST_INIT message SHOULD be ignored. Errors are handled as 660 described in Section 5.4. 662 4.2.1.5. Components of the REQUEST_RESP Message 664 The version, PRF func and CSB ID, #CS, and CS ID map type fields in 665 the HDR payload SHALL be identical to the corresponding fields in the 666 REQUEST_INIT message. The V flag has no meaning in this context. It 667 SHALL be set to '0' by the KMS and ignored by the Initiator. 669 If one of the NTP timestamp types is used, the KMS SHALL generate a 670 fresh timestamp value (unlike [RFC3830]), which may be used for clock 671 synchronization. If the COUNTER timestamp type (see Section 6.6 of 672 [RFC3830]) is used, the timestamp value MAY be equal to the one in 673 the REQUEST_INIT message. 675 The TICKET payload carries the granted Ticket Policy and the Ticket 676 Data (see Section 6.10). As the KMS decides which Ticket Policy to 677 use, this may not be the same Ticket Policy as the Initiator 678 requested. The Ticket Type and the Ticket Data depend on the granted 679 Ticket Policy. 681 The KEMAC payload SHALL use the NULL authentication algorithm, as a 682 MAC is included in the V payload. Depending on the type of 683 REQUEST_INIT message, either the pre-shared key or the envelope key 684 SHALL be used to derive the encr_key (and salt_key). Depending on 685 the encryption algorithm, the salting key may go into the IV (see 686 [RFC3830]). If the TP payload in the REQUEST_INIT message does not 687 contain a KEMAC, it is RECOMMENDED that the KMS's default KEMAC 688 includes a single TGK. The KEMAC SHALL include a MPK (MIKEY 689 Protection Key), MPKi, used as a pre-shared key to protect the 690 messages in the Ticket Transfer exchange. If key forking (see 691 Section 5.1.1) is used (determined by the Ticket Policy) a second 692 MPK, MPKr, SHALL be included in the KEMAC. Then MPKi SHALL be used 693 to protect the TRANSFER_INIT message and MPKr SHALL be used to verify 694 the TRANSFER_RESP message. The KEMAC is hence constructed as 695 follows: 697 KEMAC = E(encr_key, MPKi || [MPKr] || {TEK|TGK|GTGK}) 699 The last payload SHALL be a Verification payload (V). Depending on 700 the type of REQUEST_INIT message, either the pre-shared key or the 701 envelope key SHALL be used to derive the auth_key. The MAC SHALL 702 cover the entire REQUEST_RESP message as well as the REQUEST_INIT 703 message (see Section 5.5 for the exact definition). 705 4.2.1.6. Processing the REQUEST_RESP Message 707 If the Initiator can verify the integrity of the received message and 708 the message can be correctly parsed, the ticket and the associated 709 session information SHALL be stored. Unexpected payloads in the 710 REQUEST_RESP message SHOULD be ignored. Errors are handled as 711 described in Section 5.4. 713 Before using the received ticket, the Initiator MUST check that the 714 granted Ticket Policy is acceptable. If not, the Initiator SHALL 715 discard and MAY send a new REQUEST_INIT message suggesting a 716 different Ticket Policy than before. 718 4.2.2. Ticket Transfer 720 This exchange is used to transfer a ticket as well as session 721 information from the Initiator to a Responder. The exchange is 722 modeled after the pre-shared key mode [RFC3830], but instead of a 723 pre-shared key, a MPK encoded in the ticket is used. The session 724 keys are also encoded in the TICKET payload, but in some use cases 725 (see Section 8) they need to be sent in a separate KEMAC payload. 726 The session information may be sent from the Initiator to the 727 Responder (similar to [RFC3830]) or from the Responder to the 728 Initiator (similar to [RFC4738]). As the motive for this exchange is 729 to setup a shared secret key between Initiator and Responder, the 730 Responder cannot check the authenticity of the message before the 731 ticket is resolved (by KMS or Responder). A full round-trip is 732 required if Responder key confirmation and freshness guarantee are 733 needed. 735 Initiator Responder 737 TRANSFER_INIT = ----> 738 HDR, T, RANDRi, [IDRi], 739 [IDRr], {SP}, TICKET, < - - TRANSFER_RESP = 740 [KEMAC], V HDR, T, [RANDRr], 741 [IDRr], [RANDRkms], 742 {SP}, [KEMAC], V 744 4.2.2.1. Components of the TRANSFER_INIT Message 746 The TRANSFER_INIT message MUST always include the Header (HDR), 747 Timestamp (T), and RANDRi payloads. 749 In HDR, the CSB ID (Crypto Session Bundle ID) SHALL be assigned as in 750 [RFC3830]. The value of the V flag SHALL agree with the F flag in 751 the Ticket Policy and it SHALL be ignored by the Responder. 753 The IDRi and IDRr payloads SHOULD be included, but IDRi MAY be left 754 out if the Responder can identify the Initiator by other means, and 755 IDRr MAY be left out when it can be expected that the Responder has a 756 single identity. 758 Multiple SP payloads MAY be used both to indicate supported security 759 policies for a specific crypto session (similar to [RFC4738]), and to 760 specify security policies for different crypto sessions (similar to 761 [RFC3830]). 763 The ticket payload (see Section 6.10) contains the Ticket Policy (see 764 Section 6.10) as well as Ticket Data (the default ticket type is 765 defined in Appendix A). The Ticket Policy contains information 766 intended for all parties involved whereas the Ticket Data is only 767 intended for the party that resolves the ticket. The Ticket Type 768 provided in the Ticket Data is indicated in the Ticket Policy. 770 The KEMAC payload is handled in the same way as if it were sent in a 771 later CSB update (see Section 5.2), with the only difference that the 772 encr_key is always derived from MPKi. Initiator specified keys MAY 773 be used if Initiator has pre-encrypted content and specific TEKs 774 (Traffic Encryption Keys) need to be used (see Section 8). If 775 indicated by the Ticket Policy (L flag), a KEMAC payload SHALL NOT be 776 included. 778 The last payload SHALL be a Verification payload (V) where the 779 authentication key (auth_key) is derived from the MPKi (see 780 Section 5.1.2 for key derivation specification). The MAC SHALL cover 781 the entire TRANSFER_INIT message as well as the identities of the 782 involved parties (see Section 5.5 for the exact definition). 784 4.2.2.2. Processing the TRANSFER_INIT Message 786 As the Initiator and Responder do not have any pre-shared keys, the 787 Responder cannot check the authenticity of the message before the 788 ticket is resolved. The Responder SHALL however check that both the 789 Ticket Policy and the security policies (SP) are acceptable. If they 790 are not, the Responder SHALL reject without contacting the KMS. This 791 is an early reject mechanism to avoid unnecessary KMS signaling when 792 the Responder can conclude from the information at hand that it will 793 not accept the connection. After the ticket has been resolved the 794 parsing of the TRANSFER_INIT message continues. Unexpected payloads 795 in the TRANSFER_INIT message SHOULD be ignored. Errors are handled 796 as described in Section 5.4. If the F flag in the Ticket Policy is 797 set, the Responder MUST send a TRANSFER_RESP message. 799 4.2.2.3. Components of the TRANSFER_RESP Message 801 The version, PRF func and CSB ID fields in the HDR payload SHALL be 802 identical to the corresponding fields in the TRANSFER_INIT message. 803 The V flag has no meaning in this context. It SHALL be set to '0' by 804 the Responder and ignored by the Initiator. The Responder SHALL 805 update the CS ID map info so that each crypto session has exactly one 806 security policy indicated. The Responder MUST provide Session Data 807 (at least for SRTP) and SPI for each crypto session, which the 808 Initiator did not provide it for. If the Responder adds crypto 809 sessions, the #CS SHALL be updated. 811 If one of the NTP timestamp types is used, the Responder SHALL 812 generate a fresh timestamp value (unlike [RFC3830]). If the COUNTER 813 timestamp type (see Section 6.6 of [RFC3830]) is used, the timestamp 814 value MAY be equal to the one in the TRANSFER_INIT message. 816 If indicated by the Ticket Policy (G flag), the Responder SHALL 817 generate a fresh (pseudo-)random byte string RANDRr. RANDRr is used 818 to produce Responder freshness guarantee in key derivations. 820 If the Responder receives an IDRr payload in the RESOLVE_RESP 821 message, the same identity MUST be sent in an IDRr payload in the 822 TRANSFER_RESP message. The identity sent in the IDRr payload in the 823 TRANSFER_RESP message (e.g. user1@example.com) MAY differ from the 824 one sent in the IDRr payload in the TRANSFER_INIT message (e.g. 825 IT-support@example.com). 827 If the Responder receives a RANDRkms payload in the RESOLVE_RESP 828 message, the same RAND MUST be sent in a RANDRkms payload in the 829 TRANSFER_RESP message. 831 The Responder MAY provide additional Security Policy payloads. The 832 Responder SHOULD NOT resend SP payloads, which the Initiator 833 supplied. 835 The KEMAC payload SHALL be handled exactly as if it was sent in a 836 later CSB update, see Section 5.2. Responder specified keys MAY be 837 used if Responder has pre-encrypted content and specific TEKs 838 (Traffic Encryption Keys) need to be used (see Section 8). If 839 indicated by the Ticket Policy (M flag), a KEMAC payload SHALL NOT be 840 included. 842 The last payload SHALL be a Verification payload (V) where the 843 authentication key (auth_key) is derived from MPKi or MPKr' 844 (depending on if key forking is used). The MAC SHALL cover the 845 entire TRANSFER_RESP message as well as the TRANSFER_INIT message 846 (see Section 5.5 for the exact definition). 848 4.2.2.4. Processing the TRANSFER_RESP Message 850 If the Initiator can verify the integrity of the received message and 851 the message can be correctly parsed, the Initiator MUST check that 852 any Responder generated security policies (SP) are acceptable. If 853 not, the Initiator SHALL discard and MAY send a new TRANSFER_INIT 854 message to indicate supported security policies. Unexpected payloads 855 in the TRANSFER_RESP message SHOULD be ignored. Errors are handled 856 as described in Section 5.4. 858 4.2.3. Ticket Resolve 860 This exchange is used by the Responder to request the KMS to return 861 the keys encoded in a ticket. The KMS does not need to be the same 862 KMS that originally issued the ticket, see Section 10. A full round- 863 trip is required for the Responder to receive the keys. The Ticket 864 Resolve exchange is OPTIONAL (depending on the Ticket Policy), and 865 SHOULD only be used when the Responder is unable to resolve the 866 ticket without assistance from the KMS. The initial message 867 RESOLVE_INIT comes in two variants (independent from the used 868 REQUEST_INIT variant). The first variant corresponds to the pre- 869 shared key (PSK) method of [RFC3830]. 871 Responder KMS 873 RESOLVE_INIT_PSK = ----> 874 HDR, T, RANDRr, [IDRr], 875 [IDRkms], TICKET, <---- RESOLVE_RESP 876 [IDRpsk], V HDR, T, [IDRkms], KEMAC, 877 [IDRr], [RANDRkms], V 879 The second variant corresponds to the public-key (PK) method of 881 [RFC3830]. 883 Responder KMS 885 RESOLVE_INIT_PK = ----> 886 HDR, T, RANDRr, [IDRr], 887 {CERTr}, [IDRkms], TICKET, <---- RESOLVE_RESP 888 [CHASH], PKE, SIGNr HDR, T, [IDRkms], KEMAC, 889 [IDRr], [RANDRkms], V 891 As the RESOLVE_INIT message MUST ensure the identity of the Responder 892 to the KMS, it SHALL be protected by a MAC based on a pre-shared key 893 or by a signature. The response message RESOLVE_RESP is the same for 894 the two variants and SHALL be protected by using the pre-shared/ 895 envelope key indicated in the RESOLVE_INIT message. 897 Upon receiving the RESOLVE_INIT message, the KMS verifies that the 898 Responder is authorized to resolve the ticket based on ticket and KMS 899 policies. The KMS extracts the session information from the ticket 900 and returns this to the Responder. Since the KMS resolved the 901 ticket, the Responder is assured of the integrity of the Ticket 902 Policy, which contains the identity of the peer that requested or 903 created the ticket. The Responder can complete the session 904 information it got from the Initiator with the additional session 905 information received from the KMS. 907 4.2.3.1. Common Components of the RESOLVE_INIT Messages 909 The RESOLVE_INIT message MUST always include the Header (HDR), 910 Timestamp (T), and RANDRr payloads. 912 The CSB ID (Crypto Session Bundle ID) SHALL be assigned as in 913 [RFC3830]. The V flag MUST be set to '1' but SHALL be ignored by the 914 KMS as a response is MANDATORY. As crypto sessions SHALL NOT be 915 handled, the #CS MUST be set to 0 and the CS ID map type SHALL be the 916 "Empty map" as defined in [RFC4563]. 918 IDRkms SHOULD be included, but it MAY be left out when it can be 919 expected that the KMS has a single identity. 921 The TICKET payload contains the Ticket Policy and Ticket Data that 922 the Responder wants to have resolved. 924 4.2.3.2. Components of the RESOLVE_INIT_PSK Message 926 IDRr contains the identity of the Responder. IDRr SHOULD be 927 included, but it MAY be left out when it can be expected that the KMS 928 can identify the Responder in some other manner. 930 The IDRpsk payload is used to indicate the pre-shared key used. It 931 MAY be omitted if the KMS can find the pre-shared key by other means. 933 The last payload SHALL be a Verification payload (V) where the 934 authentication key (auth_key) is derived from the pre-shared key 935 shared by the Responder and the KMS. The MAC SHALL cover the entire 936 RESOLVE_INIT_PSK message as well as the identities of the involved 937 parties (see Section 5.5 for the exact definition). 939 4.2.3.3. Components of the RESOLVE_INIT_PK Message 941 The identity IDRr and certificate CERTr SHOULD be included, but they 942 MAY be left out when it can be expected that the KMS can obtain the 943 certificate in some other manner. If a certificate chain is to be 944 provided, each certificate in the chain SHOULD be included in a 945 separate CERT payload. The Responder's certificate MUST come first. 946 Each following certificate MUST directly certify the one preceding 947 it. 949 PKE contains the encrypted envelope key: PKE = E(PKkms, env_key). It 950 is encrypted using PKkms. If the KMS possesses several public keys, 951 the Responder can indicate the key used in the CHASH payload. 953 SIGNr is a signature covering the entire RESOLVE_INIT_PK message, 954 using the Responder's signature key (see Section 5.5 for the exact 955 definition). 957 4.2.3.4. Processing the RESOLVE_INIT Message 959 If the KMS can verify the integrity of the received message, the 960 message can be correctly parsed, and the Responder is authorized to 961 resolve the ticket, the KMS MUST send a RESOLVE_RESP message. 962 Unexpected payloads in the RESOLVE_INIT message SHOULD be ignored. 963 Errors are handled as described in Section 5.4. 965 4.2.3.5. Components of the RESOLVE_RESP Message 967 The version, PRF func and CSB ID, #CS, and CS ID map type fields in 968 the HDR payload SHALL be identical to the corresponding fields in the 969 RESOLVE_INIT message. The V flag has no meaning in this context. It 970 SHALL be set to '0' by the KMS and ignored by the Responder. 972 If one of the NTP timestamp types is used, the KMS SHALL generate a 973 fresh timestamp value (unlike [RFC3830]), which may be used for clock 974 synchronization. If the COUNTER timestamp type (see Section 6.6 of 975 [RFC3830]) is used, the timestamp value MAY be equal to the one in 976 the RESOLVE_INIT message. 978 The KEMAC payload SHALL use the NULL authentication algorithm, as a 979 MAC is included in the V payload. Depending on the type of 980 RESOLVE_INIT message, either the pre-shared key or the envelope key 981 SHALL be used to derive the encr_key (and salt_key). Depending on 982 the encryption algorithm, the salting key may go into the IV (see 983 [RFC3830]). The KEMAC SHALL include a MPK (MPKi), used as a pre- 984 shared key to protect the messages in the Ticket Transfer exchange. 985 The KEMAC is hence constructed as follows: 987 KEMAC = E(encr_key, MPKi || [MPKr'] || {TEK|TGK|GTGK}) 989 If key forking (see Section 5.1.1) is used (determined by the I flag 990 in the Ticket Policy) a second MPK (MPKr') SHALL be included in the 991 KEMAC. Then MPKi SHALL be used to verify the TRANSFER_INIT message 992 and MPKr' SHALL be used to protect the TRANSFER_RESP message. The 993 KMS SHALL also fork the MPKr and the TGKs. The modifier used to 994 derive the forked keys SHALL be included in the IDRr and RANDRkms 995 payloads, where IDRr is the identity of the endpoint that answered 996 and RANDRkms is a fresh (pseudo-)random byte string generated by the 997 KMS. The reason that the KMS MAY adjust the Responder's identity is 998 so that it matches an identity encoded in the ticket. 1000 The last payload SHALL be a Verification payload (V). Depending on 1001 the type of RESOLVE_INIT message, either the pre-shared key or the 1002 envelope key SHALL be used to derive the auth_key. The MAC SHALL 1003 cover the entire RESOLVE_RESP message as well as the RESOLVE_INIT 1004 message (see Section 5.5 for the exact definition). 1006 4.2.3.6. Processing the RESOLVE_RESP Message 1008 If the Responder can verify the integrity of the received message and 1009 the message can be correctly parsed, the Responder MUST verify the 1010 TRANSFER_INIT message with the MPKi received from the KMS. 1011 Unexpected payloads in the RESOLVE_RESP message SHOULD be ignored. 1012 Errors are handled as described in Section 5.4. 1014 5. Key Management Functions 1016 5.1. Key Derivation 1018 For all messages in the Ticket Request and Ticket Resolve exchanges, 1019 the keys used to protect the MIKEY messages are derived from the pre- 1020 shared key or the envelope key. As crypto sessions SHALL NOT be 1021 handled, further keying material (i.e. TEKs) does not have to be 1022 derived. 1024 In the Ticket Transfer exchange, the keys used to protect the MIKEY 1025 messages are derived from a MPK. If key forking is used, the KMS and 1026 the Initiator SHALL fork the MPKr and the TGKs (encoded in the 1027 ticket) based on a modifier, and different MPKs (MPKi and MPKr') 1028 SHALL be used to protect the TRANSFER_INIT and TRANSFER_RESP 1029 messages. In addition, the Responder MAY generate a RAND used to 1030 give Responder key freshness guarantee. 1032 The key hierarchy and its dependencies on TRANSFER_INIT message 1033 contents for the case without key forking and RANDRr are illustrated 1034 in Figure 4. The KEMAC shown is the KEMAC sent from the KMS to the 1035 Initiator and the Responder. The illustrated key derivations are 1036 done by the Initiator and the Responder. 1038 +------+------------------+-----+------+ 1039 KEMAC | MPKi |..................| TGK | SALT | 1040 +--+---+------------------+--+--+--+---+ 1041 | MPKi | | 1042 v | | 1043 CSB ID ----- auth_key ------ | | 1044 +---------->| PRF |------------>| AUTH | | | 1045 | ----- ------ | | 1046 | ^ MAC | | | 1047 | | RAND v | | 1048 +--+--+------+----+---+--+--------+--+---+ | | 1049 TRANSFER_INIT | HDR |......| RANDRi |..| TICKET |..| V | | | 1050 +--+--+------+----+---+--+--------+--+---+ | | 1051 | | RAND | | 1052 | v | | 1053 | CS ID ----- TGK | | 1054 +---------->| PRF |<---------------------+ | 1055 ----- | 1056 | TEK SALT | 1057 v v 1058 --------------------------------------- 1059 | Security Protocol e.g. SRTP | 1060 --------------------------------------- 1062 Figure 4: Key hierarchy without key forking and RANDRr 1064 The key hierarchy and its dependencies on TRANSFER_RESP message 1065 contents for the case with key forking and RANDRr are illustrated in 1066 Figure 5. The KEMAC shown is the KEMAC sent from the KMS to the 1067 Initiator. MOD is the modifier (IDRr, RANDRkms). The two key 1068 derivations that produce forked keys are done by the Initiator and 1069 the KMS, and the remaining two key derivations are done by the 1070 Initiator and the Responder. The random value RANDRi from the 1071 TRANSFER_INIT message is used as input to the derivation of the 1072 auth_key and may be used as input to the derivation of the TEK, but 1073 this is omitted from the figure. The protection of the TRANSFER_INIT 1074 message is done as in Figure 4. 1076 +------+--------------------------+-----+------+ 1077 KEMAC | MPKr |..........................| TGK | SALT | 1078 +--+---+--------------------------+--+--+--+---+ 1079 | MPKr | | 1080 v | | 1081 ----- MPKr' | | 1082 | PRF |-------+ TGK | | 1083 ----- | | | 1084 ^ v | | 1085 CSB ID | ----- auth_key ------ | | 1086 +---------)------>| PRF |--------->| AUTH | | | 1087 | | ----- ------ | | 1088 | | ID Data ^ MAC | | | 1089 | | RAND | RAND v | | 1090 +--+--+---+--+--+---+---+----+----------+---+ | | 1091 TRANSFER_RESP | HDR |...| MOD |...| RANDRr |..........| V | | | 1092 +--+--+---+--+--+---+---+----+----------+---+ | | 1093 | | | RAND v | 1094 | | | ID Data ----- | 1095 | +----------)------------------>| PRF | | 1096 | | RAND ----- | 1097 | v | | 1098 | CS ID ----- TGK' | | 1099 +---------------->| PRF |<------------------+ | 1100 ----- | 1101 | TEK SALT | 1102 v v 1103 --------------------------------------- 1104 | Security Protocol e.g. SRTP | 1105 --------------------------------------- 1107 Figure 5: Key hierarchy with key forking and RANDRr 1109 The labels in the key derivations SHALL NOT include entire RANDR 1110 payloads, only the fields RAND length and RAND from the corresponding 1111 payload. 1113 5.1.1. Deriving Forked Keys 1115 When key forking is used (determined by the I flag in the Ticket 1116 Policy), the MPKr and TGKs (encoded in the ticket) SHALL be forked. 1117 The TEKs and GTGKs (Group TGKs), however, SHALL NOT be forked. This 1118 key forking is done by the KMS and the Initiator using the PRF 1119 (Pseudo-Random Function) indicated in the Ticket Policy. The 1120 parameters for the default PRF are: 1122 inkey: : MPKr or TGK 1123 inkey_len : bit length of the inkey 1124 label : constant || 0xFF || 0xFFFFFFFF || 0x00 || 1125 length ID Data || ID Data || length RANDRkms || RANDRkms 1126 outkey_len : desired bit length of the outkey (MPKr', TGK') 1128 where the ID Data field is taken from the IDRr payload sent in the 1129 RESOLVE_RESP and TRANSFER_RESP messages. Length ID Data is the 1130 length of the ID Data field in bytes as a 16-bit unsigned integer. 1131 Length RANDRkms is the length of RANDRkms in bytes as an 8-bit 1132 unsigned integer. The constant depends on the derived key type as 1133 summarized below. 1135 Derived key | Constant 1136 ------------+----------- 1137 MPKr' | 0x2B288856 1138 TGK' | 0x1512B54A 1140 Table 5.1: Constants for forking key derivation 1142 The constants are taken from the decimal digits of e as described in 1143 [RFC3830]. 1145 5.1.2. Deriving Keys from an Envelope/Pre-Shared Key/MPK 1147 This derivation is used to form the keys used to protect the MIKEY 1148 messages. For the Ticket Request and Ticket Resolve exchanges, the 1149 keys used to protect the MIKEY messages are derived from the pre- 1150 shared key or the envelope key. For the Ticket Transfer exchange, 1151 the keys are derived from a MPK. If key forking is used, different 1152 MPKs (MPKi and MPKr') SHALL be used to protect the TRANSFER_INIT and 1153 TRANSFER_RESP messages. The initial messages SHALL be protected with 1154 the keys derived using the parameters given below. 1156 inkey: : envelope key, pre-shared key, or MPKi 1157 inkey_len : bit length of the inkey 1158 label : constant || 0xFF || CSB ID || 0x01 || 1159 length RANDRi || RANDRi 1160 outkey_len : desired bit length of the output key (encr_key, 1161 auth_key, salt_key) 1163 The parameters for the response messages are given below. 1165 inkey: : envelope key, pre-shared key, MPKi, or MPKr' 1166 inkey_len : bit length of the inkey 1167 label : constant || 0xFF || CSB ID || 0x02 || 1168 length RANDRi || RANDRi || length RANDRr || [RANDRr] 1169 outkey_len : desired bit length of the output key (encr_key, 1170 auth_key, salt_key) 1172 The constant depends on the derived key type as defined in Section 1173 4.1.4 of [RFC3830]. The 32-bit CSB ID field is taken from the HDR 1174 payload. RANDRr SHALL be included in the derivation of the keys used 1175 to protect TRANSFER_RESP if the Ticket Policy determines that it 1176 shall be present in the TRANSFER_RESP message (G flag). Length 1177 RANDRi is the length of RANDRi in bytes as an 8-bit unsigned integer, 1178 and Length RANDRr is the length of RANDRr in bytes as an 8-bit 1179 unsigned integer. If RANDRr is omitted, length RANDRr SHALL be 0. 1181 5.1.3. Deriving Keys from a TGK/GTGK 1183 This only affects the Ticket Transfer exchange. In the following, we 1184 describe how keying material is derived from a TGK/GTGK. If key 1185 forking is used, any TGK encoded in the ticket SHALL be forked, and 1186 the forked key TGK' SHALL be used. The key derivation method SHALL 1187 be executed using the PRF indicated in the HDR payload. The 1188 parameters for the default PRF are given below. 1190 inkey: : TGK, TGK', or GTGK 1191 inkey_len : bit length of the inkey 1192 label : constant || CS ID || 0xFFFFFFFF || 0x03 || 1193 length RANDRi || [RANDRi] || length RANDRr || [RANDRr] 1194 outkey_len : bit length of the outkey (TEK, encr_key, 1195 auth_key, salt_key) 1197 The constant depends on the derived key type as defined in Section 1198 4.1.3 of [RFC3830]. If a salting key is present in the key data sub- 1199 payload, a security protocol in need of a salting key SHALL use this 1200 salting key and a new salting key SHALL NOT be derived. The 8-bit CS 1201 ID field is given by the CS ID map info field in the HDR payload. 1202 RANDRi SHALL be included if the Ticket Policy determines that it 1203 shall be used (H flag). RANDRr SHALL be included if the Ticket 1204 Policy determines that it shall be present in the TRANSFER_RESP 1205 message (G flag). Length RANDRi is the length of RANDRi in bytes as 1206 an 8-bit unsigned integer, and Length RANDRr is the length of RANDRr 1207 in bytes as an 8-bit unsigned integer. If RANDRi or RANDRr is 1208 omitted the corresponding length SHALL be 0. Note that at least one 1209 of RANDRi and RANDRr MUST be used. 1211 5.2. CSB Updating 1213 Similar to [RFC3830], MIKEY-TICKET provides a means of updating the 1214 CSB (Crypto Session Bundle), e.g. transporting new TEK/TGK/GTGK or 1215 adding new crypto sessions. The CSB updating is done by executing 1216 the Ticket Transfer exchange again, e.g. before a TEK expires or when 1217 a new crypto session is needed. The CSB updating can be started by 1218 either the Initiator or the Responder. 1220 Initiator Responder 1222 TRANSFER_INIT = ----> 1223 HDR, T, [IDRi], [IDRr], 1224 {SP}, [KEMAC], V < - - TRANSFER_RESP = 1225 HDR, T, [IDRr], 1226 {SP}, [KEMAC], V 1228 Responder Initiator 1230 TRANSFER_INIT = ----> 1231 HDR, T, [IDRr], [IDRi], 1232 {SP}, [KEMAC], V < - - TRANSFER_RESP = 1233 HDR, T, [IDRi], 1234 {SP}, [KEMAC], V 1236 The new message exchange MUST use the same CSB ID as the initial 1237 exchange, but MUST use new timestamps. The crypto sessions 1238 negotiation (#CS field, CS ID map info field, and SP payloads) are 1239 handled as in the initial exchange. In the TRANSFER_INIT message the 1240 V flag SHALL be used to indicate whether a response message is 1241 expected or not. The ticket and other static payloads that were 1242 provided in the initial exchange MUST NOT be included. New RANDs 1243 MUST NOT be included in the message exchange (the RANDs will only 1244 have effect in the initial exchange). The reason that new RANDs 1245 SHALL NOT be used is that if several TGKs are used, the peers would 1246 need to keep track of which RANDs to use for each TGK. This adds 1247 unnecessary complexity. Both messages SHALL be protected with the 1248 same keys (derived from MPKi or MPKr') that protected the last 1249 message (TRANSFER_INIT or TRANSFER_RESP) in the initial exchange. 1251 New keying material MAY be sent in a KEMAC payload. If indicated by 1252 the Ticket Policy (L and M flags), KEMAC payloads SHALL NOT be 1253 included. The Responder MUST provide a session key for each crypto 1254 session, which the Initiator has not supplied a session key for. The 1255 KEMAC SHALL use the NULL authentication algorithm, as a MAC is 1256 included in the V payload. The encr_key (and salt_key) SHALL be 1257 derived from the MPK (MPKi or MPKr'). Depending on the encryption 1258 algorithm, the salting key may go into the IV (see [RFC3830]). If a 1259 new TGK is exchanged, it SHALL NOT be forked. The KEMAC is hence 1260 constructed as follows: 1262 KEMAC = E(encr_key, (TEK|TGK|GTGK)) 1264 5.3. Ticket Reuse 1266 MIKEY-TICKET includes features aiming to offload the KMS from 1267 receiving ticket requests. One such feature is that tickets may be 1268 reused. This means that a user may request a ticket for media 1269 sessions with another user and then under the ticket's validity 1270 period use this ticket to protect several media sessions with that 1271 user. 1273 When reusing a ticket that has been used in a previous Ticket 1274 Transfer exchange, a new Ticket Transfer exchange is executed. The 1275 new exchange MUST use a new CSB ID, a new timestamp, and new RANDs 1276 (RANDRi, RANDRr). If the Responder has resolved the ticket before, 1277 the Responder does not need to resolve the ticket again. In that 1278 case, the same modifier (IDRr, RANDRkms) SHALL be used. If the 1279 Ticket Policy forbids reuse (J flag), the ticket MUST NOT be reused. 1280 Note that such reuse cannot be detected by a stateless KMS. When 1281 group keys are used, ticket reuse leaves the Initiator responsible to 1282 ensure that group membership has not changed since the ticket was 1283 last used. (Otherwise, unauthorized responders may gain access to 1284 the group communication.) Thus, if group dynamics are difficult to 1285 verify, the Initiator SHOULD NOT initiate ticket reuse. 1287 When key forking is used, only the user that requested the ticket has 1288 access to the encoded master keys (MPKr, TGKs). Because of this, no 1289 one else can initiate a Ticket Transfer exchange using the ticket. 1291 5.4. Error Handling 1293 If a fatal error occurs during the parsing of a message, the message 1294 SHOULD be discarded, and an Error message SHOULD be sent to the other 1295 party (Initiator, Responder, KMS). If a failure is due to the 1296 inability to authenticate the peer, the message SHALL be discarded, 1297 the Error message is OPTIONAL, and the caveats in Section 5.1.2 of 1298 [RFC3830] apply. Error messages may be used to report errors in both 1299 initial and response messages. 1301 In the Ticket Request and Ticket Resolve exchanges, the Error message 1302 MAY be authenticated with a MAC or a signature. The Error message is 1303 hence constructed as follows: 1305 Error message = HDR, T, (ERR), [V|SIGNx] 1307 where x is in the set {i, r, kms} (Initiator, Responder, KMS). 1309 In the Ticket Transfer exchange, the Error message MAY be 1310 authenticated with a MAC. If the suggested security policies are not 1311 supported, the Error message SHOULD include the supported parameters. 1313 The Error message is hence constructed as follows: 1315 Error message = HDR, T, (ERR), {SP}, [V] 1317 In Error messages, the version, PRF func, and CSB ID fields in the 1318 HDR payload SHALL be identical to the corresponding fields in the 1319 message where the error occurred. The V field SHALL be set to '0' 1320 and be ignored. 1322 If one of the NTP timestamp types is used, a fresh timestamp value 1323 SHALL be used. If the COUNTER timestamp type (see Section 6.6 of 1324 [RFC3830]) is used, the timestamp value MAY be equal to the one in 1325 the message where the error occurred. 1327 The MAC/Signature in the V/SIGN payloads covers the entire Error 1328 message, except the MAC/Signature field itself. The auth_key SHALL 1329 be the same as in the message where the error occurred. 1331 5.5. MAC/Signature Coverage 1333 The MAC/Signature in the V/SIGN payloads covers the entire MIKEY 1334 message, except the MAC/Signature field itself. For initial 1335 messages, the identities (not whole payloads) of the parties involved 1336 MUST directly follow the MIKEY message in the Verification MAC/ 1337 Signature calculation. Note that in the Transfer Exchange, 1338 Identity_r in TRANSFER_RESP (e.g. user1@example.com) MAY differ from 1339 that appearing in TRANSFER_INIT (e.g. IT-support@example.com). For 1340 response messages, the entire initial message (including the MAC/ 1341 Signature field) MUST directly follow the MIKEY message in the 1342 Verification MAC/Signature calculation (the identities are implicitly 1343 covered as they are covered by the initial message's MAC/Signature). 1345 Message type | MAC/Signature coverage 1346 --------------+-------------------------------------------- 1347 REQUEST_INIT | REQUEST_INIT || Identity_i || Identity_kms 1348 REQUEST_RESP | REQUEST_RESP || REQUEST_INIT 1349 TRANSFER_INIT | TRANSFER_INIT || Identity_i || Identity_r 1350 TRANSFER_RESP | TRANSFER_RESP || TRANSFER_INIT 1351 RESOLVE_INIT | RESOLVE_INIT || Identity_r || Identity_kms 1352 RESOLVE_RESP | RESOLVE_RESP || RESOLVE_INIT 1353 Error message | Error message 1355 Table 5.2: MAC/Signature coverage 1357 6. Payload Encoding 1359 This section does not describe all the payloads that are used in the 1360 new message types. It describes in detail the new TR, IDR, RANDR, 1361 TP, and TICKET payloads. For the other payloads, only the additions 1362 and changes compared to [RFC3830] are described. For a detailed 1363 description of the other MIKEY payloads, see [RFC3830]. Note that 1364 the fields with variable length are byte aligned and not 32-bit 1365 aligned. 1367 6.1. Common Header Payload (HDR) 1369 For the Common Header Payload, new values are added to the Data Type, 1370 Next Payload, PRF func, and CS ID map type name spaces. 1372 * Data Type (8 bits): describes the type of message. 1374 Data Type | Value | Comment 1375 -----------------+-------+------------------------------------- 1376 REQUEST_INIT_PSK | TBD1 | Ticket request initial message (PSK) 1377 REQUEST_INIT_PK | TBD2 | Ticket request initial message (PK) 1378 REQUEST_RESP | TBD3 | Ticket request response message 1379 | | 1380 TRANSFER_INIT | TBD4 | Ticket transfer initial message 1381 TRANSFER_RESP | TBD5 | Ticket transfer response message 1382 | | 1383 RESOLVE_INIT_PSK | TBD6 | Ticket resolve initial message (PSK) 1384 RESOLVE_INIT_PK | TBD7 | Ticket resolve initial message (PK) 1385 RESOLVE_RESP | TBD8 | Ticket resolve response message 1387 Table 6.1: Data Type (Additions) 1389 * Next Payload (8 bits): identifies the payload that is added after 1390 this payload. 1392 Next Payload | Value | Section 1393 -------------+-------+-------- 1394 TR | TBD9 | 6.4 1395 IDR | TBD10 | 6.6 1396 RANDR | TBD11 | 6.8 1397 TP | TBD12 | 6.10 1398 TICKET | TBD13 | 6.10 1400 Table 6.2: Next Payload (Additions) 1402 * V (1 bit): flag to indicate whether a response message is expected 1403 ('1') or not ('0'). It MUST be set to '0' and ignored in all 1404 messages except TRANSFER_INIT messages used for CSB updating (see 1405 Section 5.2). 1407 * PRF func (7 bits): indicates the PRF function that has been/will 1408 be used for key derivation. Besides the PRFs already defined in 1409 [RFC3830] the following additional PRF may be used. 1411 PRF func | Value 1412 -----------------+------ 1413 PRF-HMAC-SHA-256 | TBD14 1415 Table 6.3: PRF func (Additions) 1417 The new PRF SHALL be constructed as described in Section 4.1.2 of 1418 [RFC3830] with the differences that HMAC-SHA-256 (see Section 6.2) 1419 SHALL be used instead of HMAC-SHA-1 and the value 256 SHALL be 1420 used instead of 160. This corresponds to the full output length 1421 of SHA-256. 1423 * #CS (8 bits): indicates the number of crypto sessions in the CS ID 1424 map info. 1426 * CS ID map type (8 bits): specifies the method of uniquely mapping 1427 crypto sessions to the security protocol sessions. In the Ticket 1428 Transfer exchange the new GENERIC-ID map type, which is intended 1429 to eliminate the limitations with the existing SRTP-ID map type, 1430 SHOULD be used. The map type SRTP-ID SHALL NOT be used. 1432 CS ID map type | Value 1433 ---------------------- 1434 GENERIC-ID | TBD15 1436 Table 6.4: CS ID map type (Additions) 1438 * CS ID map info (variable length): identifies and maps the crypto 1439 sessions to the security protocol sessions for which SAs should be 1440 created. 1442 6.1.1. The GENERIC-ID map type 1444 For the GENERIC-ID map type, the CS ID map info consists of #CS 1445 number of blocks, each mapping policies, session data (e.g. SSRC), 1446 and key to a specific crypto session. 1448 0 1 2 3 1449 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 1450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1451 ! CS ID ! Prot type !S! #P ! Ps (OPTIONAL) ~ 1452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1453 ! Session Data Length ! Session Data (OPTIONAL) ~ 1454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1455 ! SPI Length ! SPI (OPTIONAL) ~ 1456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1458 * CS ID (8 bits): defines the CS ID to be used for the crypto 1459 session. 1461 * Prot Type (8 bits): defines the security protocol to be used for 1462 the crypto session. Allowed values are the ones defined for the 1463 Prot type field in the SP payload (see Section 6.10 of [RFC3830]). 1465 * S (1 bit): flag that MAY be used by the Session Data. 1467 * #P (7 bits): indicates the number of security policies provided 1468 for the crypto session. In an initial message, if #P = 0, a 1469 security policy MUST be provided in the response message, and if 1470 #P > 0, one of the suggested policies MUST be chosen in the 1471 response message. In response messages #P SHALL always be exactly 1472 1. 1474 * Ps (variable length): lists the policies for the crypto session. 1475 It SHALL contain exactly #P policies, each having the specified 1476 Prot type. 1478 0 1 2 3 1479 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 1480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1481 ! Policy_no_1 ! Policy_no_2 ! ... ! Policy_no_#P ! 1482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1484 * Policy_no_i (8 bits): a policy_no that corresponds to the 1485 policy_no of a SP payload. In response messages, the policy_no 1486 may refer to a SP payload in the initial message. 1488 * Session Data Length (16 bits): the length of Session Data (in 1489 bytes). For the Prot type SRTP, Session Data MAY be omitted in 1490 the initial message (length = 0), but it MUST be provided in the 1491 response message. 1493 * Session Data (variable length): contains session data for the 1494 crypto session. The type of Session Data depends on the specified 1495 Prot Type. The Session Data for the Prot type SRTP is defined 1496 below. The S flag is used to indicate whether the ROC and SEQ 1497 fields are provided ('1') or if they are omitted ('0'). 1499 0 1 2 3 1500 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 1501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1502 ! SSRC ! 1503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1504 ! ROC (OPTIONAL) ! 1505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1506 ! SEQ (OPTIONAL) ! 1507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1509 * SSRC (32 bits): specifies the SSRC that MUST be used for the 1510 crypto session. Note that unlike [RFC3830], a SSRC field set 1511 to zero has no special meaning. 1513 * ROC (32 bits): current/initial rollover counter. If the 1514 session has not started, this field is set to 0. 1516 * SEQ (16 bits): current/initial sequence number. 1518 * SPI Length (8 bits): the length of SPI (in bytes). SPI MAY be 1519 omitted in the initial message (length = 0), but it MUST be 1520 provided in the response message. 1522 * SPI (variable length): the SPI (or MKI) corresponding to the 1523 session key to (initially) be used for the crypto session. This 1524 does not exclude other keys to be used. All keys MUST belong to 1525 the crypto session bundle. 1527 6.2. Key Data Transport Payload (KEMAC) 1529 For the KEMAC payload, new encryption and authentication algorithms 1530 are defined. 1532 * Encr alg (8 bits): besides the algorithms already defined in 1533 [RFC3830], this specification defines the following additional 1534 encryption algorithm that may be used to encrypt the Encr data 1535 field. 1537 Encr alg | Value | Comment 1538 -----------+-------+--------------------------- 1539 AES-CM-256 | TBD16 | AES-CM using a 256-bit key 1540 Table 6.5: Encr alg (Additions) 1542 The new encryption algorithm is defined as described in Section 1543 4.2.3 of [RFC3830] with the only difference that a 256-bit key 1544 SHALL be used. 1546 * MAC alg (8 bits): besides the algorithms already defined in 1547 [RFC3830], this specification defines that the following 1548 additional authentication algorithm may be used. 1550 MAC alg | Value | Length (bits) 1551 -----------------+-------+-------------- 1552 HMAC-SHA-256-256 | TBD17 | 256 1554 Table 6.6: MAC alg (Additions) 1556 The new authentication algorithm is Hash-based Message 1557 Authentication Code (HMAC) [RFC2104] in conjunction with SHA-256 1558 [FIPS.180-3]. It SHALL be used with a 256-bit authentication key. 1560 6.2.1. Key Data Sub-Payload 1562 For the key data sub-payload, new types of keys are defined. The 1563 Group TGK (GTGK) is used as a regular TGK, with the difference that 1564 it SHALL NOT be forked. It is intended to enable the establishment 1565 of a group TGK when key forking is used. The MIKEY Protection Key 1566 (MPK) is used to protect the MIKEY messages in the Ticket Transfer 1567 exchange. The MPK is used as the pre-shared key in the pre-shared 1568 key method of [RFC3830], it is however not known by the Responder 1569 before the ticket has been resolved. 1571 A SPI (or MKI) MUST be specified for each key (see Section 6.13 of 1572 [RFC3830]). 1574 * Type (4 bits): indicates the type of key included in the payload. 1576 Type | Value | Comments 1577 ----------+-------+--------------------- 1578 GTGK | TBD23 | Group TGK 1579 GTGK+SALT | TBD24 | Group TGK + SALT 1580 MPK | TBD25 | MIKEY Protection Key 1582 Table 6.7: Key Data Type (Additions) 1584 6.3. Timestamp Payload (T) 1586 For the timestamp payload, a new type of timestamp is defined. The 1587 new type is intended to be used when defining validity periods, where 1588 fractions of seconds seldom matter. The NTP-UTC-32 string contain 1589 four bytes, in the same format as the first four bytes in the NTP 1590 timestamp format, defined in [RFC4330]. This represents the number 1591 of seconds since 0h on 1 January 1900 with respect to the Coordinated 1592 Universal Time (UTC). On 7 February 2036 the time value will 1593 overflow. [RFC4330] describes a procedure to extend the time to 2104 1594 and this procedure is MANDATORY to support. 1596 * TS Type (8 bits): specifies the timestamp type used. 1598 TS Type | Value | Length of TS value 1599 -----------+-------+------------------- 1600 NTP-UTC-32 | TBD18 | 32 bits 1602 Table 6.8: TS Type (Additions) 1604 NTP-UTC-32 SHALL be padded to a 64-bit NTP-UTC timestamp (with zeroes 1605 in the fractional second part) when used as input for a PRF requiring 1606 a 64-bit timestamp. 1608 6.4. Timestamp Payload with Role Indicator (TR) 1610 The TR payload uses all the fields from the standard timestamp 1611 payload (T) but expands it with a new field describing the role of 1612 the timestamp. Whereas the TS Type describes the type of the TS 1613 Value, the TS Role describes the meaning of the timestamp itself. 1614 The TR payload is intended to eliminate ambiguity when a MIKEY 1615 message contains several timestamp payloads (e.g. in the Ticket 1616 Policy). 1618 0 1 2 3 1619 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 1620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1621 ! Next Payload ! TS Role ! TS Type ! TS Value ~ 1622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1624 * TS Role (8 bits): specifies the sort of timestamp. 1626 TS Role | Value 1627 -------------------------------+------ 1628 Time of issue (TRi) | 1 1629 Start of validity period (TRs) | 2 1630 End of validity period (TRe) | 3 1631 Rekeying interval (TRr) | 4 1633 Table 6.9: TS Role 1635 6.5. ID Payload (ID) 1637 For the ID payload, a new ID Type byte string is defined. The byte 1638 string type is intended to be used when the ID payload is used to 1639 identify a pre-shared key. Contrary to the previously defined ID 1640 Types (URI, NAI), the byte string does not have any encoding rules. 1642 * ID Type (8 bits): specifies the identifier type used. 1644 ID Type | Value 1645 ------------+------ 1646 Byte string | TBD19 1648 Table 6.10: ID Type (Additions) 1650 6.6. ID Payload with Role Indicator (IDR) 1652 The IDR payload uses all the fields from the standard identity 1653 payload (ID) but expands it with a new field describing the role of 1654 the ID payload. Whereas the ID Type describes the type of the ID 1655 Data, the ID Role describes the meaning of the identity itself. The 1656 IDR payload is intended to eliminate ambiguity when a MIKEY message 1657 contains several identity payloads. The IDR payload MUST be used 1658 instead of the ID payload in all MIKEY-TICKET messages. 1660 0 1 2 3 1661 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 1662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1663 ! Next Payload ! ID Role ! ID Type ! ID len 1664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1665 ID len (cont) ! ID Data ~ 1666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1668 * ID Role (8 bits): specifies the sort of identity. 1670 ID Role | Value 1671 ------------------------+------ 1672 Initiator (IDRi) | 1 1673 Responder (IDRr) | 2 1674 KMS (IDRkms) | 3 1675 Pre-Shared Key (IDRpsk) | 4 1676 Application (IDRapp) | 5 1678 Table 6.11: ID Role 1680 IDRapp is intended to specify the authorized Application IDs (see 1681 Section 5.1.3 and Section 6.10) 1683 6.7. Cert Hash Payload (CHASH) 1685 * Hash func (8 bits): besides the algorithms already defined in 1686 [RFC3830], this specification defines that the following hash 1687 function algorithm may be used. 1689 Hash func | Value | Hash Length (bits) 1690 ----------+-------+------------------- 1691 SHA-256 | TBD20 | 256 1693 Table 6.12: Hash func (Additions) 1695 The SHA-256 hash function is defined in [FIPS.180-3]. 1697 6.8. RAND payload with Role Indicator (RANDR) 1699 The RANDR payload uses all the fields from the standard RAND payload 1700 (RAND) but expands it with a new field describing the role (the 1701 generating entity) of the RAND. The RANDR payload is intended to 1702 eliminate ambiguity when a MIKEY message contains several RAND 1703 payloads. 1705 0 1 2 3 1706 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 1707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1708 ! Next Payload ! RAND Role ! RAND length ! RAND ~ 1709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1711 * RAND Role (8 bits): specifies the entity that generated the RAND. 1713 RAND Role | Value 1714 -------------------+------ 1715 Initiator (RANDRi) | 1 1716 Responder (RANDRr) | 2 1717 KMS (RANDRkms) | 3 1719 Table 6.13: RAND Role 1721 6.9. Error Payload (ERR) 1723 For the key data sub-payload, new types of errors are defined. 1725 * Error no (8 bits): indicates the type of error that was 1726 encountered. 1728 Error no | Value | Comments 1729 ---------------+-------+---------------------------- 1730 Invalid TICKET | TBD21 | Ticket Type not supported 1731 Invalid TPpar | TBD22 | TP parameters not supported 1733 Table 6.14: Error no (Additions) 1735 6.10. Ticket Policy Payload (TP) / Ticket Payload (TICKET) 1737 Note that the Ticket Policy Payload (TP) and the Ticket Payload 1738 (TICKET) are two different payloads (having different payload 1739 identifiers). However, as they share much of the payload structure, 1740 they are described in the same section. 1742 The Ticket Policy payload contains a desired Ticket Policy and does 1743 not include the Ticket Data length or Ticket Data fields. The ticket 1744 payload contains the granted Ticket Policy as well as Ticket Data 1745 (the default ticket type is defined in Appendix A). The Ticket 1746 Policy contains information intended for all parties involved whereas 1747 the Ticket Data is only intended for the party that resolves the 1748 ticket. The Ticket Type provided in the Ticket Data is indicated in 1749 the Ticket Policy. 1751 Note that the flags are not independent; NOT D implies L, G implies 1752 F, NOT G implies H, NOT H implies G, I implies E, I implies F, K 1753 implies D, and M implies F. 1755 0 1 2 3 1756 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 1757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1758 ! Next Payload ! Ticket Type ! Subtype ! 1759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1760 ! Version ! PRF Func !D!E!F!G!H!I!J!K!L!M!N!O! Res ! 1761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1762 ! First Payload ! TP Data length ! TP Data ~ 1763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1764 ! Ticket Data length ! Ticket Data (TD) ~ 1765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1767 * Next Payload (8 bits): identifies the payload that is added after 1768 this payload. 1770 * Ticket Type (16 bits): specifies the Ticket Type used. 1772 Ticket Type | Value | Comments 1773 ------------------+-------+--------------------------- 1774 MIKEY Base Ticket | 1 | Defined in Appendix A 1775 3GPP Base Ticket | 2 | Used and specified by 3GPP 1777 Table 6.15: Ticket Type 1779 Subtype = 0x01 and Version = 0x01 refers to MIKEY Base Ticket as 1780 defined in this document. 1782 * Subtype (8 bits): specifies the ticket subtype used. 1784 * Version (8 bits): specifies the ticket subtype version used. 1786 * PRF Func (7 bits): specifies the PRF that SHALL be used for key 1787 forking. 1789 * D (1 bit): flag to indicate whether the ticket was generated by 1790 the KMS ('1') or by the Initiator ('0'). 1792 * E (1 bit): flag to indicate whether the Ticket Resolve exchange is 1793 MANDATORY ('1') or if the Responder MAY resolve the ticket ('0'). 1795 * F (1 bit): flag to indicate whether the TRANSFER_RESP message 1796 SHALL be sent ('1') or if it SHALL NOT be sent ('0'). 1798 * G (1 bit): flag to indicate whether the Responder SHALL generate 1799 RANDRr ('1') or if the Responder SHALL NOT generate RANDRr ('0'). 1801 * H (1 bit): flag to indicate whether RANDRi SHALL be used when 1802 deriving keys from a TGK/GTGK ('1') or if RANDRi SHALL NOT be used 1803 ('0'). 1805 * I (1 bit): flag to indicate whether key forking SHALL be used 1806 ('1') or if key forking SHALL NOT be used ('0'). 1808 * J (1 bit): flag to indicate whether the ticket MAY be reused ('1') 1809 and therefore MAY be cached or if it SHALL NOT be reused ('0'). 1811 * K (1 bit): flag to indicate whether the KMS changed the desired 1812 Ticket Policy or the desired KEMAC ('1') or if it did not ('0'). 1813 In the TP payload, it SHALL be set to '0' by the Initiator and 1814 ignored by the KMS. 1816 * L (1 bit): flag to indicate whether the Initiator MAY supply 1817 session keys ('1') or if the Initiator SHALL NOT supply session 1818 keys ('0'). 1820 * M (1 bit): flag to indicate whether the Responder MAY supply 1821 session keys ('1') or if the Responder SHALL NOT supply session 1822 keys ('0'). 1824 * N (1 bit): flag to indicate whether an Initiator following this 1825 specification can initiate a TRANSFER_INIT message using the 1826 ticket ('1') or if additional processing is required ('0'). If 1827 the flag is set to ('0') the Initiator SHOULD follow the 1828 processing in the specification of the received Ticket Type. 1830 * O (1 bit): flag to indicate whether a Responder following this 1831 specification can process a TRANSFER_INIT message containing the 1832 ticket ('1') or if additional processing is required ('0'). If 1833 the flag is set to ('0') the Responder SHOULD follow the 1834 processing in the specification of the received Ticket Type. 1836 * Res (5 bits): reserved for future use. 1838 * First Payload (8 bits): identifies the first payload in TP Data. 1840 * TP Data length (16 bits): length of TP Data (in bytes). 1842 * TP Data (variable length): the TP Data SHALL be constructed as a 1843 MIKEY message. Unexpected payloads in the TP Data SHOULD be 1844 ignored. 1846 TP Data = 1847 [IDRkms], [IDRi], [TRs], [TRe], [TRr], [KEMAC], {IDRapp}, (IDRr) 1848 IDRkms contains the identity of a KMS that can resolve the ticket. 1850 IDRi contains the identity of the peer that requested or created 1851 the ticket. 1853 TRs is the start of the validity period. TRs SHALL be interpreted 1854 as being in the range 1968-2104 as described in [RFC4330]. An 1855 omitted TRs means that the validity period has no defined 1856 beginning. 1858 TRe is the end of the validity period. TRe SHALL be interpreted 1859 as being in the range 1968-2104 as described in [RFC4330]. An 1860 omitted TRe means that the validity period has no defined end. 1862 TRr indicates how often rekeying MUST be done. TS Type SHALL be 1863 NTP-UTC-32 and the time between two rekeyings SHALL NOT be longer 1864 than the number of seconds in the integer part of the timestamp. 1865 How the rekeying is done is implementation specific. 1867 The KEMAC payload may be used to indicate the number of requested 1868 keys and specify other key information (key type, key length, and 1869 KV (key validity) data). The KEMAC payload SHALL use the NULL 1870 encryption algorithm and the NULL authentication algorithm, as a 1871 MAC is included in the V payload. The KEMAC is hence constructed 1872 as follows: 1874 KEMAC = {TEK|TGK|GTGK} 1876 The Key Data fields SHALL be set to 0 by the Initiator and ignored 1877 by the KMS. The KEMAC SHALL NOT be present in the granted Ticket 1878 Policy. 1880 IDRapp is an identifier for an authorized application ID. The 1881 application IDs are implementation specific. If no IDRapp 1882 payloads are supplied, all application IDs are authorized. 1884 IDRr is the identity of a responder or a group of responders that 1885 are authorized to resolve the ticket. If there is more than one 1886 responder identity, each responder identity SHALL be included in a 1887 separate IDR payload. 1889 * Ticket Data length (16 bits): the length of the Ticket Data field 1890 (in bytes). Not present in the TP payload. 1892 * Ticket Data (variable length): contains the Ticket Data. Not 1893 present in the TP payload. 1895 7. Transport Protocols 1897 MIKEY messages are not tied to any specific transport protocols. In 1898 [RFC4567], extensions for SDP and RTSP to carry MIKEY messages (and 1899 therefore MIKEY-TICKET messages) are defined. The messages in the 1900 Ticket Transfer exchange (TRANSFER_INIT, TRANSFER_RESP) are 1901 preferably included in the session setup signaling (e.g. SIP INVITE 1902 and 200 OK). It may however not be suitable for the MIKEY-TICKET 1903 exchanges that do not establish keying material for media sessions 1904 (Ticket Request and Ticket Resolve) to be carried in SDP or RTSP. If 1905 SDP or RTSP is not used, the transport protocol needs to be defined. 1906 In [3GPP.33.328] it is defined how the Ticket Request and Ticket 1907 Resolve exchanges are carried over HTTP. 1909 8. Pre-Encrypted Content 1911 The default setting is that the KMS supplies the session keys 1912 (encoded in the ticket). This is not possible if the content is pre- 1913 encrypted (e.g. Video on Demand). In such use cases, the key 1914 exchange is typically reversed and MAY be carried out as follows. 1915 The Initiator sends a ticket without encoded session keys to the 1916 Responder in a TRANSFER_INIT message. The Responder has access to 1917 the TEKs used to protect the requested content, but may not be 1918 streaming the content. The Responder includes the TEK in the 1919 TRANSFER_RESP message, which is sent to the Initiator. 1921 +---+ +---+ 1922 | I | | R | 1923 +---+ +---+ 1924 TRANSFER_INIT 1925 ----------------------------------------------------------------> 1926 TRANSFER_RESP {KEMAC} 1927 <---------------------------------------------------------------- 1929 Figure 6: Distribution of pre-encrypted content 1931 9. Group Communication 1933 What has been discussed up to now can also be used for group 1934 communication. The MIKEY signaling for multi-party sessions can be 1935 centralized as illustrated in Figure 7. 1937 +---+ +---+ +---+ 1938 | A | | B | | C | 1939 +---+ +---+ +---+ 1940 Ticket Transfer 1941 <-------------------------------> Ticket Transfer 1942 <---------------------------------------------------------------> 1944 Figure 7: Centralized signaling around party A 1946 or decentralized as illustrated in Figure 8. 1948 +---+ +---+ +---+ 1949 | A | | B | | C | 1950 +---+ +---+ +---+ 1951 Ticket Transfer 1952 <-------------------------------> Ticket Transfer 1953 <-------------------------------> 1955 Figure 8: Decentralized signaling 1957 In the decentralized scenario, B's and C's identities SHALL be used 1958 in the second Ticket Transfer exchange. Independent of the how the 1959 MIKEY signaling is done, a group key may be used as session key. 1961 If a group key is used, the group key and session information may be 1962 pushed to all group members (similar to [RFC3830]), or distributed 1963 when requested (similar to [RFC4738]). If a TGK/GTGK is used as a 1964 group key, the same RANDs MUST be used to derive the session keys in 1965 all Ticket Transfer exchanges. Note also caveats with ticket reuse 1966 in group communication settings as discussed in Section 5.3. 1968 9.1. Key Forking 1970 When key forking is used, the MIKEY signaling MUST be centralized to 1971 the party that initially requested the ticket. Decentralized 1972 signaling does not work, as only the user that requested the ticket 1973 could initiate the Ticket Transfer exchange, see Section 5.3. 1975 Another consideration is that different users get different session 1976 keys if TGKs (encoded in the ticket) are used. 1978 10. Signaling Between Different KMSs 1980 A user can in general only be expected to have a trust relation with 1981 a single KMS. Different users might therefore use tickets issued by 1982 different KMSs using only locally known keys. Thus, if users with 1983 trust relations to different KMSs are to be able to establish a 1984 secure session with each other, the KMSs involved have to cooperate 1985 and there has to be a trust relation between them. The KMSs SHALL be 1986 mutually authenticated and signaling between them SHALL be integrity 1987 and confidentiality protected. The technical means for the inter-KMS 1988 security is however outside the scope of this specification. Under 1989 these assumptions, the following approach MAY be used. 1991 +---+ +---+ +-------+ +-------+ 1992 | I | | R | | KMS R | | KMS I | 1993 +---+ +---+ +-------+ +-------+ 1994 TRANSFER_INIT 1995 --------------------> RESOLVE_INIT 1996 - - - - - - - - - - -> RESOLVE_INIT 1997 - - - - - - - - - - -> 1998 RESOLVE_RESP 1999 RESOLVE_RESP <- - - - - - - - - - - 2000 TRANSFER_RESP < - - - - - - - - - - 2001 <-------------------- 2003 Figure 9: Routing of resolve messages 2005 If the Responder cannot directly resolve a ticket, the ticket SHOULD 2006 be included in a RESOLVE_INIT message sent to a KMS. If the 2007 Responder does not have a shared credential with the KMS that issued 2008 the ticket (KMS I) or if the Responder does not know which KMS that 2009 issued the ticket, the Responder SHOULD send the RESOLVE_INIT message 2010 to one of the Responder's trusted KMS (KMS R). If KMS R did not 2011 issue the ticket, KMS R would normally be unable to directly resolve 2012 the ticket and must hence ask another KMS to resolve it (typically 2013 the issuing KMS). 2015 The signaling between different KMSs MAY be done with a Ticket 2016 Resolve exchange as illustrated in Figure 9. The IDRr and TICKET 2017 payloads from the previous RESOLVE_INIT message SHOULD be reused. 2018 Note that IDRr cannot be used to look up the pre-shared key/ 2019 certificate. 2021 11. Adding New Ticket Types to MIKEY-TICKET 2023 The Ticket Data (in the TICKET payload) could be a reference to 2024 information (keys etc.) stored by the key management service, it 2025 could contain all the information itself, or it could be a 2026 combination of the two alternatives. For systems serving many users, 2027 it is not ideal to use the reference-only ticket approach as this 2028 would force the key management service to keep state of all issued 2029 tickets that are still valid. Tickets may carry many different types 2030 of information helping to enforce usage policies. The policies may 2031 be group policies or per-user policies. 2033 Tickets may either be transparent, meaning they can be resolved 2034 without contacting the KMS that generated them, or opaque, meaning 2035 that the original KMS must be contacted. The ticket information 2036 SHOULD typically be integrity protected and certain fields need 2037 confidentiality protection, in particular the keys if explicitly 2038 included. Other types of information may also require 2039 confidentiality protection due to privacy reasons. In mode 2 (see 2040 Section 4.1.1) it may be preferable to include several encrypted 2041 ticket protection keys (similar to S/MIME) as this may allow multiple 2042 peers to resolve the ticket. 2044 The Ticket Data MUST include information so that the resolving party 2045 can retrieve an encoded KEMAC. It MUST also be possible to verify 2046 the integrity of the TICKET payload. It is RECOMMENDED that future 2047 specifications use the recommended payload order and do not add any 2048 additional payloads or processing. New Ticket Types SHOULD NOT 2049 change the processing for the Responder. If a new Ticket Type 2050 requires additional processing, it MUST be indicated in the Ticket 2051 Policy (N and O flags). New specifications MUST specify which modes 2052 are supported and if any additional security considerations apply. 2054 12. Security Considerations 2056 Unless otherwise stated, the security considerations in [RFC3830] 2057 still apply and contain notes on the security properties of the MIKEY 2058 protocol, key derivation functions, and other components. As some 2059 security properties depend on the specific Ticket Type, only generic 2060 security considerations concerning the MIKEY-TICKET framework are 2061 discussed. 2063 12.1. General 2065 In addition to the Ticket Policy the KMS MAY have its own set of 2066 policies (authorized key lengths, algorithms, etc.) that in some way 2067 are shared with the peers. The KMS MAY also provide keying material 2068 to authorized intermediate nodes performing various network functions 2069 (e.g. transcoding services, recording services, conference bridges). 2070 The key management service can enforce end-to-end security by only 2071 distributing the keys to authorized end-users. As in [RFC3830] the 2072 user identities are not confidentiality protected. If user privacy 2073 is needed some kind of Privacy Enhancing Technologies (PET) like 2074 anonymous or temporary credentials MAY be used. 2076 In the standard MIKEY modes [RFC3830], the keys are generated by the 2077 Initiator (or by both peers in the Diffie-Hellman scheme). If a bad 2078 PRNG (Pseudo-Random Number Generator) is used, this is likely to make 2079 any key management protocol sensitive to different kinds of attacks, 2080 and MIKEY is no exception. As the choice of the PRNG is 2081 implementation specific, the easiest (and often bad) choice is to use 2082 the PRNG supplied by the operating system. In MIKEY-TICKET's default 2083 mode of operation, the key generation is mostly done by the KMS, 2084 which can be assumed to be less likely to use a bad random number 2085 generator. All keys (including keys used to protect the ticket) MUST 2086 have adequate strength/length, i.e. 128 bits or more. 2088 The use of random nonces (RANDs) in the key derivation is of utmost 2089 importance to counter offline pre-computation attacks and other 2090 generic attacks. A key of length n, using RANDs of length r, has 2091 effective key entropy of (n + r) / 2 against a birthday attack. 2092 Therefore, the length of RAND generated by the Initiator MUST at 2093 least be equal to the length of the pre-shared key/envelope key/MPK 2094 and the sum of the lengths of the RANDs (RANDRi, RANDRr) MUST at 2095 least be equal to the key size of the longest TGK/GTGK. 2097 Note that the CSB Updating messages reuse the old RANDs. This means 2098 that the total effective key entropy (relative to pre-computation 2099 attacks) for k consecutive key updates, assuming the TGKs are each n 2100 bits long, is still no more than n bits. In other words, the time 2101 and memory needed by an attacker to get all k n-bit keys are 2102 proportional to 2^n. While this might seem like a defect, this is in 2103 practice (for all reasonable values of k) not better than brute 2104 force, which on average requires k * 2^(n-1) work (even if different 2105 RANDs would be used). A birthday attack would only require 2^(n/2) 2106 work, but would need access to 2^(n/2) sessions protected with 2107 equally many different keys using a single pair of RANDs. This is, 2108 for typical values of n, clearly totally infeasible. The success 2109 probability of such an attack can be controlled by limiting the 2110 number of updates correspondingly. As stated in [RFC3830], the fact 2111 that more than one key can be compromised in a single attack is 2112 inherent to any solution using secret- or public-key algorithms. An 2113 attacker always gets access to all the exchanged keys by doing an 2114 exhaustive search on the pre-shared key/envelope key/MPK. This 2115 requires 2^m work, where m is the effective size of the key. 2117 As the Responder MAY generate a RAND, The Ticket Transfer exchange 2118 can provide mutual freshness guarantee for all derived keys. 2120 The new encryption, authentication, and pseudo-random functions allow 2121 the use of 256-bit keys and offer a higher security level than the 2122 ones previously defined. 2124 12.2. Key Forking 2126 In some situations, the TRANSFER_INIT message may be delivered to 2127 multiple endpoints. For example when a Responder is registered on 2128 several devices (e.g. mobile phone, fixed phone, and computer) or 2129 when an invite is being made to addresses of the type 2130 IT-support@example.com, a group of users where only one is supposed 2131 to answer. The Initiator may not even always know exactly who the 2132 authorized group members are. To prevent all forms of eavesdropping, 2133 entities other than the endpoint that answers MUST NOT get access to 2134 the session keys. 2136 When key forking is not used, keys are accessible by everyone that 2137 can resolve the ticket. When key forking is used, some keys (MPKr 2138 and TGKs encoded in the ticket) are modified, making them 2139 cryptographically unique for each responder targeted by the forking. 2140 As only the Initiator and the KMS have access to the master TGKs, it 2141 is infeasible for anyone else to derive the session keys. 2143 When key forking is used, some keys (MPKi and TEKs and GTGK encoded 2144 in the ticket) are still accessible by everyone that can resolve the 2145 ticket and should be used with this in mind. This also concerns 2146 session keys transferred in a KEMAC in the first TRANSFER_INIT (as 2147 they are protected with MPKi). 2149 12.3. Denial of Service 2151 This protocol is resistant to Denial of Service attacks against the 2152 KMS in the sense that it does not construct any state (at the key 2153 management protocol level) before it has authenticated the Initiator 2154 or Responder. Since the Responder in general cannot verify the 2155 validity of a TRANSFER_INIT message without first contacting the KMS, 2156 Denial of Service may be launched against the Responder and/or the 2157 KMS via the Responder. Typical prevention methods such as rate- 2158 limiting and ACL (Access Control List) capability SHOULD therefore be 2159 implemented in the KMS as well as the clients. If something in the 2160 signaling is suspicious, the Responder SHOULD abort before attempting 2161 a RESOLVE_INIT with the KMS. The types and amount of prevention 2162 needed depends on how critical the system is and may vary depending 2163 on the Ticket Type. 2165 12.4. Replay 2167 In a replay attack an attacker may intercept and later retransmit the 2168 whole or part of a MIKEY message, attempting to trick the receiver 2169 (Responder or KMS) into undesired operations, leading e.g. to lack of 2170 key freshness. MIKEY-TICKET implements several mechanisms to prevent 2171 and detect such attacks. Timestamps together with a replay cache 2172 efficiently stop the replay of entire MIKEY messages. Parts of the 2173 received messages (or their hashes) can be saved in the replay cache 2174 until their timestamp is outdated. To prevent replay attacks, the 2175 sender's (Initiator or Responder) and the receiver's (Responder or 2176 KMS) identity is always (explicitly or implicitly) included in the 2177 MAC/Signature calculation. 2179 An attacker may also attempt to replay a ticket by inserting it into 2180 a new MIKEY message. A possible scenario is that Alice and Bob first 2181 communicate based on a ticket, which an attacker Mallory intercepts. 2182 Later, Mallory (acting as herself) invites Bob by inserting the 2183 ticket into her own TRANSFER_INIT message. Unless Mallory has 2184 knowledge of the MPKi, such replays will be detected when Bob has 2185 resolved the ticket. If Mallory has knowledge of the MPKi (i.e. she 2186 is authorized to resolve the ticket) and a TGK is used together with 2187 key forking, Mallory will not be able to communicate with Bob due to 2188 her inability to deduce the session keys. If key forking is not used 2189 or a TEK or GTGK is used, the session key is a group key and there is 2190 no attack. For the reasons explained above, it is RECOMMENDED to use 2191 a TGK together with key forking. 2193 12.5. Group Key Management 2195 In a group scenario, only authorized group members must have access 2196 to the keys. In some situation, the communication may be initiated 2197 by the Initiator using a group identity and the Initiator may not 2198 even know exactly who the authorized group members are. Moreover, 2199 group membership may change over time due to leaves/joins. In such a 2200 situation, it is foremost the responsibility of the KMS to reject 2201 ticket resolution requests from unauthorized responders, implying 2202 that the KMS needs to be able to map an individual's identity 2203 (carried in the RESOLVE_INIT message) to group membership (where the 2204 group identity is carried in the ticket). 2206 As noted, reuse of tickets, which bypasses the KMS, is NOT 2207 RECOMMENDED when the Initiator is not fully ensured about group 2208 membership status. 2210 13. Acknowledgements 2212 The authors would like to thank Fredrik Ahlqvist, Rolf Blom, Yi 2213 Cheng, Lakshminath Dondeti, Vesa Lehtovirta, Fredrik Lindholm, Mats 2214 Naslund, Karl Norrman, Oscar Ohlsson, Brian Rosenberg, Bengt Sahlin, 2215 Wei Yinxing, and Zhu Yunwen for their support and valuable comments. 2217 14. IANA Considerations 2219 This document defines several new values for the namespaces Data 2220 Type, Next Payload, PRF func, CS ID map type, Encr alg, MAC alg, TS 2221 Type, ID Type, Hash func, Error no, and Key Data Type defined in 2222 [RFC3830]. The following IANA assignments were added to the MIKEY 2223 Payload registry (in bracket is a reference to the table containing 2224 the registered values): 2226 o Data Type (see Table 6.1) 2228 o Next Payload (see Table 6.2) 2230 o PRF func (see Table 6.3) 2232 o CS ID map type (see Table 6.4) 2234 o Encr alg (see Table 6.5) 2236 o MAC alg (see Table 6.6) 2238 o TS Type (see Table 6.7) 2240 o ID Type (see Table 6.9) 2242 o Hash func (see Table 6.11) 2244 o Error no (see Table 6.13) 2246 o Key Data Type (see Table 6.14) 2248 The TR payload defines an 8-bit TS Role field for which IANA is to 2249 create and maintain a new namespace in the MIKEY Payload registry. 2250 Assignments consist of a TS Role name and its associated value. 2251 Values in the range 1-239 SHOULD be approved by the process of 2252 Specification Required, values in the range 240-254 are for Private 2253 Use, and the values 0 and 255 are Reserved according to [RFC5226]. 2254 The initial contents of the registry should be as follows: 2256 Value TS Role 2257 ------- ------------------------------ 2258 0 Reserved 2259 1 Time of issue (TRi) 2260 2 Start of validity period (TRs) 2261 3 End of validity period (TRe) 2262 4 Rekeying interval (TRr) 2263 5-239 Unassigned 2264 240-254 Private Use 2265 255 Reserved 2267 The IDR payload defines an 8-bit ID Role field for which IANA is to 2268 create and maintain a new namespace in the MIKEY Payload registry. 2269 Assignments consist of an ID Role name and its associated value. 2270 Values in the range 1-239 SHOULD be approved by the process of 2271 Specification Required, values in the range 240-254 are for Private 2272 Use, and the values 0 and 255 are Reserved according to [RFC5226]. 2273 The initial contents of the registry should be as follows: 2275 Value ID Role 2276 ------- ----------------------- 2277 0 Reserved 2278 1 Initiator (IDRi) 2279 2 Responder (IDRr) 2280 3 KMS (IDRkms) 2281 4 Pre-Shared Key (IDRpsk) 2282 5 Application (IDRapp) 2283 6-239 Unassigned 2284 240-254 Private Use 2285 255 Reserved 2287 The RANDR payload defines an 8-bit RAND Role field for which IANA is 2288 to create and maintain a new namespace in the MIKEY Payload registry. 2289 Assignments consist of an RAND Role name and its associated value. 2290 Values in the range 1-239 SHOULD be approved by the process of 2291 Specification Required, values in the range 240-254 are for Private 2292 Use, and the values 0 and 255 are Reserved according to [RFC5226]. 2293 The initial contents of the registry should be as follows: 2295 Value RAND Role 2296 ------- ------------------ 2297 0 Reserved 2298 1 Initiator (RANDRi) 2299 2 Responder (RANDRr) 2300 3 KMS (RANDRkms) 2302 The TP/TICKET payload defines a 16-bit Ticket Type field for which 2303 IANA is to create and maintain a new namespace in the MIKEY Payload 2304 registry. Assignments consist of a Ticket Type name and its 2305 associated value. Values in the range 1-61439 SHOULD be approved by 2306 the process of Specification Required, values in the range 61440- 2307 65534 are for Private Use, and the values 0 and 65535 are Reserved 2308 according to [RFC5226]. The initial contents of the registry should 2309 be as follows: 2311 Value Ticket Type 2312 ----------- ----------------- 2313 0 Reserved 2314 1 MIKEY base ticket 2315 2 3GPP base ticket 2316 3-61439 Unassigned 2317 61440-65534 Private Use 2318 65535 Reserved 2320 15. References 2322 15.1. Normative References 2324 [FIPS.180-3] 2325 National Institute of Standards and Technology, "Secure 2326 Hash Standard (SHS)", FIPS PUB 180-3, October 2008, . 2330 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 2331 Hashing for Message Authentication", RFC 2104, 2332 February 1997. 2334 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2335 Requirement Levels", BCP 14, RFC 2119, March 1997. 2337 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 2338 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 2339 August 2004. 2341 [RFC4330] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 2342 for IPv4, IPv6 and OSI", RFC 4330, January 2006. 2344 [RFC4563] Carrara, E., Lehtovirta, V., and K. Norrman, "The Key ID 2345 Information Type for the General Extension Payload in 2346 Multimedia Internet KEYing (MIKEY)", RFC 4563, June 2006. 2348 [RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. 2349 Carrara, "Key Management Extensions for Session 2350 Description Protocol (SDP) and Real Time Streaming 2351 Protocol (RTSP)", RFC 4567, July 2006. 2353 [RFC4738] Ignjatic, D., Dondeti, L., Audet, F., and P. Lin, "MIKEY- 2354 RSA-R: An Additional Mode of Key Distribution in 2355 Multimedia Internet KEYing (MIKEY)", RFC 4738, 2356 November 2006. 2358 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2359 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2360 May 2008. 2362 15.2. Informative References 2364 [3GPP.33.328] 2365 3GPP, "IP Multimedia Subsystem (IMS) media plane 2366 security", 3GPP TS 33.328 9.1.0, April 2010. 2368 [Otway-Rees] 2369 Otway, D., and O. Rees, "Efficient and Timely Mutual 2370 Authentication", ACM SIGOPS Operating Systems Review v.21 2371 n.1, p.8-10, January 1987. 2373 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2374 A., Peterson, J., Sparks, R., Handley, M., and E. 2375 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2376 June 2002. 2378 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 2379 Kerberos Network Authentication Service (V5)", RFC 4120, 2380 July 2005. 2382 [RFC4650] Euchner, M., "HMAC-Authenticated Diffie-Hellman for 2383 Multimedia Internet KEYing (MIKEY)", RFC 4650, 2384 September 2006. 2386 [RFC5197] Fries, S. and D. Ignjatic, "On the Applicability of 2387 Various Multimedia Internet KEYing (MIKEY) Modes and 2388 Extensions", RFC 5197, June 2008. 2390 [RFC5479] Wing, D., Fries, S., Tschofenig, H., and F. Audet, 2391 "Requirements and Analysis of Media Security Management 2392 Protocols", RFC 5479, April 2009. 2394 Appendix A. MIKEY Base Ticket 2396 The MIKEY base ticket MAY be used in any of the modes described in 2397 Section 4.1.1. The Ticket Data SHALL be constructed as a MIKEY 2398 message protected by a MAC based on a pre-shared Ticket Protection 2399 Key (TPK). The parties that shares the TPK depends on the mode. 2400 Unexpected payloads in the Ticket Data SHOULD be ignored. 2402 Ticket Data = THDR, T, RAND, KEMAC, [IDRpsk], V 2404 A.1. Components of the Ticket Data 2406 The Ticket Data MUST always begin with a Ticket Header payload 2407 (THDR). The ticket header is a new payload type, for definition see 2408 Appendix A.3. 2410 T is a timestamp containing the time of issue or a counter. It MAY 2411 be used in the IV (Initialization Vector) formation (e.g. Section 2412 4.2.3 of [RFC3830]). 2414 RAND is used as input to the key derivation function when keys are 2415 derived from the TPK and the MPK (see Sections A.2.1 and A.2.2). 2417 The KEMAC payload SHALL use the NULL authentication algorithm, as a 2418 MAC is included in the V payload. The encryption key (encr_key) and 2419 salting key (salt_key) SHALL be derived from the TPK (see 2420 Appendix A.2.1). Depending on the encryption algorithm, the salting 2421 key may go into the IV (see [RFC3830]). If CSB ID is needed in the 2422 IV formation it SHALL be set to 0xFFFFFFFF. The KEMAC is hence 2423 constructed as follows: 2425 KEMAC = E(encr_key, MPK || {TEK|TGK|GTGK}) 2427 MPKi and MPKr are derived from the MPK as defined in Appendix A.2.2. 2429 IDRpsk contains an identifier that enables the KMS/Responder to 2430 retrieve the TPK. It MAY be omitted when the TPK can be retrieved 2431 anyhow. 2433 The last payload SHALL be a Verification payload (V) where the 2434 authentication key (auth_key) is derived from the TPK. The MAC SHALL 2435 be calculated over the entire TICKET payload except the Next Payload 2436 field (in the TICKET payload) and the MAC field itself. 2438 A.2. Key Derivation 2440 The labels in the key derivations SHALL NOT include entire RAND 2441 payloads, only the fields RAND length and RAND from the corresponding 2442 payload. 2444 A.2.1. Deriving Keys from a TPK 2446 In the following, we describe how keying material is derived from a 2447 TPK. The key derivation method SHALL be executed using the PRF 2448 indicated in the Ticket Policy. The parameters for the default PRF 2449 are given below. 2451 inkey: : TPK 2452 inkey_len : bit length of the inkey 2453 label : constant || 0xFF || 0xFFFFFFFF || 0x04 || 2454 length RAND || RAND 2455 outkey_len : desired bit length of the outkey (encr_key, 2456 auth_key, salt_key) 2458 Length RAND is the length of RAND in bytes as an 8-bit unsigned 2459 integer. The constants are as defined in Section 4.1.4 of [RFC3830]. 2460 The key derivation and its dependencies on Ticket Data contents when 2461 AES-CM-128 [RFC3830] is used are illustrated in Figure 10. The key 2462 derivation is done by the party that creates the ticket (KMS or 2463 Initiator) and by the party that resolves the ticket (KMS or 2464 Responder). The encryption key and the IV are used to encrypt the 2465 KEMAC. 2467 ----- auth_key ------ 2468 ----- TPK | |----------------------->| AUTH | 2469 | TPK |----------->| | encr_key ------ 2470 ----- | PRF |--------------------+ | 2471 ^ +-->| | salt_key | | 2472 : | | |----------------+ | | 2473 : | ----- | | | 2474 : | v | | 2475 identify : RAND | TS value ---- | | MAC 2476 : | +------------>| IV | | | 2477 : | | ---- | | 2478 : | | IV | | | 2479 : | | v v v 2480 Ticket +---+----+---+--+---+---+-+-+------------+-------+---+---+ 2481 Data | IDRpsk |...| RAND |...| T |............| KEMAC |...| V | 2482 +--------+---+------+---+---+------------+-------+---+---+ 2484 Figure 10: Deriving keys from a TPK 2486 A.2.2. Deriving MPKi and MPKr 2488 In the following, we describe how MPKi and MPKr are derived from the 2489 MPK in the KEMAC payload. The key derivation method SHALL be 2490 executed using the PRF indicated in the Ticket Policy. The 2491 parameters for the default PRF are given below. 2493 inkey: : MPK 2494 inkey_len : bit length of the inkey 2495 label : constant || 0xFF || 0xFFFFFFFF || 0x05 || 2496 length RAND || RAND 2497 outkey_len : desired bit length of the outkey (MPKi, MPKr) 2498 Length RAND is the length of RAND in bytes as an 8-bit unsigned 2499 integer. The constant depends on the derived key type as summarized 2500 below. 2502 Derived key | Constant 2503 ------------+----------- 2504 MPKi | 0x220E99A2 2505 MPKr | 0x1F4D675B 2507 Table A.1: Constants for MPK key derivation 2509 The constants are taken from the decimal digits of e as described in 2510 [RFC3830]. 2512 A.3. Ticket Header Payload (THDR) 2514 The ticket header payload contains an indicator of the next payload 2515 as well as implementation specific data. 2517 0 1 2 3 2518 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 2519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2520 ! Next Payload ! THDR Data length ! THDR Data ~ 2521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2523 * Next Payload (8 bits): identifies the payload that is added after 2524 this payload. 2526 * THDR Data length (16 bits): the length of the THDR Data field (in 2527 bytes). 2529 * THDR Data (variable length): implementation specific data that 2530 SHOULD be ignored if it is not expected. 2532 Appendix B. Alternative Use Cases 2534 B.1. Compatibility Mode 2536 MIKEY-TICKET can be used to define a Ticket Type compatible with 2537 [RFC3830] or any other half-round-trip key management protocol. The 2538 Initiator requests and gets a ticket from the KMS where the Ticket 2539 Data is a [RFC3830] message protected with a pre-shared key (KMS- 2540 Responder) or with the Responder's certificate. The Ticket Data is 2541 then sent to the Responder according to [RFC3830]. In this way the 2542 Initiator can communicate with a Responder that only supports 2543 [RFC3830] and with whom the Initiator do not have any shared 2544 credentials. 2546 +---+ +-----+ +---+ 2547 | I | | KMS | | R | 2548 +---+ +-----+ +---+ 2549 REQUEST_INIT 2550 --------------------------------> 2551 REQUEST_RESP 2552 <-------------------------------- 2553 3830 MIKEY 2554 ----------------------------------------------------------------> 2556 Figure 11: Compatibility mode 2558 Authors' Addresses 2560 John Mattsson 2561 Ericsson AB 2562 SE-164 80 Stockholm 2563 Sweden 2565 Phone: +46 10 71 43 501 2566 Email: john.mattsson@ericsson.com 2568 Tian Tian 2569 ZTE Corpoporation 2570 4F,RD Building 2,Zijinghua Road 2571 Yuhuatai District,Nanjing 210012 2572 P.R.China 2574 Phone: +86-025-5287-7867 2575 Email: tian.tian1@zte.com.cn