idnits 2.17.1 draft-groves-mikey-sakke-03.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 date (October 27, 2011) is 4564 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'IDRi' is mentioned on line 159, but not defined == Missing Reference: 'IDRr' is mentioned on line 159, but not defined == Missing Reference: 'IDRkmsi' is mentioned on line 159, but not defined == Missing Reference: 'IDRkmsr' is mentioned on line 159, but not defined == Missing Reference: 'CERT' is mentioned on line 160, but not defined -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Groves 3 Internet Draft CESG 4 Intended Status: Informational October 27, 2011 5 Expires: April 29, 2012 7 MIKEY-SAKKE: Sakai-Kasahara Key Exchange in Multimedia Internet KEYing 8 (MIKEY) 9 draft-groves-mikey-sakke-03 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on April 29, 2012. 34 Copyright Notice 36 Copyright (c) 2011 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with 44 respect to this document. Code Components extracted from this 45 document must include Simplified BSD License text as described in 46 Section 4.e of the Trust Legal Provisions and are provided without 47 warranty as described in the Simplified BSD License. 49 Abstract 51 This document describes MIKEY-SAKKE, a method of key exchange 52 designed for use in IP Multimedia Subsystem (IMS) [3GPP.33.328] Media 53 Plane Security, but with potential for wider applicability. The 54 MIKEY-SAKKE mode uses Identifier-based Public Key Cryptography 55 (IDPKC) to establish a shared secret value and certificate-less 56 signatures to provide source authentication. MIKEY-SAKKE has a 57 number of desirable features, including simplex transmission, 58 scalability, low-latency call setup and support for secure deferred 59 delivery. 61 Table of Contents 63 1. Introduction.....................................................2 64 1.1. Requirements Terminology....................................3 65 2. A New MIKEY Mode: MIKEY-SAKKE....................................3 66 2.1. Outline.....................................................3 67 2.1.1. Parameters.............................................4 68 2.1.2. Key types..............................................5 69 2.2. Preparing and processing MIKEY-SAKKE messages...............5 70 2.2.1. Components of the I_MESSAGE............................5 71 2.2.2. Processing the I_MESSAGE...............................7 72 2.3. Forking and Retargeting.....................................7 73 2.4. Group Communications........................................8 74 2.5. Deferred Delivery...........................................8 75 3. Key Management...................................................9 76 3.1. Generating Keys from the Shared Secret Value................9 77 3.2. Identifiers.................................................9 78 3.3. Key Longevity and Update...................................10 79 3.4. Key Delivery...............................................11 80 4. Payload Encoding................................................11 81 4.1. Common Header Payload (HDR)................................11 82 4.2. SAKKE payload..............................................12 83 4.3. SIGN payload...............................................13 84 4.4. IDR payload................................................13 85 5. Applicability of MIKEY-SAKKE mode...............................13 86 6. Security Considerations.........................................13 87 6.1. Forking....................................................14 88 6.2. Retargeting................................................14 89 6.3. Group Calls................................................15 90 6.4. Deferred Delivery..........................................15 91 7. IANA Considerations.............................................15 92 8. References......................................................16 93 8.1. Normative References.......................................16 94 8.2. Informative References.....................................17 95 Appendix A. Parameters for use in MIKEY-SAKKE......................18 97 1. Introduction 98 Multimedia Internet Keying (MIKEY) [RFC3830] defines a protocol 99 framework for key distribution and specifies key distribution methods 100 using pre-shared keys, RSA and optionally, a Diffie-Hellman Key 101 Exchange. Since the original specification, several alternative key 102 distribution methods for MIKEY have been proposed such as [RFC4650], 103 [RFC4738], [RFC6043] and [RFC6267]. 105 This document defines an Identifier-based cryptography key 106 distribution method called MIKEY-SAKKE. This scheme makes use of a 107 Key Management Server (KMS) as a root of trust and distributor of key 108 material. The KMS provides users with assurance of the authenticity 109 of the peers with which they communicate. Unlike traditional key 110 distribution systems, MIKEY-SAKKE does not require the KMS to offer 111 high availability. Rather it need only distribute new keys to its 112 users periodically. 114 MIKEY-SAKKE consists of an IDPKC scheme based on that of Sakai and 115 Kasahara [S-K], and a source authentication algorithm which is 116 tailored to use Identifiers instead of certificates. The algorithms 117 behind this protocol are described in [SAKKE] and [ECCSI]. 119 The primary motivation for the MIKEY protocol design is the 120 low-latency requirement of real-time communication; hence many of the 121 defined exchanges finish in one-half to 1 roundtrip. However, some 122 exchanges, such as [RFC6043] and [RFC6267], have been proposed which 123 extend the latency of the protocol with the intent of providing 124 additional security. MIKEY-SAKKE affords similarly enhanced 125 security, but requires only a single simplex transmission (one half 126 roundtrip). 128 MIKEY-SAKKE additionally offers support for scenarios such as 129 forking, retargeting, deferred delivery and pre-encoded content. 131 1.1. Requirements Terminology 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 135 "OPTIONAL" in this document are to be interpreted as described in 136 [RFC2119]. 138 2. A New MIKEY Mode: MIKEY-SAKKE 140 2.1. Outline 142 The proposed MIKEY mode requires a single simplex transmission. The 143 Initiator sends a MIKEY I_MESSAGE containing SAKKE Encapsulated Data 144 and a signature to the intended recipient. The Responder MUST 145 validate the signature. Following signature validation, the 146 Responder processes the Encapsulated Data according to the operations 147 defined in [SAKKE] to derive a Shared Secret Value (SSV). This SSV 148 is used as the TGK (the TEK Generation Key defined in [RFC3830]). 150 A verification message from the Responder (as in Pre-shared key mode, 151 for example) is not needed as the parties are mutually authenticated 152 following processing of the single I_MESSAGE. The notation used for 153 MIKEY messages and their payloads in Figure 1, and in the rest of 154 this document, is defined in [RFC3830]. 156 Initiator Responder 158 I_MESSAGE = 159 HDR, T, RAND, [IDRi], [IDRr], [IDRkmsi], [IDRkmsr], 160 [CERT], {SP}, SAKKE, SIGN ---> 162 Figure 1: MIKEY-SAKKE Unicast Mode 164 The Initiator wants to establish a secure media session with the 165 Responder. The Initiator and the Responder trust a third party, the 166 KMS, which provisions them with key material by a secure mechanism. 167 In addition to the public and secret keys corresponding to their 168 Identifier, the KMS MUST provision devices with its KMS Public Key 169 and, where [ECCSI] is used, its KMS Public Authentication Key. A 170 description of all key material used in MIKEY-SAKKE can be found in 171 Section 2.1.2. The Initiator and the Responder do not share any 172 credentials, instead the Initiator is able to derive the Responder's 173 public Identifier. 175 Implementations MAY provide support for multiple KMSs. In this case, 176 rather than a single KMS, several different KMSs could be involved, 177 e.g. one for the Initiator and one for the Responder. To allow 178 this, each interoperating KMS MUST provide its users with the KMS 179 public keys for every KMS subscriber domain with which its users 180 communicate. It is not anticipated that large mutually communicating 181 groups of KMSs will be needed as each KMS only needs to provide its 182 domain of devices with key material once per key period (see Section 183 3.3) rather than to be active in each call. 185 As MIKEY-SAKKE is based on [RFC3830], the same terminology, 186 processing and considerations still apply unless otherwise stated. 187 Following [RFC3830], messages are integrity protected and encryption 188 is not applied to entire messages. 190 2.1.1. Parameters 192 [SAKKE] requires each application to define the set of public 193 parameters to be used by implementations. The parameters in Appendix 194 A SHOULD be used in MIKEY-SAKKE; alternative parameters MAY be 195 subsequently defined, see Section 4.2. 197 [ECCSI] requires each application to define the Hash function and 198 various other parameters to be used (see Section 4.1 of [ECCSI]). 199 For MIKEY-SAKKE, the P256 elliptic curve and base-point [FIPS186-3] 200 and SHA-256 [FIPS180-3] MUST be used. 202 2.1.2. Key types 204 Users require keys for [SAKKE] and to sign messages. These keys MUST 205 be provided by the users' KMS. It is RECOMMENDED that 206 implementations support the [ECCSI] scheme for signatures. 207 Alternatively, RSA signing as defined in [RFC3830] MAY be used. 209 SAKKE keys SAKKE requires each user to have a Receiver Secret Key, 210 created by the KMS, and the KMS Public Key. For 211 systems that support multiple KMSs, each user also 212 requires the KMS Public Key of every KMS subscriber 213 domain with which communication is authorised. 215 ECCSI keys If ECCSI signatures are used, each user requires a 216 Secret Signing Key and Public Validation Token, created 217 by the KMS, and the KMS Public Authentication Key. For 218 systems that support multiple KMSs, each user also 219 requires the KMS Public Authentication Key of every KMS 220 subscriber domain with which communication is 221 authorised. 223 If instead RSA signatures are to be used, certificates and 224 corresponding private keys MUST be supplied. 226 2.2. Preparing and processing MIKEY-SAKKE messages 228 Preparation and parsing of MIKEY messages are as described in 229 Sections 5.2 and 5.3 of [RFC3830]. Error handling is described in 230 Section 5.1.2 and replay protection guidelines are in Section 5.4 of 231 [RFC3830]. In the following, we describe the components of 232 MIKEY-SAKKE messages and specify message processing and parsing rules 233 in addition to those in [RFC3830]. 235 2.2.1. Components of the I_MESSAGE 237 MIKEY-SAKKE requires a single simplex transmission (a half roundtrip) 238 to establish a shared TGK. The I_MESSAGE MUST contain the MIKEY HDR 239 and timestamp payload in order to provide replay protection. The HDR 240 field contains a CSB_ID (Crypto Session Bundle ID) randomly selected 241 by the Initiator. The V bit in the HDR payload MUST be set to '0' 242 and ignored by the Responder as a response is not expected in this 243 mode. The timestamp payload MUST use TS type NTP-UTC (TS type 0) or 244 NTP (TS type 1) as defined in Section 6.6 of [RFC3830] so that the 245 Responder can determine the Identifiers used by the Initiator (see 246 Section 3.2). It is RECOMMENDED that the time always be specified in 247 UTC. 249 The I_MESSAGE MUST be signed by the Initiator following either the 250 procedure to sign MIKEY messages specified in [RFC3830], or using 251 [ECCSI] as specified in this document. The SIGN payload contains 252 this signature. Thus the I_MESSAGE is integrity and replay 253 protected. The ECCSI signature scheme [ECCSI] SHOULD be used. If 254 this signature scheme is used, then the Initiator MUST NOT include a 255 CERT payload. To form this signature type, the Initiator requires a 256 Secret Signing Key which is provided by the KMS. 258 Other signature types defined for use with MIKEY MAY be used. If 259 signature types 0 or 1 (RSA) are used, then the Initiator SHOULD 260 include a CERT payload; in this case the CERT payload MAY be left out 261 if it is expected that the Responder is able to obtain the 262 certificate in some other manner. If a CERT payload is included, it 263 MUST correspond to the private key used to sign the I_MESSAGE. 265 The Initiator MUST include a RAND payload in the I_MESSAGE as this is 266 used to derive session keys. 268 The I_MESSAGE MAY contain IDRi, IDRr, IDRkmsi and IDRkmsr 269 respectively the identities of the Initiator, Responder, the 270 Initiator's KMS (root of trust for authentication of the Initiator) 271 and the Responder's KMS (root of trust for authentication of the 272 Responder). The IDR payload is defined in [RFC6043] and modified in 273 Section 4.4. When used, this payload provides the Identifier for any 274 of the Initiator, the Responder and their respective KMSs. 276 The ID role MUST be Initiator (value 1) for the IDRi payload and 277 Responder (value 2) for the IDRr payload. The Initiator's ID is used 278 to validate [ECCSI] signatures. If included, the IDRi payload MUST 279 contain the URI of the Initiator incorporated in the Identifier used 280 to sign the I_MESSAGE (see Section 3.2). If included, the IDRr 281 payload MUST contain the URI of the Responder incorporated in the 282 Identifier which the Initiator used in SAKKE (see Section 3.2). If 283 included, the ID role MUST be Initiator's KMS (value TBD4) for the 284 IDRkmsi payload and Responder's KMS (value TBD5) for the IDRkmsr 285 payload and MUST correspond to the KMS used as root of trust for the 286 signature (for the IDRkmsi payload) and the KMS used as the root of 287 trust for the SAKKE key exchange (for the IDRkmsr payload). 289 It is OPTIONAL to include any IDR payloads, as in some user groups 290 Identifiers could be inferred by other means, e.g. through the 291 signalling used to establish a call. Furthermore, a closed user 292 group could rely on only one KMS, whose identity will be understood 293 and need not be included in the signalling. 295 The I_MESSAGE MUST contain a SAKKE payload constructed as defined in 296 Section 4.2. 298 The Initiator MAY also send security policy (SP) payload(s) 299 containing all the security policies that it supports. If the 300 Responder does not support any of the policies included, it SHOULD 301 reply with an Error message of type "Invalid SPpar" (Error no. 10). 302 The Responder has the option not to send the Error message in MIKEY 303 if a generic session establishment failure indication is deemed 304 appropriate and communicated via other means (see Section 4.1.2 of 305 [RFC4567] for additional guidance). 307 2.2.2. Processing the I_MESSAGE 309 The Responder MUST process the I_MESSAGE according to the rules 310 specified in Section 5.3 of [RFC3830]. The following additional 311 processing MUST also be applied. 313 * If the Responder does not support the MIKEY-SAKKE mode of 314 operation, or otherwise cannot correctly parse the received 315 MIKEY message then it SHOULD send an Error message "Message type 316 not supported (Error no 13). Error no 13 is not defined in 317 [RFC3830], and so [RFC3830] compliant implementations MAY return 318 "an unspecified error occurred" (Error no 12). 320 * The Responder MAY compare the IDi payload against his local 321 policy to determine whether he wishes to establish secure 322 communications from the Initiator. If the Responder's policy 323 does not allow this communication, then the Responder MAY 324 respond with an Authentication Error (Error no 0). 326 * If the Responder supports MIKEY-SAKKE and has determined that it 327 wishes to establish secure communications with the initiator, 328 then it MUST verify the signature according to the method 329 described in Section 5.2.2 of [ECCSI] if it is of type TBD3, or 330 according to the certificate used if a signature of type 0 or 1 331 is used. If the verification of the signature fails then an 332 Authentication Error (Error no 0) MAY be sent to the Initiator. 334 * If the authentication is successful then the Responder SHALL 335 process the SAKKE payload and derive the SSV according to the 336 method described in [SAKKE]. 338 2.3. Forking and Retargeting 340 Where forking is to be supported, Receiver Secret Keys can be held by 341 multiple devices. To facilitate this, the Responder needs to load 342 his Receiver Secret Key into each of his devices that he wishes to 343 receive MIKEY-SAKKE communications. If forking occurs, each of these 344 devices can then process the SAKKE payload, and each can verify the 345 Identifier of the Initiator as they hold the KMS Public 346 Authentication Key. The traffic keys could therefore be derived by 347 any of these devices. However, this is the case for any scheme 348 employing simplex transmission, and it is considered that the 349 advantages of this type of scheme are significant for many users. 350 Furthermore, it is for the owner of the Identifier to determine on 351 which devices to allow his Receiver Secret Key to be loaded. Thus it 352 is anticipated that he would have control over all devices that hold 353 his Receiver Secret Key. This argument also applies to applications 354 such as call centres, in which the security relationship is typically 355 between the call centre and the individual calling the centre, rather 356 than the particular operative who receives the call. 358 Devices holding the same Receiver Secret Key ought to each hold a 359 different Secret Signing Key corresponding to the same Identifier. 360 This is possible because the ECCSI scheme allows multiple keys to be 361 generated by KMS for the same Identifier. 363 Secure retargeted calls can only be established in the situation 364 where the Initiator is aware of the Identifier of the device to whom 365 the call is being retargeted; in this case the Initiator ought to 366 initiate a new MIKEY-SAKKE session with the device to whom it has 367 been retargeted (if willing to do so). Retargeting an Initiator's 368 call to another device (with a different Identifier) is to be viewed 369 as insecure when the Initiator is unaware that this has occurred as 370 this prevents authentication of the Responder. 372 2.4. Group Communications 374 SAKKE supports key establishment for group communications. The 375 Initiator needs to form an I_MESSAGE for each member in the group, 376 each using the same SSV. Alternatively, a bridge can be used. In 377 this case the bridge forms an I_MESSAGE for each member of the 378 group. Any member of the group can invite new members directly by 379 forming an I_MESSAGE using the group SSV. 381 2.5. Deferred Delivery 383 Deferred delivery/secure voicemail is fully supported by 384 MIKEY-SAKKE. A deferred delivery server that supports MIKEY-SAKKE 385 needs to store the MIKEY-SAKKE I_MESSAGE along with the encrypted 386 data. When the recipient of the voicemail requests his data, the 387 server needs to initiate MIKEY-SAKKE using the stored I_MESSAGE. 388 Thus the data can be received and decrypted only by a legitimate 389 recipient, who can also verify the Identifier of the sender. This 390 requires no additional support from the KMS, and the deferred 391 delivery server need not be trusted as it is unable to read or tamper 392 with the messages it receives. Note that the deferred delivery 393 server does not need to fully implement MIKEY-SAKKE, merely to store 394 and forward the I_MESSAGE. 396 The deferred delivery message needs to be collected by its recipient 397 before the key period in which it was sent expires (see Section 3.3 398 for a discussion of key periods). Alternatively, if greater 399 longevity of deferred delivery payloads is to be supported, the 400 Initiator needs to include an I_MESSAGE for each key period during 401 the lifetime of the deferred delivery message, each using the same 402 SSV. In this case, the deferred delivery server needs to forward the 403 I_MESSAGE corresponding to the current key period to the recipient. 405 3. Key Management 407 3.1. Generating Keys from the Shared Secret Value 409 Once a MIKEY-SAKKE I_MESSAGE has been successfully processed by the 410 Responder, he will share an authenticated Shared Secret Value (SSV) 411 with the Initiator. This SSV is used as the TGK. The keys used to 412 protect application traffic are derived as specified in [RFC3830]. 414 3.2. Identifiers 416 One of the primary features and advantages of Identifier-Based 417 Encryption is that the public keys of users are their Identifiers, 418 which can be constructed by their peers. This removes the need for 419 Public Key or Certificate servers, so that all data transmission per 420 session can take place directly between the peers and high 421 availability security infrastructure is not needed. In order for the 422 Identifiers to be constructable, they need to be unambiguously 423 defined. This section defines the format of Identifiers for use in 424 MIKEY-SAKKE. 426 If keys are updated regularly, a KMS is able to revoke devices. To 427 this end, every Identifier for use in MIKEY-SAKKE MUST contain a 428 timestamp value indicating the key period for which the Identifier is 429 valid (see Section 3.3). This document uses a year and month format 430 to enforce monthly changes of key material. Further Identifier 431 schemes MAY be defined for communities that require different key 432 longevity. 434 An Identifier for use in MIKEY-SAKKE MUST take the form of a 435 timestamp formatted as a US-ASCII string [ASCII] and terminated by a 436 NULL byte, followed by identifying data which relates to the identity 437 of the device or user, also represented by a US-ASCII string and 438 terminated by a NULL byte. 440 For the purposes of this document, the timestamp MUST take the form 441 of a year and month value, formatted according to [ISO8601], with the 442 format "YYYY-MM", indicating a four digit year, followed by a hyphen 443 "-", followed by a two digit month. 445 For the Identifier scheme defined in this document, the identifying 446 data MUST take the form of a constrained "tel" URI. If an 447 alternative URI scheme is to be used to form SAKKE Identifiers, a 448 subsequent RFC MUST define constraints to ensure that the URI can be 449 formed unambiguously. The normalization procedures described in 450 Section 6 of [RFC3986] MUST be used as part of the constraining rules 451 for the URI format. It would also be possible to define Identifier 452 types that used identifying data other than a URI. 454 The restrictions for the "tel" URI scheme [RFC3966] for use in 455 MIKEY-SAKKE Identifiers are as follows: 457 * the "tel" URI for use in MIKEY-SAKKE MUST be formed in global 458 notation, 460 * visual separators MUST NOT be included, 462 * the "tel" URI MUST NOT include additional parameters, 464 * the "tel" URI MUST NOT include phone-context parameters. 466 These constraints on format are necessary so that all parties can 467 unambiguously form the "tel" URI. 469 For example, suppose a user's telephone number is +447700900123 and 470 the month is 2011-02. Then the user's Identifier is defined as the 471 ASCII string 473 2011-02\0tel:+447700900123\0, 475 where '\0' denotes the null 8-bit ASCII character 0x00. 477 If included in I_MESSAGE, the IDRi and IDRr payloads MUST contain the 478 URI used to form the Identifier. The value of the month used to form 479 the Identifiers MUST be equal to the month as specified by the data 480 in the timestamp payload. 482 3.3. Key Longevity and Update 484 Identifiers for use in MIKEY-SAKKE change regularly in order to force 485 users to regularly update their key material; we term the interval 486 for which a key is valid a "key period". This means that if a device 487 is compromised (and this is reported procedurally), it can continue 488 to communicate with other users for at most one key period. Key 489 periods SHOULD be indicated by the granularity of the format of the 490 timestamp used in the Identifier. In particular, the Identifier 491 scheme in this document uses monthly key periods. Implementations 492 MUST allow devices to hold two periods' keys simultaneously to allow 493 for differences in system time between Initiator and Responder. 495 Where a monthly key period applies, it is RECOMMENDED that 496 implementations receive the new key material before the 497 second-to-last day of the old month, commence allowing receipt of 498 calls with the new key material on the second-to-last day of the old 499 month, and continue to allow receipt calls with the old key material 500 on the first and second days of the new month. Devices SHOULD cease 501 to receive calls with key material corresponding to the previous 502 month on the third day of the month; this is to allow compromised 503 devices to be keyed out of the communicating user group. 505 KMSs MAY update their KMS Master Secret Keys and KMS Master Secret 506 Authentication Keys. If such an update is not deemed necessary, then 507 the corresponding KMS Public Keys and KMS Public Authentication Keys 508 will be fixed. If KMS keys are to be updated, then this update MUST 509 occur at the change of a key period, and new KMS Public Key(s) and 510 KMS Public Authentication Key(s) MUST be provided to all users with 511 their user key material. 513 It is NOT RECOMMENDED for KMSs to distribute multiple key periods' 514 keys simultaneously, as this prevents the periodic change of keys 515 from excluding compromised devices. 517 3.4. Key Delivery 519 This document does not seek to restrict the mechanisms by which the 520 necessary key material might be obtained from the KMS. The 521 mechanisms of [RFC5408] are not suitable for this application as the 522 MIKEY-SAKKE protocol does not require public parameters to be 523 obtained from a server: these are fixed for all users in order to 524 facilitate interoperability and simplify implementation. 526 The delivery mechanism used MUST provide confidentiality to all 527 secret keys, integrity protection to all keys and mutual 528 authentication of the device and the KMS. 530 4. Payload Encoding 532 This section describes the new SAKKE payload and also the payloads 533 for which changes have been made compared to [RFC3830]. A detailed 534 description of MIKEY payloads is provided in [RFC3830]. 536 4.1. Common Header Payload (HDR) 538 An additional value is added to the data type and next payload 539 fields. 541 * Data type (8 bits): describes the type of message 543 Data type | Value | Comment 544 ----------------------------------------------- 545 SAKKE msg | TBD1 | Initiator's SAKKE message 547 Table 1: Data type (additions) 549 * Next payload (8 bits): identifies the payload that is added 550 after this payload. 552 Next Payload | Value | Section 553 ------------------------------- 554 SAKKE | TBD2 | 4.2 556 Table 2: Next payload (additions) 558 * V (1 bit): flag to indicate whether a response message is 559 expected ('1') or not ('0'). It MUST be set to '0' and ignored 560 by the Responder in a SAKKE message. 562 4.2. SAKKE payload 564 The SAKKE payload contains the SAKKE Encapsulated Data as defined in 565 [SAKKE]. 567 1 2 3 568 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 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 ! Next payload ! SAKKE params ! ID scheme ! SAKKE data ~ 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 ~ length (cont) ! SAKKE data ~ 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 Table 3: SAKKE payload 577 * Next payload (8 bits): identifies the payload that is added 578 after this payload. 580 * SAKKE params (8 bits): indicates the SAKKE parameter set to be 581 used. 583 SAKKE params | Value 584 ------------------------------------------ 585 Parameter Set 1 (See Appendix A) | 1 587 Table 4: SAKKE params 589 * ID scheme (8 bits): indicates the SAKKE identifier scheme to be 590 used. 592 ID scheme | Value 593 ---------------------------------------------------- 594 tel URI with monthly keys (See Section 3.2) | 1 596 Table 5: ID scheme 598 * SAKKE data length (16 bits): length of SAKKE data (in bytes). 600 * SAKKE data (variable): the SAKKE Encapsulated Data formatted as 601 defined in Section 4 of [SAKKE]. 603 4.3. SIGN payload 605 To enable use of the ECCSI signature algorithm which has efficiency 606 benefits for use with Identifier-Based Encryption, we define an 607 additional signature type. 609 * S type (4 bits): indicates the signature algorithm applied by 610 the signer. 612 S type | Value | Comments 613 ----------------------------------------- 614 ECCSI | TBD3 | ECCSI signature [ECCSI] 616 Table 6: S type (additions) 618 4.4. IDR payload 620 The IDR payload was defined in [RFC6043], but its definition only 621 provided the facility to identify one KMS per exchange. Since it is 622 possible that different KMSs could be used by the Initiator and 623 Responder, this payload is extended to define an ID role for the KMS 624 of the Initiator and the KMS of the Responder. 626 * ID Role (8 bits): specifies the sort of identity. 628 ID Role | Value 629 --------------------------------- 630 Initiator's KMS (IDRkmsi) | TBD4 631 Responder's KMS (IDRkmsr) | TBD5 633 Table 7: ID Role (additions) 635 5. Applicability of MIKEY-SAKKE mode 637 MIKEY-SAKKE is suitable for use in a range of applications in which 638 secure communications under a clear trust model are needed. In 639 particular, the KMS need not provide high availability as it is only 640 necessary to provide periodic refresh of key material. Devices are 641 provided with a high level of authentication as the KMS acts as a 642 root of trust for both key exchange and signatures. 644 6. Security Considerations 646 Unless explicitly stated, the security properties of the MIKEY 647 protocol as described in [RFC3830] apply to MIKEY-SAKKE as well. In 648 addition, MIKEY-SAKKE inherits some properties of Identifier-Based 649 Cryptography. For instance, by concatenating the "date" with the URI 650 to form the Identifier, the need for any key revocation mechanisms is 651 virtually eliminated. It is NOT RECOMMENDED for KMSs to distribute 652 multiple months' keys simultaneously in an IBE system, as this 653 prevents the monthly change of keys from excluding compromised 654 devices. 656 The solution proposed provides protection suitable for high security 657 user groups, but is scalable enough that it could be used for large 658 numbers of users. Traffic keys cannot be derived by any 659 infrastructure component other than the KMS. 661 The effective security of the public parameters defined in this 662 document is 112 bits, as this is the security offered by p of size 663 1024 bits used in SAKKE (see Section 7 of [SAKKE]). For similar 664 parameter sizes, MIKEY-SAKKE provides equivalent levels of effective 665 security to other schemes of this type (such as [RFC6267]). For 666 reasons of efficiency and security, it is RECOMMENDED to use a mode 667 of AES-128 [AES] in the traffic application to which MIKEY-SAKKE 668 supplies key material, but users SHOULD be aware that 112 bits of 669 security are offered by the defined public parameters. Following 670 [SP800-57], this choice of security strength is appropriate for use 671 to protect data until 2030. 673 User identities cannot be spoofed, since the Public Authentication 674 Token is tied to the Identifier of the sender by the KMS. In 675 particular, the Initiator is provided with assurance that nobody 676 other than a holder of the legitimate Receiver Secret Key can process 677 the SAKKE Encapsulated Data, and the signature binds the holder of 678 the Initiator's Secret Signing Key to the I_MESSAGE. Since these 679 keys are provided via a secure channel by the KMS, mutual 680 authentication is provided. This mechanism protects against both 681 passive and active attacks. 683 If there were a requirement that a caller remain anonymous from any 684 called parties, then it would be possible to remove the signature 685 from the protocol. A called user could then decide, according to 686 local policy, whether to accept such a secure session. 688 6.1. Forking 690 Where forking is used, the view is taken that it is not necessary for 691 each device to have a separate Receiver Secret Key. Rather, where a 692 user wishes his calls to be forked between his devices, he loads the 693 same Receiver Secret Key onto each of them. This does not compromise 694 his security as he controls each of the devices, and is consistent 695 with the Initiator's expectation that he is authenticated to the 696 owner of the Identifier he selected when initiating the call. 698 6.2. Retargeting 699 Since the Initiator is made aware by the forwarding server of the 700 change to the Identifier of the Responder, he creates an I_MESSAGE 701 that can only be processed by this legitimate Responder. The 702 Initiator MAY also choose to discontinue the session after checking 703 his local policy. 705 6.3. Group Calls 707 Any device that possesses an SSV can potentially provide it securely 708 to any other device using SAKKE. Thus group calls can either be 709 established by an Initiator, or can be extended to further Responders 710 by any party to whom the original Initiator has sent an I_MESSAGE. 711 The Initiator in this context MAY be a conference bridge. If a mode 712 of operation in which a bridge has no knowledge of the SSV is needed, 713 the role of MIKEY-SAKKE Initiator MUST be carried out by one or more 714 of the communicating parties, not by the bridge. 716 Where multi-way communications (rather than broadcast) are needed, 717 the application using the supplied key material MUST ensure that a 718 suitable IV scheme is used in order to prevent cryptovariable 719 re-use. 721 6.4. Deferred Delivery 723 Secure deferred delivery is supported in a manner such that no trust 724 is placed on the deferred delivery server. This is a significant 725 advantage, as it removes the need for secure infrastructure 726 components beyond the KMS. 728 7. IANA Considerations 730 This document defines new values for the namespaces Data Type, Next 731 Payload, and S type defined in [RFC3830], and for the ID Role 732 namespace defined in [RFC6043]. The following IANA assignments were 733 added to the MIKEY Payload registry [to be removed upon publication: 734 http://www.iana.org/assignments/mikey-payloads] (in bracket is a 735 reference to the table containing the registered values): 737 * Data Type (see Table 1) 739 * Next Payload (see Table 2) 741 * S type (see Table 6) 743 * ID Role (see Table 7) 745 The SAKKE payload defined in Section 4.2 defines two fields for which 746 IANA is requested to create and maintain name spaces in the MIKEY 747 Payload registry. These two fields are the 8-bit SAKKE params field, 748 and the 8-bit ID scheme field. IANA is requested to record the 749 pre-defined values defined in Section 4.2 for each of the two name 750 spaces. Values in the range 1-239 SHOULD be approved by the process 751 of Specification Required, values in the range 240-254 are for 752 Private Use, and the values 0 and 255 are Reserved according to 753 [RFC5226]. 755 Initial values for the SAKKE params registry are given below. 756 Assignments consist of a SAKKE parameters name and its associated 757 value. 759 Value SAKKE params Definition 760 ----- ------------ ---------- 761 0 Reserved 762 1 Parameter Set 1 See Appendix A 763 2-239 Unassigned 764 240-254 Private Use 765 255 Reserved 767 Initial values for the ID scheme registry are given below. 768 Assignments consist of a name of an identifier scheme name and its 769 associated value. 771 Value ID Scheme Definition 772 ----- ------------ ---------- 773 0 Reserved 774 1 tel URI with monthly keys See Section 3.2 775 2-239 Unassigned 776 240-254 Private Use 777 255 Reserved 779 8. References 781 8.1. Normative References 783 [AES] NIST, "Advanced Encryption Standard (AES)", FIPS 784 PUB 197, http://www.nist.gov/aes/ 786 [ASCII] American National Standards Institute, "Coded 787 Character Set -- 7-bit American Standard Code for 788 Information Interchange", ANSI X3.4, 1986. 790 [ECCSI] Groves, M., Elliptic Curve-based Certificate-less 791 Signatures for Identifier Based Encryption 792 (ECCSI), draft-groves-eccsi-01 [work in progress], 793 February 2011. 795 [FIPS180-3] Federal Information Processing Standards 796 Publication (FIPS PUB) 180-3, Secure Hash Standard 797 (SHS), October 2008. 799 [FIPS186-3] Federal Information Processing Standards 800 Publication (FIPS PUB) 186-3, Digital Signature 801 Standard (DSS), June 2009. 803 [ISO8601] "Data elements and interchange formats -- 804 Information interchange -- Representation of dates 805 and times", ISO 8601:1988(E), International 806 Organization for Standardization, June, 1988. 808 [RFC2119] Bradner, S., "Key words for use in RFCs to 809 Indicate Requirement Levels", BCP 14, RFC 2119, 810 March 1997. 812 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., 813 and K. Norrman, "MIKEY: Multimedia Internet 814 KEYing", RFC 3830, August 2004. 816 [RFC3966] Schulzrinne, H., "The tel URI for Telephone 817 Numbers", RFC 3966, December 2004. 819 [RFC3986] Berners-Lee, T., Fielding, R. and L. Masinter, 820 "Uniform Resource Identifier (URI): Generic 821 Syntax", RFC 3986, January 2005. 823 [RFC6043] Mattsson, J. and T. Tian, "MIKEY-TICKET: An 824 Additional Mode of Key Distribution in Multimedia 825 Internet KEYing (MIKEY)", RFC 6043, March 2011. 827 [SAKKE] Groves M., "Sakai-Kasahara Key Establishment 828 (SAKKE)", draft-groves-sakke-03 [work in 829 progress], October 2011. 831 [SP800-57] E. Barker, W. Barker, W. Burr, W. Polk and M. 832 Smid, "Recommendation for Key Management - Part 1: 833 General (Revised)," NIST Special Publication 834 800-57, March 2007. 836 8.2. Informative References 838 [3GPP.33.328] 3GPP, "IP Multimedia Subsystem (IMS) media plane 839 security", 3GPP TS 33.328 9.3.0, December 2010. 841 [RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., 842 and E. Carrara, "Key Management Extensions for 843 Session Description Protocol (SDP) and Real Time 844 Streaming Protocol (RTSP)", RFC 4567, July 2006. 846 [RFC4650] Euchner, M., "HMAC-Authenticated Diffie-Hellman 847 for Multimedia Internet KEYing (MIKEY)", RFC 4650, 848 September 2006. 850 [RFC4738] Ignjatic, D., Dondeti, L., Audet, F., and P. Lin, 851 "MIKEY- RSA-R: An Additional Mode of Key 852 Distribution in Multimedia Internet KEYing 853 (MIKEY)", RFC 4738, November 2006. 855 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for 856 Writing an IANA Considerations Section in RFCs", 857 BCP 26, RFC 5226, May 2008. 859 [RFC5408] Appenzeller, G., Martin, L., and M. Schertler, 860 "Identity- Based Encryption Architecture and 861 Supporting Data Structures", RFC 5408, January 862 2009. 864 [RFC6267] Cakulev, V. and G. Sundaram, "MIKEY-IBAKE: 865 Identity-Based Mode of Key Distribution in 866 Multimedia Internet KEYing (MIKEY)", RFC 6267, 867 June 2011. 869 [S-K] Sakai, R., Ohgishi, K. and M. Kasahara, "ID 870 based cryptosystem with pairing on elliptic 871 curve", Symposium on Cryptography and Information 872 Security - SCIS, 2003. 874 Appendix A. Parameters for use in MIKEY-SAKKE 876 [SAKKE] requires each application to define the set of public 877 parameters to be used by implementations. Parameter Set 1 is defined 878 in this appendix. Descriptions of the parameters are provided in 879 Section 2.1 of [SAKKE]. 881 n = 128 883 p = 997ABB1F 0A563FDA 65C61198 DAD0657A 884 416C0CE1 9CB48261 BE9AE358 B3E01A2E 885 F40AAB27 E2FC0F1B 228730D5 31A59CB0 886 E791B39F F7C88A19 356D27F4 A666A6D0 887 E26C6487 326B4CD4 512AC5CD 65681CE1 888 B6AFF4A8 31852A82 A7CF3C52 1C3C09AA 889 9F94D6AF 56971F1F FCE3E823 89857DB0 890 80C5DF10 AC7ACE87 666D807A FEA85FEB 892 q = 265EAEC7 C2958FF6 99718466 36B4195E 893 905B0338 672D2098 6FA6B8D6 2CF8068B 894 BD02AAC9 F8BF03C6 C8A1CC35 4C69672C 895 39E46CE7 FDF22286 4D5B49FD 2999A9B4 896 389B1921 CC9AD335 144AB173 595A0738 897 6DABFD2A 0C614AA0 A9F3CF14 870F026A 898 A7E535AB D5A5C7C7 FF38FA08 E2615F6C 899 203177C4 2B1EB3A1 D99B601E BFAA17FB 901 Px = 53FC09EE 332C29AD 0A799005 3ED9B52A 902 2B1A2FD6 0AEC69C6 98B2F204 B6FF7CBF 903 B5EDB6C0 F6CE2308 AB10DB90 30B09E10 904 43D5F22C DB9DFA55 718BD9E7 406CE890 905 9760AF76 5DD5BCCB 337C8654 8B72F2E1 906 A702C339 7A60DE74 A7C1514D BA66910D 907 D5CFB4CC 80728D87 EE9163A5 B63F73EC 908 80EC46C4 967E0979 880DC8AB EAE63895 910 Py = 0A824906 3F6009F1 F9F1F053 3634A135 911 D3E82016 02990696 3D778D82 1E141178 912 F5EA69F4 654EC2B9 E7F7F5E5 F0DE55F6 913 6B598CCF 9A140B2E 416CFF0C A9E032B9 914 70DAE117 AD547C6C CAD696B5 B7652FE0 915 AC6F1E80 164AA989 492D979F C5A4D5F2 916 13515AD7 E9CB99A9 80BDAD5A D5BB4636 917 ADB9B570 6A67DCDE 75573FD7 1BEF16D7 919 g = 66FC2A43 2B6EA392 148F1586 7D623068 920 C6A87BD1 FB94C41E 27FABE65 8E015A87 921 371E9474 4C96FEDA 449AE956 3F8BC446 922 CBFDA85D 5D00EF57 7072DA8F 541721BE 923 EE0FAED1 828EAB90 B99DFB01 38C78433 924 55DF0460 B4A9FD74 B4F1A32B CAFA1FFA 925 D682C033 A7942BCC E3720F20 B9B7B040 926 3C8CAE87 B7A0042A CDE0FAB3 6461EA46 928 Hash = SHA-256 (defined in [FIPS180-3]). 930 Author's Address 932 Michael Groves 933 CESG 934 Hubble Road 935 Cheltenham 936 GL51 8HJ 937 UK 939 Email: Michael.Groves@cesg.gsi.gov.uk 941 Acknowledgement 943 Funding for the RFC Editor function is provided by the IETF 944 Administrative Support Activity (IASA).