idnits 2.17.00 (12 Aug 2021) /tmp/idnits9150/draft-hardjono-ace-fluffy-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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 4, 2016) is 2140 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC7159' is mentioned on line 172, but not defined ** Obsolete undefined reference: RFC 7159 (Obsoleted by RFC 8259) == Missing Reference: 'RFC7049' is mentioned on line 172, but not defined ** Obsolete undefined reference: RFC 7049 (Obsoleted by RFC 8949) == Missing Reference: 'RFC6749' is mentioned on line 175, but not defined == Missing Reference: 'Oauth2' is mentioned on line 310, but not defined == Missing Reference: 'RFC5929' is mentioned on line 377, but not defined == Missing Reference: 'RFC7517' is mentioned on line 727, but not defined == Missing Reference: 'RFC5280' is mentioned on line 792, but not defined == Unused Reference: 'RFC6347' is defined on line 2082, but no explicit reference was found in the text == Unused Reference: 'ACE' is defined on line 2090, but no explicit reference was found in the text == Unused Reference: 'BR-3KPD' is defined on line 2093, but no explicit reference was found in the text == Unused Reference: 'Choo04' is defined on line 2098, but no explicit reference was found in the text == Unused Reference: 'Choo06' is defined on line 2103, but no explicit reference was found in the text == Unused Reference: 'NS' is defined on line 2121, but no explicit reference was found in the text == Unused Reference: 'OAuth2' is defined on line 2126, but no explicit reference was found in the text == Unused Reference: 'RFC6113' is defined on line 2144, but no explicit reference was found in the text ** Obsolete normative reference: RFC 7159 (ref. 'JSON') (Obsoleted by RFC 8259) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) Summary: 4 errors (**), 0 flaws (~~), 17 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Hardjono 3 Internet-Draft MIT 4 Intended status: Standards Track N. Smith 5 Expires: January 5, 2017 Intel Corp 6 July 4, 2016 8 Fluffy: Simplified Key Exchange for Constrained Environments 9 draft-hardjono-ace-fluffy-03 11 Abstract 13 This document proposes a simplified key exchange protocol for the 14 establishment of a symmetric key shared between two devices or 15 entities within a constrained environment. The pair-wise key 16 establishment is performed using the mediation of a trusted Simple 17 Key Distribution Center (SKDC) entity. The protocol also supports 18 the mediated distribution of a group-key among multiple devices or 19 entities for the purposes of protecting multicast messages. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on January 5, 2017. 38 Copyright Notice 40 Copyright (c) 2016 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 5 57 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 58 1.3. Design Considerations and Assumptions . . . . . . . . . . 7 59 1.4. Out of Scope and Non-Goals: . . . . . . . . . . . . . . . 8 60 2. Common Building Blocks . . . . . . . . . . . . . . . . . . . 9 61 2.1. SKDC Request Body . . . . . . . . . . . . . . . . . . . . 9 62 2.2. Miniticket . . . . . . . . . . . . . . . . . . . . . . . 10 63 2.3. Receipt . . . . . . . . . . . . . . . . . . . . . . . . . 12 64 2.4. Authenticator . . . . . . . . . . . . . . . . . . . . . . 14 65 2.5. Acknowledgement . . . . . . . . . . . . . . . . . . . . . 15 66 2.6. Key Data . . . . . . . . . . . . . . . . . . . . . . . . 16 67 2.6.1. Symmetric Key Data . . . . . . . . . . . . . . . . . 16 68 2.6.2. Asymmetric Key Data . . . . . . . . . . . . . . . . . 16 69 2.7. Key Envelope . . . . . . . . . . . . . . . . . . . . . . 17 70 3. Pair-wise Shared Key Establishment . . . . . . . . . . . . . 18 71 3.1. Basic Protocol Exchange . . . . . . . . . . . . . . . . . 18 72 3.2. PSK-Request Message (PSK-REQ) . . . . . . . . . . . . . . 21 73 3.3. PSK-Response Message (PSK-REP) . . . . . . . . . . . . . 22 74 3.4. PSK-Establish Message (PSK-ESTB) . . . . . . . . . . . . 24 75 3.5. PSK-Acknowledge Message (PSK-ACK) . . . . . . . . . . . . 25 76 4. Pair-wise Shared Key Deletion . . . . . . . . . . . . . . . . 26 77 4.1. PSK-Delete Message (PSK-DELT) . . . . . . . . . . . . . . 27 78 4.2. PSK-Delete-Confirm Message (PSK-DELC) . . . . . . . . . . 27 79 5. Group Shared Key Establishment . . . . . . . . . . . . . . . 28 80 5.1. GSK-Request Message (GSK-REQ) . . . . . . . . . . . . . . 31 81 5.2. GSK-Response Message (GSK-REP) . . . . . . . . . . . . . 33 82 5.3. GSK-Fetch Message (GSK-FET) . . . . . . . . . . . . . . . 34 83 5.4. GSK-Deliver Message (GSK-DLVR) . . . . . . . . . . . . . 35 84 6. Group Shared Key Deletion . . . . . . . . . . . . . . . . . . 36 85 6.1. GSK-Delete Message (GSK-DELT) . . . . . . . . . . . . . . 37 86 6.2. GSK-Delete-Confirm Message (GSK-DELC) . . . . . . . . . . 38 87 7. Public Key Pair Establishment . . . . . . . . . . . . . . . . 39 88 7.1. Public Key Pair Request (PKP-REQ) . . . . . . . . . . . . 40 89 7.2. Public Key Pair Response (PKP-REP) . . . . . . . . . . . 42 90 8. JSON Message Format . . . . . . . . . . . . . . . . . . . . . 44 91 9. Encryption and Checksums . . . . . . . . . . . . . . . . . . 44 92 10. Security Considerations . . . . . . . . . . . . . . . . . . . 44 93 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 44 94 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 95 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 44 96 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 97 14.1. Normative References . . . . . . . . . . . . . . . . . . 44 98 14.2. Informative References . . . . . . . . . . . . . . . . . 45 99 Appendix A. Document History . . . . . . . . . . . . . . . . . . 46 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46 102 1. Introduction 104 This document proposes a simplified key exchange protocol for 105 constrained environments for the establishment of a symmetric key 106 shared between two constrained devices. The pair-wise key 107 establishment is performed using the mediation of a trusted Simple 108 Key Distribution Center (SKDC) entity. The protocol also supports 109 the mediated distribution of a group-key among multiple devices or 110 entities for the purposes of protecting multicast messages. 112 The simplified key exchange protocol is referred to here as "Fluffy" 113 and is based on a reduced set of Kerberos [RFC4120] messages, 114 adjusting the message flows, types and features to the needs and 115 capabilities of constrained devices and environments. It does not 116 seek to be backward compatible with Kerberos implementations. 118 The protocol aims to be independent of the underlying transport 119 protocol, and as such the protocol messages are integrity-protected 120 against modifications in-transit. Similar to Kerberos [RFC4120], 121 messages that carry sensitive information (such as keys and/or keying 122 material) are protected using authenticated-encryption. Non- 123 sensitive fields of the messages are integrity-protected using 124 checksums or keyed-hash in the manner of RFC3961. A separate 125 specification will be developed to address in more detail these 126 cryptographic aspects of the current proposed protocol. 128 Two families of protocol messages are defined here: 130 o Pairwise key establishment between two entities: When a client 131 seeks to establish a pairwise shared key (called the session 132 encryption key) with a service principal (SP), it invokes the 133 mediation of the SKDC. A four (4) message flow among the client, 134 SKDC and SP are used to establish the pairwise shared key. A 135 further two messages are used to delete the key prior to its 136 expiration. 138 o Group-shared key establishment among multiple entities: When a 139 client (e.g. client#1) seeks to create a group-shared key (called 140 the group encryption key), it invokes the SKDC to create the 141 group-key, to retain a copy at the SKDC and to return a copy to 142 the requesting client. The distribution of the group-key to other 143 members of a multicast group uses a simple fetch/deliver model in 144 which new group members (e.g. client#2) must ask for a copy of the 145 group-key from the SKDC. 147 An additional set of exchanges are introduced to support the delivery 148 of a public key pair to a client entity, with or without an 149 accompanying digital certificate. 151 The current simplified key exchange protocol does not address the 152 initial secret establishment between an entity and the SKDC. This is 153 referred to in RFC4120 and RFC6113 as "pre-authentication". We 154 anticipate that many types of constrained devices would need to 155 undergo "on-boarding" into an operational state within a constrained 156 environment, and that the on-boarding process may include (directly 157 or as a side-effect) the establishment of the initial secret between 158 the new device and the SKDC already operating in the environment. 159 Thus, for example, the on-boarding process of a device (e.g. door- 160 lock) into a constrained environment (e.g. home basement) with an 161 SKDC entity (e.g. within the alarm panel) may consist of the device 162 and the SKDC running a Diffie-Hellman exchange with the assistance of 163 the human owner. The topic of on-boarding and off-boarding of 164 devices is outside the scope of the current specification. 166 In this specification we assume that a transport such as CoAP 167 [RFC7252] will be deployed in constrained environments where the IP 168 protocol is operating at the network layer. Environments that are 169 using non-IP transport are out of scope currently for this 170 specification. 172 The current protocol uses JSON [RFC7159] and CBOR [RFC7049] for its 173 message format. This is in-line with the RESTful paradigm and 174 provides the greatest flexibility for the current protocol to be 175 integrated with other protocols such as OAuth2.0 [RFC6749] for 176 authorization and UMA [UMACORE] for user-centric consent management. 178 Since the intended deployment environment for the current protocol is 179 a constrained environment, devices and entities there are assumed to 180 use the UUID as the basis for identification. How a device is 181 assigned a UUID is out of scope for the current specification. 183 The current specification acknowledges that in certain types of 184 constrained environments there is the need for devices to not only 185 operate autonomously for long periods of time, but also for devices 186 to have the capability to take-on different roles with respect to 187 other devices in the environment. Thus, a device (D1) acting as a 188 client to another device (D2) that is acting as an SKDC could also be 189 acting as an SKDC for yet a third device (D3). Thus, the device D1 190 may have the capability to be both a client and SKDC depending on the 191 operational environment. 193 As in many deployment environments generally, often security is a 194 trade-off among several factors (e.g. usability, assurance levels, 195 cost, economic risk/benefits, and others). As such, it is realistic 196 to acknowledge that the degree of trustworthiness of an SKDC is 197 dependent on the value of the data and connections within the 198 deployment environment. Thus, an SKDC within a home environment may 199 not be expected to feature the same level of resistance to attacks as 200 an enterprise deployment of a Kerberos KDC. 202 1.1. Notational Conventions 204 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 205 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this 206 document are to be interpreted as described in [RFC2119]. 208 Unless otherwise noted, all protocol properties and values are case 209 sensitive. JSON [JSON] data structures defined by this specification 210 MAY contain extension properties that are not defined in this 211 specification. Any entity receiving or retrieving a JSON data 212 structure SHOULD ignore extension properties it is unable to 213 understand. Extension names that are unprotected from collisions are 214 outside the scope of this specification. 216 1.2. Terminology 218 The current specification seeks to share terminology as much as 219 possible with the terminology defined for CoAP [RFC7252]. However, 220 since the intended Application(s) play a crucial role within 221 constrained networks, we also refer to terminology used by OAuth 2.0 222 and UMA. Note that within a given constrained network, an device 223 make take multiple roles (client or server) depending on the exchange 224 and layers of the exchange in which they participate. 226 client 227 The client is the entity in a constrained environment seeking 228 to share a key pair-wise with the service principal. 230 service principal 231 The entity with whom the client seeks to establish a pair-wise 232 symmetric key is refereed to as the service principal (SP). 233 This terminology is used to avoid confusion as much as possible 234 with the generic term "server" or "service". 236 simple key distribution center 237 The simple key distribution center (SKDC) is the entity which 238 mediates the establishment of the pair-wise shared key between 239 the client and service principal. 241 miniticket 242 This is the data structure that carries the symmetric key to be 243 shared between the client and service principal. 245 receipt 246 This is the data structure that carries the symmetric key from 247 the SKDC to an entity (client or service principal). 249 authenticator 250 This is the data structure that carries proof-of-possession of 251 a shared symmetric key between two entities. 253 pair-wise shared key 254 A pair-wise shared key (PSK) is symmetric key shared only 255 between a client and service principal. 257 group shared key 258 A group shared key (GSK) is symmetric key shared by two or more 259 entities. 261 session encryption key 262 The session encryption key is the symmetric key generated by 263 the SKDC to be shared pair-wise between the client and the 264 service principal. A session encryption key is an instance of 265 a PSK. 267 group encryption key 268 The group encryption key is the symmetric key generated by the 269 SKDC to be shared among members of a multicast group. A group 270 encryption key is an instance of a GSK. 272 secret key 273 The secret key is the symmetric key that is uniquely shared 274 pair-wise between a client (or service principal) and the SKDC. 275 This term is borrowed from RFC4120. Thus, the client secret 276 key is the symmetric key that is uniquely shared pair-wise 277 between the client and the SKDC. The SP secret key is the 278 symmetric key that is uniquely shared pair-wise between the SP 279 and the SKDC. 281 set-up keying material 282 The cryptographic keying material (including possibly keys) 283 resulting from the initial on-boarding process of a device into 284 a constrained environment is referred to generally as "set-up 285 keying material". 287 permissions and access control 288 The permissions and access control (PAC) is the set of 289 information pertaining to permissions for entities within a 290 constrained environment. 292 resource 293 The resource refers to the end-point at the service principal 294 to which the application seeks access. 296 1.3. Design Considerations and Assumptions 298 There are a number of design considerations and background for the 299 current protocol. 301 Transport: We assume that the entities in the constrained 302 environment are deploying the CoAP protocol as transport 303 [RFC7252]. However, the design of the current protocol seeks to 304 be transport-independent as much as possible because we anticipate 305 that not all constrained networks may be running CoAP. 307 JSON data structures: The data structures in this specification are 308 expressed in JSON. We believe this provides the greatest 309 flexibility for the protocol to be integrated into existing 310 protocols for authorization (such as OAuth2.0 [Oauth2] and OpenID- 311 Connect [OIDC]) and consent management by the resource/device 312 owner (such as the User Managed Access (UMA) protocol [UMACORE]). 314 On-boarding and off-boarding: We assume that constrained devices 315 will undergo the phase of "on-boarding" into a constrained 316 environment. Similarly, "off-boarding" will be required when a 317 constrained device leaves (or is removed) from a constrained 318 environment. The notion of on-boarding is closely related to that 319 of "take-ownership" of certain types of devices. Technologies 320 such as the TPM [TPM] and EPID [EPID] play a crucial role in 321 providing both cryptographic proof (technical trust) and human 322 proof (social trust) in the process of changing the ownership of a 323 device when it is activated and introduced into a constrained 324 environment. We see a close relationship between on-boarding and 325 the current protocol for establishing PSKs and GSKs within a 326 constrained environment. 328 Secret key establishment or derivation: Following the on-boarding 329 process of a client (resulting in the client and SKDC possessing 330 set-up keying material), the client and the SKDC are assumed to 331 generated the secret key which is shared pair-wise between the 332 client and the SKDC. Methods include using PRFs and other one-way 333 functions. The exact process of generating a secret key from the 334 set-up keying material is out of scope of the current 335 specification. As such, the current Fluffy protocol begins with 336 the assumption that each entity (client and service principal) 337 already shares pair-wise a secret key with the SDKC. This secret 338 key should be used only for key-management related messages as 339 defined in this specification. Additionally, in this 340 specification we have avoided the use of the term "long-term key" 341 to refer to this secret key due to the broad meaning of this term. 343 Realms and zones: We have borrowed the notion of "realms" from 344 RFC4120 because we anticipate that a constrained environment may 345 consists of one or more physical networks, and which may be 346 arranged (logically or physically) into "zones". Furthermore, we 347 anticipate that in some use-cases the notion of a "realm" or 348 "zone" may be more ephemeral than is commonly understood for 349 RFC4120 deployments. Thus, there may be constrained use-cases 350 where realms or zones are short-lived. 352 1.4. Out of Scope and Non-Goals: 354 The following are out of scope (non-goals) for the current 355 specification: 357 Authorization and permissions: The issue of permissions and 358 authorization is out of scope for this specification. However, 359 the current specification anticipates the close integration 360 between permissions, authentication and key establishment. 362 Discovery: Discovery of endpoints, identities, services and other 363 aspects of a constrained environment is out of scope for the 364 current specification. 366 Backward compatibility with Kerberos: It is not a goal of this 367 specification to achieve backward compatibility with RFC1510 or 368 RFC4120. Similarly, it is not the goal of this specification to 369 be compatible with the MS-PAC [MSPAC] and MS-KILE [MSKILE] 370 specifications. 372 Pre-authentication: RFC4120, RFC4556 and RFC613 uses the term "pre- 373 authentication" to denote a client obtaining keying material for 374 its secret key prior executing the Kerberos. It is not a goal of 375 this specification to address pre-authentication. 377 Channel Binding for TLS and DTLS: Channel binding [RFC5929] for DTLS 378 or TLS are out of scope in the current specification. 380 Certificate Issuance and Management: Issuance of X509 digital 381 certificates and certificate management (in the sense of RFC2459, 382 RFC2797 and RFC4210) is out of scope in the current specification. 384 2. Common Building Blocks 386 The current protocol employs a number of data structures that are 387 common across several message types. A number of these data 388 structures have semantic equivalents in RFC4120, while some are newly 389 introduced. 391 Depending on the message type, some fields may be overloaded in its 392 usage. For example, in the PSK-Request message the client states the 393 identity and realm of the service principal within the SKDC-REQ-BODY. 394 This is similar to RFC4120 because three (3) parties are involved in 395 a PSK establishment (initiated by the client sending a PSK-Request 396 message to the SKDC). However, when the SKDC-REQ-BODY is used in GSK 397 establishment (initiated by an entity sending the SKDC a GSK-Request 398 (GSK-REQ) message) the identity and realm fields are used instead to 399 communicate the desired identity and the realm of the multicast 400 group. 402 Two building blocks that do not have equivalents in RFC4120 are the 403 Key Data and the Key Envelope structures: 405 Key Data: The keydata structure is used to convey cryptographic 406 key(s) together with the associated operational parameters for the 407 key(s). The structure of the keydata follows the JSON Web Key 408 (JWK) definition of keys and keying material [RFC7517]. This is a 409 departure from RFC4120. 411 Key Envelope: The key envelope is used to convey parameters 412 related to a key (e.g. KeyID) but not the key itself. It is used 413 in cases where entities need to refer to a key (e.g. group-key) 414 without having to carry the key in the message. 416 In the following the common building blocks are discussed. 418 2.1. SKDC Request Body 420 The SKDC request body (SKDC-REQ-BODY) carries specific information 421 regarding the type of request and the entities involved in the 422 message. This data structure is used in the initial request send 423 from a client (or SP) to the SKDC. 425 The SKDC-REQ-BODY varies slightly when used in the PSK-REQ and GSK- 426 REQ messages. 428 SKDC-REQ-BODY: 430 o Key Type (kty): This denotes the type of key being requested by 431 the sender (client or SP) of the request. 433 o Desired algorithm (etype): This is the algorithm that is desired 434 (or supported) by the sender of the request (client or SP) . 436 o SKDC options - optional (skdc-options): These are flags that are 437 intended for the SKDC only. This field is optional. 439 o SKDCs realm (skdcrealm): This the name of the realm, domain or 440 zone of the SKDC. 442 o SKDC's identity (skdcname): This is the identity of the SKDC. 444 o Service principal's realm - optional (sprealm): This the name of 445 the realm, domain or zone of the service principal in a PSK-REQ 446 message. In a GSK-REQ message it is the realm of the multicast 447 group. This field is optional. 449 o Service principal's identity (spname): In a PSK-REQ message this 450 is the identity of the service principal. In a GSK-REQ message it 451 is the identity or name of the multicast group. 453 o Client permissions - optional (cpac): In a PSK-REQ message this is 454 the permisions desired by the client for itself. In a GSK-REQ 455 message this is the permisions desired by the client for the 456 multicast group. This field is optional. 458 2.2. Miniticket 460 The miniticket is always created by the SKDC and is always intended 461 for the service principal (although it is delivered via the client 462 who initiates with the PSK-REQ message). The SKDC responds to the 463 client by sending a PSK-Response (PSK-REP) message containing the 464 miniticket and a receipt. The miniticket contains a copy of the 465 session encryption key to be delivered to the service principal by 466 the client in a PSK-Establish (PSK-ESTB) message. As such, the 467 sensitive parts (enc-part) of the miniticket is encrypted using the 468 service principal's secret key (which it shares pair-wise with the 469 KDC). The miniticket is functionally equivalent to the service- 470 ticket in RFC4120. 472 The miniticket contains the following: 474 o Issuing SKDC's realm (skdcrealm): This the name of the realm, 475 domain or zone of the SKDC that issued this miniticket. 477 o Issuing SKDC's identity (skdcname): This is the identity of the 478 SKDC that issued this miniticket. 480 o Service principal's realm - optional (sprealm): This the name of 481 the realm, domain or zone of the service principal for whom this 482 miniticket is destined. This field is optional. 484 o Service Principal's identity (spname): This is the identity of the 485 service principal for whom this miniticket is destined. 487 o Encrypted miniticket part (enc-part): This is the encrypted part 488 of the miniticket intended for the service principal. It is 489 encrypted using the secret key shared pair-wise between the SKDC 490 and the service principal. The encrypted part contains the 491 following: 493 * Ticket flags - optional (tflags): This is the flags set by the 494 SKDC for the service principal concerning this ticket. This 495 field is optional. 497 * Client's realm (crealm): This the name of the realm, domain or 498 zone of the client with whom the receiver of this miniticket 499 shares the enclosed key. 501 * Client's identity (cname): This is the identity of the client 502 with whom the receiver of this miniticket shares the enclosed 503 key. 505 * Client permissions - optional (cpac): This is the permissions 506 and access control (PAC) structure containing permissions 507 granted to the client associated with the enclosed key. This 508 field is optional. 510 * Time of authentication (authtime): This is the time at the SKDC 511 when it created this miniticket in response to a request. 513 * Expiration time of key (endtime): The is the expiration time of 514 the key in this miniticket. 516 * Service principal permissions - optional (sppac): This is the 517 permissions and access control (PAC) structure granted to the 518 service principal associated with the enclosed key. This field 519 is optional. 521 * Transited realms - optional (transited): This is the set of 522 SKDCs and realms that was involved in the issuance of the 523 miniticket for the service principal. This field is used for 524 cross-realm ticket issuance. This field is optional. 526 * Key data (keydata): This fields contains the key-data structure 527 that carries the cryptographic key and other parameters 528 necessary for operating the key. See section Section 2.6 for 529 the key-data structure. 531 2.3. Receipt 533 The receipt is always created by the SKDC and is used for the SKDC to 534 deliver a key to a requesting party (be it client, service principal 535 or multicast group members). The receipt is functionally equivalent 536 to the SKDC-Response part in RFC4120. 538 In The PSK estabslishment flows the receipt is used to deliver the 539 new session encryption key to the requesting client in a PSK-REP 540 message from the SKDC. 542 In The GSK establishment flows the receipt is used to deliver the new 543 group encryption key to the requesting entity using the GSK-Response 544 (GSK-REP) message. Similarly, members of a multicast group must 545 individually request a copy of the group key using the GSK-Fetch 546 message (GSK-FET), to which the SDKC will send a receipt structure 547 containing a copy of the group key via the GSK-Deliver (GSK-DLVR) 548 message. 550 When used in a PSK-REP message as a response to the client's request 551 for a new session encryption key, the receipt names the service 552 principal who is to share the key with the client. The service 553 principal identified in this receipt is the same as that stated in 554 the matching miniticket. 556 When used in a GSK-REP message for a new group-key creation, the 557 receipt instead names the multicast group with associated with this 558 key. Note that the GSK-REP message has no accompanying miniticket 559 because the SKDC is reponding solely to the requester of the new 560 group-key in a 2-party flow. The receipt in a GSK-Deliver (GSK-DLVR) 561 message (to deliver a copy of the group-key to members of the 562 multicast group) is functionally identical to the receipt in the GSK- 563 REP message. 565 A note about convention: in the remainder of this specification the 566 entity that requests the creation of a group-key is denoted as the 567 service principal (SP). The members of the multicast group are 568 denoted as the client. 570 Receipt: 572 o Receipts flags - optional (rflags): This is the flags set by the 573 SKDC concerning this receipt. This field is optional. 575 o Issuing SKDC's realm (skdcrealm): This the name of the realm, 576 domain or zone of the SKDC that issued this receipt. 578 o Issuing SKDC's identity (skdcname): This is the identity of the 579 SKDC that issued this receipt. 581 o Realm - optional (sprealm or mcastrealm): This field is optional, 582 and is used as follows: 584 * sprealm: In a PSK-REP message, sprealm is used. This is the 585 name of the realm, domain or zone of the service principal with 586 whom the client (recipient of this receipt) shares the enclosed 587 session encryption key. 589 * mcastrealm: In a GSK-REP message and GSK-DLVR message, the 590 mcastrealm is used. This is the realm of the multicast group 591 associated with the enclose group encryption key. 593 o Name of entity sharing this key (spname or mcastname): 595 * spname: In a PSK-REP message, spname is used. This is the 596 identity of the service principal who will be sharing the 597 enclosed session encryption key with requesting client. 599 * mcastname: In a GSK-REP message and GSK-DLVR message, mcastname 600 is used. This is the identity of the multicast group 601 associated with the enclosed group encryption key. 603 o Service Principal's SKDC - optional (spskdc): This field is 604 optional. In a PSK-REP message, this is the identity of the 605 service principal's SKDC. This field is absent in receipts used 606 in a GSK-REP message or GSK-DLVR message. 608 o Permissions - optional (cpac or grppac): This field is optional. 609 This is the permissions and access control (PAC) structure 610 containing permissions granted, associated with the enclosed key. 612 * cpac: In a PSK-REP message, the permissions pertains to the 613 client who requested the session encryption key. 615 * grppac: In a GSK-REP message or GSK-DLVR message, the 616 permissions pertain to the members of the multicast group who 617 share this common group encryption key. 619 o Time of authentication (authtime): This is the time at the SKDC 620 when it created this receipt. 622 o Nonce from the sender's request (nonce): This is the nonce found 623 in the previous request message (either PSK-REQ message or GSK-REQ 624 message). 626 o Expiration time of key (endtime): The is the expiration time of 627 the key in this receipt. 629 o Key data (keydata): This fields contains the key-data structure 630 that carries the cryptographic key and other parameters necessary 631 for operating the key. In a PSK-REP message, this key is the 632 session encryption key to be shared between the client and service 633 principal. In a GSK-REP message or GSK-DLVR message this is the 634 group encryption key to be shared by the multicast group members. 635 See section Section 2.6 for the key-data structure. 637 2.4. Authenticator 639 The authenticator is used by a sender to provide proof-of-possession 640 (POP) to a receiver of a given key that the sender shares with the 641 receiver. The authenticator here is functionally equivalent to the 642 authenticator in RFC4120. 644 In the PSK-REQ and GSK-REQ messages, the requesting entity uses the 645 authenticator to "authenticate" itself to the SKDC by providing 646 proof-of-possession of the secret key which it shares pair-wise with 647 the SKDC. Note that this mode of usage of the authenticator departs 648 from RFC4120 where a key request message (namely the AP-REQ in 649 RFC4120) is not accompanied by an authenticator. 651 In the PSK establishment flows, the authenticator is used also in the 652 PSK-ESTB message that is sent from the client to the service 653 principal. More specifically, in the PSK-ESTB message the client 654 encrypts the authenticator using the session encryption key that the 655 client obtained in the previous PSK-REP message it received from the 656 SKDC. Here the authenticator proves to the service principal that 657 the client knows the session encryption key that is enclosed in the 658 accompanying miniticket. 660 The authenticator is also used in the PSK deletion and GSK deletion 661 flows where the SKDC accompanies its PSK-DELT and GSK-DELT messages 662 respectively with an authenticator that proves to the intended 663 recipient of the message that the SKDC knows the secret key shared 664 pair-wise with that recipient. As such, the authenticator can be 665 used as a generic mechanism to provide proof-of-possession of a 666 shared key between two entities. 668 Using the example of a client sending an authenticator to a service 669 principal, the authenticator contains the following: 671 o Client's realm (crealm): This the identity of the realm, domain or 672 zone of the client that created the authenticator. 674 o Client's identity (cname): This is the identity of the client that 675 created the authenticator. 677 o Client's current time (ctime): This is the time at the client when 678 it created the authenticator. 680 o Nonce (nonce): This is a new nonce generated by the client (for 681 the recipient of the authenticator). 683 o Sequence number - optional (seqnum): This is the sequence number 684 used by the client to detect attacks. This field is optional. 686 o Checksum - optional (cksum): This is the keyed-checksum (based on 687 the session encryption key) used by the client as sender. This 688 field is optional. 690 2.5. Acknowledgement 692 The acknowledgement structure (ack) is used by one entity to send a 693 positive acknowledgement to another entity regarding a message that 694 was previously exchanged. The acknowledgement would carry a nonce 695 that was found in the related previous message. The type of 696 acknowledgement is expressed in the enveloping header message (e.g. 697 PSK-ACK type acknowleges a previous PSK-ESTB message). 699 Note that the acknowledgement structure is intended to be generic, 700 and as such can also be used by the SKDC to send an acknowledgement 701 to a client or service principal. 703 Using the example of a service principal (sender) sending the an 704 acknowledgement to a client (receiver), the acknowledgement structure 705 contains the following: 707 o Service principal's realm - optional (sprealm): This the identity 708 of the realm, domain or zone of the service principal who created 709 this acknowledment. This field is optional. 711 o Service Principal's identity (spname): This is the identity of the 712 service principal for who created this acknowledgement. 714 o Nonce from the client's previous message (nonce): This is the 715 nonce found in the previous message being acknowledged. 717 o Time of authentication (authtime): This is the time at the service 718 principal when it created this acknowledgement message. 720 o Sequence number - optional (seqnum): This is the sequence number 721 used to detect attacks. This field is optional. 723 2.6. Key Data 725 The key-data structure is used to carry cryptographic keys and the 726 related parameters needed to operate the keys. The construction of 727 the key-data structure follows that of the JSON Web Keys [RFC7517] 728 which supports not only symmetric keys, but also public key pairs and 729 X509 certificates. 731 The intent is to support the delivery of either a single symmetric 732 key, a public key pair or one key (half) of a public key pair. 734 Delivery of an array of keys is for future consideration. 736 2.6.1. Symmetric Key Data 738 The key-data structure for carrying a symmetric key is as follows. 740 o Key type (kty): This is the type of key contained in the current 741 key-data structure. 743 o Key ID - optional (keyid): This is the name or handle for the key 744 that can be be referred to by parties sharing they key. This 745 field is optional. 747 o Key (key): This is the symmetric key. 749 o Key operations parameters (keyops): This is parameters required to 750 operate the cryptographic key. 752 o Algorithm (alg): This is the algorithm name for the use of the 753 key. 755 2.6.2. Asymmetric Key Data 757 The key-data structure for carrying an asymmetric key and parameters 758 is as follows. 760 o Key type (kty): This is the type of key contained in the current 761 key-data structure. 763 o Key ID - optional (keyid): This is the name or handle for the key 764 that can be be referred to by parties sharing they key. This 765 field is optional. 767 o Key (key): This is the public key. 769 o Key operations parameters (keyops): This is parameters required to 770 operate the cryptographic key. 772 o Algorithm (alg): This is the algorithm name for the use of the 773 key. 775 o Public key usage (pkuse): For public keys this field indicates the 776 use of the key. See RFC7517. 778 o X509 URL parameter (x5u): This parameter is a URI [RFC3986] that 779 refers to a resource for an X.509 public key certificate or 780 certificate chain [RFC5280]. See RFC7517. 782 o X509 certificate chains parameter - optional (x5c): This parameter 783 contains a chain of one or more PKIX certificates [RFC5280]. See 784 RFC7517. 786 o X509 thumbprint parameter - optional (x5t): This parameter 787 contains a base64url-encoded SHA-1 thumbprint (a.k.a. digest) of 788 the DER encoding of an X.509 certificate [RFC5280]. See RFC7517. 790 o X509 SHA256 thumbprint parameter - optional (x5t256): This 791 parameter contains a base64url-encoded SHA-256 thumbprint (a.k.a. 792 digest) of the DER encoding of an X.509 certificate [RFC5280]. 793 See RFC7517. 795 2.7. Key Envelope 797 The key envelope structure is used in messages that refer to a 798 cryptographic key by its KeyID. As such, the key envelope structure 799 by definition must never carry any cryptographic keys or keying 800 material. 802 The key envelope is used primarily in the deletion of a a PSK or a 803 GSK. When the SKDC wishes to delete a given PSK that it shares with 804 an entity, it can refer to the target key by way of the KeyID in the 805 key envelope. 807 In order to delete a PSK that a client and service principal shares 808 (through the mediation of the SKDC via a previous 3-party PSK 809 establishment flow), the SKDC must separately delete the PSK at the 810 client and at the service principal (i.e. using two separate PSK- 811 Delete (PSK-DELT) messages). 813 The key envelope is encrypted using the secret key shared between the 814 SKDC and the entity (client or service principal) for whom the 815 envelope is destined. 817 The key envelope must never be encrypted using the target key that is 818 to be deleted. 820 The key envelope structure contains the following: 822 o Envelope Flags - optional (envflags): This is the flags related to 823 the envelope. This field is optional. 825 o Issuing SKDC's realm (skdcrealm): This the name of the realm, 826 domain or zone of the SKDC that issued this envelope. 828 o Issuing SKDC's identity (skdcname): This is the identity of the 829 SKDC that issued this envelope. 831 o Current time (authtime): This is the time at the SKDC when it 832 created the encrypted envelope. 834 o Nonce (nonce): This is a new nonce generated by the SKDC (for the 835 recipient of the envelope). 837 o Sequence number - optional (seqnum): This is the sequence number 838 to detect attacks. This field is optional. 840 o Key data (keydata): This is the key-data structure which contains 841 the KeyID of the target key. The key-data in a key envelope must 842 not contain any cryptographic keys. See section Section 2.6 for 843 the key-data structure. 845 3. Pair-wise Shared Key Establishment 847 This section describes the pair-wise key establishment between the 848 client and the service principal. 850 3.1. Basic Protocol Exchange 852 Prior to executing the Fluffy protocol, a client must first be in 853 possession of a secret key that it shares pair-wise with the SKDC. 854 The process or method of obtaining the client secret key is outside 855 the scope of the current specification, but for a device operating 856 within a constrained environment this may be a direct consequence of 857 the on-boarding or take-ownership process. 859 The PSK establishment consists of a 4-message flow from the client to 860 SKDC, the SKDC back to the client, and between the client and the 861 service principal. 863 Note that unlike RFC4120, the client must provide an authenticator in 864 its first message (PSK-Request) to the SKDC. This authenticator is 865 encrypted by the client using the secret key it shares pair-wise with 866 the SKDC. 868 The message flows consists of the following steps and are summarized 869 in Figure 1. 871 o PSK-Request (PSK-REQ): The client sends a PSK-Request message to 872 the SKDC asking for the SKDC to mediate the sharing of a new 873 session encryption key between the client and the service 874 principal. The client must indicate the intended service 875 principal in this message. Unlike RFC4120 the client must include 876 an authenticator that is encrypted to the SKDC as a proof of 877 possession of the secret key it shares with the SKDC. 879 o PSK-Response (PSK-REP): The SKDC responds by generating a new 880 session encryption key and placing the key into a miniticket 881 intended for the service principal. The miniticket is encrypted 882 using the secret key which is pair-wise shared only between the 883 SKDC and the service principal. Additionally, the SKDC places a 884 copy of this new session encryption key into a receipt structure, 885 and encrypting it using the secret key pair-wise shared between 886 the SKDC and the client. Both the miniticket and the receipt are 887 then returned to the client. The client must forward the 888 miniticket unmodified to the service principal in the PSK- 889 Establish message. 891 o PSK-Establish (PSK-ESTB): The client then decrypts the receipt to 892 obtain the session encryption key. The client uses this session 893 encryption key to encrypt an authenticator structure as proof of 894 possession for the service principal. The client then sends the 895 authenticator and the miniticket (unmodified from the SKDC) to the 896 service principal. The service principal decrypts the miniticket 897 to obtain the session encryption key, and then it uses the session 898 encryption key to verify the authenticator (by decrypting it). At 899 this point the client and the service principal shares the session 900 encryption key. 902 o PSK-Acknowledge (PSK-ACK): The service principal exercises the 903 newly received session encryption key by encrypting an 904 acknowledgement message to the client. 906 Similar to RC4120, the integrity of the messages containing cleartext 907 data is protected using a checksum mechanism (e.g. keyed hash) based 908 on the client's secret key [RFC3961]. 910 The PSK Establishment Flows 912 +------------+ +--------------+ 913 | | | | 914 | |-----(1) PSK-Request ---->| | 915 | | | SKDC | 916 | |<---(2) PSK-Response -----| | 917 | | | | 918 | Client | +--------------+ 919 | | 920 | | +--------------+ 921 | |---- (3)PSK-Establish --->| | 922 | | | SP | 923 | |<--- (4)PSK-Acknowledge --| | 924 | | | | 925 +------------+ +--------------+ 927 Figure 1 929 The message components as used in the protocol are summarized in 930 Figure 2. Note that all protocol messages are integrity-protected, 931 and some are encrypted. 933 The PSK Message Components 935 Client SKDC 936 | | 937 | | 938 | -------- (1) PSK-REQ, SKDC-REQ-BODY ------> | 939 | | 940 | <--- (2) PSK-REP, Miniticket*, Receipt* --- | 941 | | 942 | | 944 Client SP 945 | | 946 | | 947 | -(3) PSK-ESTB, Miniticket*, Authenticator* --> | 948 | | 949 | <----- (4) PSK-ACK, Acknowledgement* -------- | 950 | | 952 Figure 2 954 3.2. PSK-Request Message (PSK-REQ) 956 The PSK-Request (PSK-REQ) message is sent from the client to the SKDC 957 asking for the SKDC to mediate the establishment of a pair-wise 958 shared key between the client and the service principal. The client 959 must indicate the intended service principal in this message. 961 o Protocol version (pvno): This the version of the protocol. 963 o Message type (msg-type): The message type for this message is 964 "PSK-REQ". 966 o SKDC request body (req-body): The request body contains the 967 parameters required by the SKDC to mediate key establishment for 968 the client. See Section Section 2.1 for more information on the 969 SKDC request body. The SKDC request body of a PSK-REQ message 970 contains the following: 972 * Key Type (kty): This is type of key being requested by the 973 client from the SKDC. 975 * Desired algorithm (etype): This is the algorithm that is 976 desired (or supported) by the client. 978 * SKDC options - optional (skdc-options). 980 * SKDC's realm (skdcrealm). 982 * SKDC's identity (skdcname). 984 * Service principal's realm - optional (sprealm). 986 * Service principal's identity (spname). 988 * Client permissions - optional (cpac). 990 o Authenticator (authenticator): This is the authenticator encrypted 991 by the client to the SKDC using the secret key that the client 992 shares with the SKDC. See Section Section 2.4 for more 993 information on the authenticator structure. 995 o Extensions - optional (ext): Reserved for future extensions. This 996 field is optional. 998 3.3. PSK-Response Message (PSK-REP) 1000 The PSK-Response (PSK-REP) is sent by the SKDC to the client as a 1001 response to the client's previous PSK-REQ message. The PSK-REP 1002 message carries two crucial data structures, namely the miniticket 1003 and the receipt. 1005 The miniticket here is intended solely for the service principal and 1006 carries a copy of the session encryption key (key) intended for the 1007 service principal. As such the miniticket is encrypted to the 1008 service principal using the secret key shared between the SKDC and 1009 service principal. Although the miniticket is returned to the 1010 client, the client is unable to view or modify the encrypted parts of 1011 the miniticket. 1013 The receipt here is intended solely for the client and carries a copy 1014 of the session encryption key (key) intended for the client. The 1015 receipt is encrypted to the client using the secret key shared 1016 between the SKDC and client. 1018 The PSK-REP message contains the following: 1020 o Protocol version (pvno): This the version of the protocol. 1022 o Message type (msg-type): The message type for this message is 1023 "PSK-REP". 1025 o Client's realm (crealm): This the name of the realm, domain or 1026 zone in which the client belongs in connection to this request. 1028 o Client's identity (cname): This is the identity of the client. 1030 o Miniticket (mticket): The miniticket contains the following: 1032 * Issuing SKDC's realm (skdcrealm). 1034 * Issuing SKDC's identity (skdcname). 1036 * Service principal's realm - optional (sprealm). 1038 * Service Principal's identity (spname). 1040 * Encrypted miniticket part (enc-part): This is the part of the 1041 PSK-REP message that is encrypted by the SKDC to the service 1042 principal, using the secret key that the SKDC shares pair-wise 1043 with the service principal. It contains the following: 1045 + Ticket flags - optional (tflags). 1047 + Client's realm (crealm): This the name of the realm, domain 1048 or zone in which the client belongs in connection to this 1049 request. 1051 + Client's identity (cname). 1053 + Client permissions - optional (cpac). 1055 + Time of authentication (authtime). 1057 + Expiration time of this key (endtime). 1059 + Service principal permissions - optional (sppac). 1061 + Transited realms - optional (transited). 1063 + Key data (keydata): This key-data structure contains a copy 1064 of the session encryption key destined for the service 1065 principal. See section Section 2.6 for the key-data 1066 structure. 1068 o Receipt (receipt): This is the part of the PSK-REP message that is 1069 encrypted by the SKDC to the client, using the secret key that the 1070 SKDC shares pair-wise with the client. It contains the following: 1072 * Receipts flags - optional (tflags). 1074 * Issuing SKDC's realm (skdcrealm). 1076 * Issuing SKDC's identity (skdcname). 1078 * Service principal's realm - optional (sprealm). 1080 * Service Principal's identity (spname). 1082 * Service Principal's SKDC - optional (spskdc). 1084 * Client permissions - optional (cpac). 1086 * Time of authentication (authtime). 1088 * Nonce from the Client's previous PSK-REQ request message 1089 (nonce). 1091 * Expiration time of this key (endtime). 1093 * Key data (keydata): This key-data structure contains a copy of 1094 the session encryption key destined for the client. See 1095 section Section 2.6 for the key-data structure. 1097 o Extensions - optional (ext): Reserved for future extensions. This 1098 field is optional. 1100 3.4. PSK-Establish Message (PSK-ESTB) 1102 The PSK-Establish (PSK-ESTB) message is sent from the client to the 1103 service principal requesting it to share a key (i.e. the session 1104 encryption key). The PSK-ESTB message contains two parts. The first 1105 is the miniticket obtained by the client from the SKDC in the 1106 previous PSK-Response (PSK-REP) message. 1108 The second is the authenticator created by the client. The 1109 authenticator is encrypted using the session encryption key which the 1110 client obtained in the receipt from the previous PSK-REP from the 1111 SKDC). 1113 The authenticator proves to the service principal that the client is 1114 in possession of the session encryption key. 1116 This PSK-ESTB message is sent by the client to the service principal. 1117 It contains the following: 1119 o Protocol version (pvno): This the version of the protocol. 1121 o Message type (msg-type): The message type for this message is 1122 "PSK-ESTB". 1124 o Client's realm (crealm): This the name of the realm, domain or 1125 zone of the client. 1127 o Client's identity (cname): This is the identity of the client. 1129 o Miniticket (mticket): This is the miniticket structure 1130 (unmodified) that the client received from the SKDC in the 1131 previous PSK-REP message. See Section Section 3.3 for the 1132 miniticket in the PSK-REP message. 1134 o Authenticator: The authenticator in the PSK-ESTB contains the 1135 following: 1137 * Client's realm (crealm). 1139 * Client's identity (cname). 1141 * Client's current time (ctime). 1143 * A new nonce generated by the client for the service principal 1144 (nonce). 1146 * Sequence number - optional (seqnum). 1148 * Checksum - optional (cksum). 1150 o Extensions - optional (ext): Reserved for future extensions. This 1151 field is optional. 1153 3.5. PSK-Acknowledge Message (PSK-ACK) 1155 The PSK-Acknowledge (PSK-ACK) message is sent from the service 1156 principal to the client in response to the previous PSK-ESTB message. 1158 The message contains an acknowledgement part that is encrypted by the 1159 service principal using the session encryption key (which the service 1160 principal obtained in the miniticket in the previous PSK-ESTB 1161 message). 1163 The PSK-ACK message contains the following: 1165 o Protocol version (pvno): This the version of the protocol. 1167 o Message type (msg-type): The message type for this message is 1168 "PSK-ACK". 1170 o Client's realm (crealm). 1172 o Client's identity (cname). 1174 o Acknowledgement (ack): This is the acknowledgement structure that 1175 contains the following: 1177 * Service principal's identity (spname). 1179 * Service principal's realm - optional (sprealm). 1181 * Nonce from the Client's previous PSK-ESTB message (nonce). 1183 * Time of authentication (authtime). 1185 * Sequence number (inremented) from PSK-ESTB message - optional 1186 (seqnum). 1188 o Extensions - optional (ext): Reserved for future extensions. This 1189 field is optional. 1191 4. Pair-wise Shared Key Deletion 1193 The current protocol supports the proactive deletion by the SKDC of a 1194 pairwise shared key (PSK) prior to the expiration of the key. The 1195 target PSK to be deleted must be a PSK that a client and service 1196 principal had established through the mediation of the SKDC using the 1197 PSK establishment flow. 1199 Only the SKDC has the authority to send a key-deletion message (PSK- 1200 DELT) to an entity (client or service principal). A client or 1201 service principal MUST ignore key-deletion messages which did not 1202 come from the SKDC. 1204 The SKDC authenticates itself to the client (service principal) by 1205 including a key envelope that is encrypted using the secret key 1206 shared between the SKDC and the client (service principal). The key 1207 envelope identifies the target key to be deleted by its key-ID. 1209 If a PSK-DELT message issued by the SKDC is received at the client 1210 after the named key has in fact expired, the client must still 1211 respond with a PSK-Delete-Confirm (PSK-DELC) message. This confirms 1212 to the SKDC that the named key no longer exists at the client. 1214 In order to delete a PSK that a client and service principal shares 1215 (through the mediation of the SKDC via a PSK establishment flow), the 1216 SKDC must delete the PSK at the client and at the service principal 1217 separately (using two separate PSK-DELT messages respectively). 1219 The message components as used in the protocol are summarized in 1220 Figure 3. 1222 The PSK Delete Message Components 1224 SKDC Client 1225 | | 1226 | | 1227 | ------- (1) PSK-DELT, Kenvelope* --------> | 1228 | | 1229 | <--- (2) PSK-DELC, Acknowledgement* ------- | 1230 | | 1231 | | 1233 Figure 3 1235 4.1. PSK-Delete Message (PSK-DELT) 1237 The PSK-DELT message is sent from the SKDC to a client (or service 1238 principal) asking for the delition or erasure of the PSK identified 1239 in the message. The SKDC must indicate the intended recipient in 1240 this message. 1242 o Protocol version (pvno): This is the version of the protocol. 1244 o Message type (msg-type): The message type for this message is 1245 "PSK-DELT". 1247 o Client's realm (crealm): This the identity of the realm, domain or 1248 group in which the client belongs in connection to this request. 1250 o Client's identity (cname): This is the identity of the client. 1252 o Key Envelope (kenvelope): The key envelope is encrypted using the 1253 client's secret key that it shared with the SKDC. The key 1254 envelope contains the following: 1256 * Envelope Flags - optional (envflags). 1258 * Issuing SKDC's realm (skdcrealm). 1260 * Issuing SKDC's identity (skdcname). 1262 * Current time (authtime). 1264 * New nonce generated by the SKDC (nonce). 1266 * Sequence number - optional (seqnum). 1268 * Key data (keydata): This key-data structure contains the KeyID 1269 of the target key to be deleted. The key-data in a key 1270 envelope must never contain a cryptographic key. See section 1271 Section 2.6 for the key-data structure. 1273 o Extensions - optional (ext): Reserved for future extensions. This 1274 field is optional. 1276 4.2. PSK-Delete-Confirm Message (PSK-DELC) 1278 The psk-delete-confirm (PSK-DELC) message is sent from the client (or 1279 service) to the SKDC confirming the removal of the PSK identified in 1280 the previous PSK-DELT message. A client (or service principal) must 1281 only send the PSK-DELC message after it has successfully remove or 1282 erase the target key from its key store. 1284 The acknowledgement in the PSK-DELC message is encrypted by the 1285 client using the secret key that the client shares with the SKDC. 1286 See Section Section 2.5 for more information on the acknowledgement 1287 structure. 1289 The PSK-DELC message contains the following: 1291 o Protocol version (pvno): This is the version of the protocol. 1293 o Message type (msg-type): The message type for this message is 1294 "PSK-DELC". 1296 o SKDC's realm - optional (skdcrealm). 1298 o SKDC's identity (skdcname). 1300 o Acknowledgement (ack): 1302 * Client's identity (cname). 1304 * Client's realm - optional (crealm). 1306 * Nonce from the SKDC's previous PSK-DELT message (nonce). 1308 * Client's current time (authtime). 1310 * Sequence number - optional (seqnum): This field is optional. 1312 o Extensions - optional (ext): Reserved for future extensions. This 1313 field is optional. 1315 5. Group Shared Key Establishment 1317 The current protocol supports the establishment of a group-shared 1318 symmetric key (referred to as the "group encryption key" or "group- 1319 key") among a number of entities within a constrained environment. 1320 The group encryption key affords group-authenticity for messages but 1321 not source-authenticity since the symmetric key is shared among 1322 multiple entities (members of the multicast group). See RFC3740 for 1323 further discussion regarding multicast group security. 1325 In the following we use the notation of the service principal (SP) as 1326 the entity that initiates the multicast group creation by requesting 1327 the SKDC to create a new group encryption key and to maintain a copy 1328 of that group-key until such time it expires or is deleted. The 1329 clients that request and obtain a copy of the group-key are denoted 1330 as "members" of the group. The current specification follows the 1331 convention that only the group-creator and the SKDC are permitted to 1332 proactively delete a group encryption key. 1334 Using the service principal as the group-creator, the service 1335 principal must accompany its request to the SKDC with an 1336 authenticator. 1338 Each group encryption key is associated with an owner (creator) who 1339 requested its creation at the SKDC. When an SP seeks to establish a 1340 new group encryption key, it sends a GSK-Request message to the SKDC 1341 asking that the SKDC generate a new symmetric key (i.e. the group 1342 encryption key), return a copy of the group encryption key to the 1343 service principal (via a receipt inside a GSK-Response message) and 1344 for the SKDC to retain a copy of the group key (for subsequent 1345 fetches by the clients). The sensitive parameters of the GSK- 1346 Response message (including the group encryption key) inside the 1347 receipt is encrypted using the secret key pair-wise shared between 1348 the SP and the SKDC. 1350 When a client seeks to obtain a copy of a group encryption key 1351 associated with a multicast group, the client sends a GSK-Fetch 1352 message to the SKDC identifying the multicast group (mcastname) of 1353 interest. The requesting client must accompany the request with an 1354 authenticator that is encrypted using the secret key shared between 1355 the client and the SKDC. 1357 If a corresponding group or group encryption key does not exist at 1358 the SKDC, the SKDC returns an error message. Otherwise, the SKDC 1359 returns a copy of the group encryption key (inside a receipt) to the 1360 requesting client using the GSK-Deliver message. The sensitive 1361 parameters of the GSK-Deliver message (including the group encryption 1362 key) inside the receipt is encrypted using the secret key pair-wise 1363 shared between the requesting client and the SKDC. 1365 The GSK Establishment Flows 1367 +------------+ +--------------+ 1368 | | | | 1369 | |-----(1) GSK-Request ---->| | 1370 | SP | | | 1371 | |<---(2) GSK-Response -----| | 1372 | | | | 1373 | | | | 1374 +------------+ | | 1375 | | SKDC | 1376 | | | 1377 | multicast | | 1378 v | | 1379 +------------+ | | 1380 | | | | 1381 | |---- (3) GSK-Fetch ----->| | 1382 | Client | | | 1383 | |<-- (4) GSK-Deliver ----| | 1384 | | | | 1385 +------------+ +--------------+ 1387 Figure 4 1389 The GSK establishment in the protocol consists of two sets of 1390 2-messages each: 1392 o Creation of the group-key at the SKDC: 1394 * GSK-Request: A service principal sends a GSK-Request (GSK-REQ) 1395 message to the SKDC asking for a new group key to be created. 1396 The service principal provides the desired name (mcastname) of 1397 the multicast group. It must accompany the request with an 1398 authenticator to the SKDC. After generating the new group-key 1399 the SKDC retains a copy of the group-key (until it expires) and 1400 associates it with the multicast group name (mcastname). 1402 * GSK-Response: The requesting service principal obtains a copy 1403 of the new group-key via the GSK-Response (GSK-REP) message 1404 from the SKDC. A receipt structure to carries the group-key. 1405 The receipt is encrypted by the SKDC using the secret key it 1406 shares with the service principal. 1408 o Fetching of a copy of the group-key from the SKDC: 1410 * GSK-Fetch: To request a copy of the group-key, a client sends 1411 the GSK-Fetch (GSK-FET) message to the SKDC with an 1412 authenticator. The client must indicate the desired multicast 1413 group (mcastname) in the GSK-FET message. 1415 * GSK-Deliver: The SKDC returns a copy of the group-key to the 1416 client via the GSK-Deliver (GSK-DLVR) message. A receipt 1417 structure to carries the group-key. The receipt is encrypted 1418 by the SKDC using the secret key it shares with the client. 1420 The message components as used in the protocol are summarized in 1421 Figure 5. Note that all protocol messages are integrity-protected, 1422 and some are encrypted. 1424 The GSK Message Components 1426 SP (Sender) SKDC 1427 | | 1428 | | 1429 | -- (1) GSK-REQ, SKDC-REQ-BODY, Authenticator* --> | 1430 | | 1431 | <----------- (2) GSK-REP, Receipt* -------------- | 1432 | | 1433 | | 1435 Client (Receiver) SKDC 1436 | | 1437 | | 1438 | -- (1) GSK-FET, SKDC-REQ-BODY, Authenticator* --> | 1439 | | 1440 | <---------- (2) GSK-DLVR, Receipt* -------------- | 1441 | | 1442 | | 1444 Figure 5 1446 5.1. GSK-Request Message (GSK-REQ) 1448 The GSK-Request message is sent from the service principal to the 1449 SKDC asking the SKDC to create a new group-key. The service 1450 principal authenticates itself to the SKDC by including an 1451 authenticator in the GSK-REQ message. 1453 The contents of the GSK-REQ message is as follows: 1455 o Protocol version (pvno): This the version of the protocol. 1457 o Message type (msg-type): The message type for this message is 1458 "GSK-REQ". 1460 o SKDC request body (req-body): The request body contains the 1461 parameters related to the group-key and multicast group. See 1462 Section Section 2.1 for more information on the SKDC request body. 1463 The SKDC request body in a GSK-REQ message contains the following: 1465 * Key Type (kty): This is type of key being requested. For a 1466 group shared key the type is "SYMM". 1468 * Desired algorithm (etype): This is the algorithm that is 1469 desired (or supported) by the service principal. 1471 * SKDC options - optional (skdc-options). 1473 * SKDC's realm (skdcrealm). 1475 * SKDC's identity (skdcname). 1477 * Multicast group realm - optional (mcastrealm): This is the 1478 desired realm name associated with the multicast group. 1480 * Multicast group identity (mcastname): This is the desired 1481 identity or name for the multicast group. 1483 * Group permissions - optional (grppac): This is the desired set 1484 of permissions associated with the multicast group. 1486 o Authenticator: In the case of a GSK-REQ message, the authenticator 1487 is encrypted by the service principal (SP) using the secret key it 1488 shares with the SKDC. The authenticator in the GSK-REQ contains 1489 the following: 1491 * SP's realm (sprealm). 1493 * SP's identity (spname). 1495 * SP's current time (sptime). 1497 * A new nonce generated by the SP (nonce). 1499 * Sequence number - optional (seqnum). 1501 * Checksum - optional (cksum). 1503 o Extensions - optional (ext): Reserved for future extensions. This 1504 field is optional. 1506 5.2. GSK-Response Message (GSK-REP) 1508 The GSK-Response (GSK-REP) message is sent from the SKDC to the 1509 service principal in response to the service principal's GSK-Request 1510 message. The GSK-Response message contains a receipt structure which 1511 carries the new group-key for the requesting service principal. 1513 Note that the GSK-REP message does not contain a miniticket. 1515 The Receipt in the GSK-Response message is encrypted by the SKDC to 1516 the requesting service principal using the secret key that is shared 1517 between the SKDC and the service principal. 1519 The GSK-Response message contains the following: 1521 o Protocol version (pvno): This the version of the protocol. 1523 o Message type (msg-type): The message type for this message is 1524 "GSK-REP". 1526 o SP's realm (sprealm): This the name of the realm, domain or zone 1527 in which the SP belongs in connection to this request. 1529 o SP's identity (spname): This is the identity of the SP requesting 1530 the group-key in the previous GSK-REQ message. 1532 o Receipt (receipt): The receipt carries the group-key and relevant 1533 parameters. It is encrypted by the SKDC to the SP using the 1534 secret key shared between the SKDC and the cSP. The receipt 1535 (receipt) contains the following: 1537 * Receipts flags - optional (rflags). 1539 * Issuing SKDC's realm (skdcrealm). 1541 * Issuing SKDC's identity (skdcname). 1543 * Multicast group realm - optional (mcastrealm). 1545 * Multicast group identity (mcastname). 1547 * Group permissions - optional (grppac). 1549 * Current time (authtime). 1551 * Nonce from the GSK-REQ request (nonce). 1553 * Expiration time of key (endtime). 1555 * Group key (keydata): The key-data structure contains the group- 1556 key destined for the requesting SP. See section Section 2.6 1557 for the key-data structure. 1559 o Extensions - optional (ext): Reserved for future extensions. This 1560 field is optional. 1562 5.3. GSK-Fetch Message (GSK-FET) 1564 The GSK-Fetch message is sent by a client to the SKDC asking for a 1565 copy of a group-key asociated with a multicast group. The client 1566 must identify the desired multicast group name (mcastname) in the 1567 SKDC-REQ-BODY of the message. The client authenticates itself to the 1568 SKDC by including an authenticator. 1570 The contents of the GSK-Fetch message is as follows: 1572 o Protocol version (pvno): This the version of the protocol. 1574 o Message type (msg-type): The message type for this message is 1575 "GSK-FET". 1577 o SKDC request body (req-body): The req-body contains the parameters 1578 required by the SKDC identify the multicast group. See 1579 Section Section 2.1 for more information on the SKDC request body. 1580 The SKDC request body of a GSK-FET message contains the following: 1582 * SKDC options - optional (skdc-options). 1584 * SKDC's realm - optional (skdcrealm). 1586 * SKDC's identity (skdcname). 1588 * Multicast group realm - optional (mcastrealm). 1590 * Multicast group identity (spname): This is the name of the 1591 multicast group whose group-key is being fetched. 1593 * KeyID - optional (keyid). 1595 o Authenticator (authenticator): The authenticator in the GSK-FET is 1596 encrypted by the client to the SKDC using the secret key that the 1597 client shares with the SKDC. See Section Section 2.4 for more 1598 information the the authenticator structure. The authenticator in 1599 the GSK-FET contains the following: 1601 * Client's realm (crealm). 1603 * Client's identity (cname). 1605 * Client's current time (ctime). 1607 * A new nonce generated by the client (nonce). 1609 * Sequence number - optional (seqnum). 1611 * Checksum - optional (cksum). 1613 o Extensions - optional (ext): Reserved for future extensions. This 1614 field is optional. 1616 5.4. GSK-Deliver Message (GSK-DLVR) 1618 The GSK-Deliver (GSK-DLVR) message is sent from the SKDC to the 1619 client in response to the client's GSK-Fetch message. The GSK- 1620 Deliver message uses the receipt structure to carry the group 1621 encryption key. The receipt is encrypted using secret key which is 1622 shared pair-wise between the client and the SKDC. 1624 The contents of the GSK-Deliver message is as follows: 1626 o Protocol version (pvno): This is the version of the protocol. 1628 o Message type (msg-type): The message type for this message is 1629 "GSK-DLVR". 1631 o Client's realm (crealm): This the name of the realm, domain or 1632 group in which the client belongs in connection to this request. 1634 o Client's identity (cname): This is the identity of the client. 1636 o Receipt (receipt): This is the part of the GSK-Deliver message 1637 carries the group-key. It is encrypted by the SKDC to the client 1638 using the secret key shared between the SKDC and the client. The 1639 receipt contains the following: 1641 * Receipts flags - optional (rflags). 1643 * Issuing SKDC's realm (skdcrealm). 1645 * Issuing SKDC's identity (skdcname). 1647 * Multicast group realm - optional (mcastrealm). 1649 * Multicast group identity (mcastname): This is the name of the 1650 multicast group whose group-key is being delivered. 1652 * Group permissions - optional (grppac). 1654 * Current time (authtime). 1656 * Nonce from the previous GSK-FET message (nonce). 1658 * Expiration time of key (endtime). 1660 * Group key (keydata): This key-data structure contains the group 1661 key destined for the requesting client. See section 1662 Section 2.6 for the key-data structure. 1664 o Extensions - optional (ext): Reserved for future extensions. This 1665 field is optional. 1667 6. Group Shared Key Deletion 1669 The current protocol supports the proactive removal of a group-key 1670 associated with a multicast group prior to the expiration of the 1671 group-key. Only the creator (owner) of the multicast group can 1672 request the SKDC to delete a group-key (or the SKDC itself could 1673 perform a group-key deletion in response to an external authorized 1674 trigger). 1676 Due to the nature of a symmetric group-key, the removal of a group- 1677 key from a multicast group requires the SKDC to issue unicast PSK- 1678 Delete messages to each known member of the group. When the SKDC 1679 sends the PSK-Delete message to a client who is a group member, the 1680 SKDC must identify the group-key via its KeyID. Each group member 1681 must respond to the SKDC with a PSK-Delete-Confirm (PSK-DELC) message 1682 to confirm the deletion or erasure of the group-key. See 1683 Section Section 4.1 for more information on the PSK-DELT and PSK-DELC 1684 messages. 1686 The SKDC must wait for all known group members to individually 1687 confirm (via a PSK-DELC message) their deletion of the group-key. 1688 Only then should the SKDC return a GSK-Delete-Confirmation (GSK-DELC) 1689 message to the service principal who requested the group-key 1690 deletion. 1692 When the SKDC is in the process of deleting a group-key, it must deny 1693 further requests for the group-key from new members. 1695 The group-key deletion process involves four types of messages: 1697 o GSK-Delete (GSK-DELT): The SP (as group-owner) sends a GSK-Delete 1698 request to the SKDC. 1700 o PSK-Delete (KeyID): For each member of the group (i.e. clients who 1701 previosuly requested a copy of the group-key), the SKDC sends a 1702 unicast PSK-Delete (PSK-DELT) message to that client identifying 1703 the target key to be deleted (by KeyID). See Section Section 4.1 1704 for the PSK-DELT message. 1706 o PSK-Delete-Confirm (KeyID): Each group member responds after key- 1707 deletion with a PSK-DELC message to the SKDC. See 1708 Section Section 4.2for the PSK-DELC message. 1710 o GSK-Delete-Confirmed (GSK-DELC): The SKDC responds with a GSK- 1711 Delete-Confirmed message to the SP (as group-owner) once all 1712 copies of the group-key has been deleted at the group-members. 1714 The message flow for GSK deletion is shown in Figure 6. 1716 The GSK Deletion Message Components 1718 SP (Group Owner) SKDC Client 1719 | | | 1720 | | | 1721 |-- (1) GSK-DELT, Kenvelope* --> | | 1722 | | | 1723 | |-- (2) PSK-DELT, Kenvelope* -->| 1724 | | | 1725 | | | 1726 | |<-(3)PSK-DELC,Acknowledgement*-| 1727 | | | 1728 | | | 1729 |<-(4) GSK-DELC, Acknowledgement*-| | 1730 | | | 1731 | | | 1733 Figure 6 1735 6.1. GSK-Delete Message (GSK-DELT) 1737 The GSK-Delete (GSK-DELT) request message is sent from an SP (group 1738 owner) to the SKDC asking for the deletion or erasure of the group- 1739 key of the multicst group identified in the message. 1741 The GSK-DELT message contains the following. 1743 o Protocol version (pvno): This is the version of the protocol. 1745 o Message type (msg-type): The message type for this message is 1746 "GSK-DELT". 1748 o SP's realm (sprealm): This the name of the realm, domain or group 1749 in which the SP belongs in connection to this request. 1751 o SP's identity (spname): This is the identity of the SP. 1753 o Key Envelope (kenvelope): The key envelope is encrypted using the 1754 SP's secret key that it shares with the SKDC. The key envelope 1755 contains the following: 1757 * Envelope Flags - optional (envflags). 1759 * Multicast group realm - optional (mcastcrealm): This is the 1760 realm of the multicast group whose group-key is being deleted. 1762 * Multicast group identity (skdcname): This is the name of the 1763 multicast group whose group-key is being deleted. 1765 * Current time (authtime). 1767 * New nonce generated by the SP (nonce). 1769 * Sequence number - optional (seqnum). 1771 * Key data (keydata): This key-data structure contains the KeyID 1772 of the target key to be deleted. The key-data in a key 1773 envelope must never contain a cryptographic key. See section 1774 Section 2.6 for the key-data structure. 1776 o Extensions - optional (ext): Reserved for future extensions. This 1777 field is optional. 1779 6.2. GSK-Delete-Confirm Message (GSK-DELC) 1781 In response to a GSK-Delete request from a service principal (as 1782 group owner), the SKDC sends a GSK-Delete-Confirm (GSK-DELC) message 1783 to the service principal for the successful deletion of not only its 1784 copy of the group-key, but also the successful deletion of the copies 1785 of the group-key at each group member (client). 1787 The GSK-DELC message contains the following: 1789 o Protocol version (pvno): This is the version of the protocol. 1791 o Message type (msg-type): The message type for this message is 1792 "GSK-DELC". 1794 o SP's realm - optional (sprealm). 1796 o SP's identity (spname). 1798 o Acknowledgement (ack): The acknowledgement is encrypted by the 1799 SKDC to the SP using the secret key shared only between the SKDC 1800 and SP. 1802 * Multicast group identity (mcastname): This is the name of the 1803 multicast group whose group-key has been deleted. 1805 * Multicast group realm - optional (mcastrealm). 1807 * Nonce from the SP's previous GSK-DELT message (nonce). 1809 * Current time (authtime). 1811 * Sequence number - optional (seqnum): This field is optional. 1813 o Extensions - optional (ext): Reserved for future extensions. This 1814 field is optional. 1816 7. Public Key Pair Establishment 1818 The current protocol supports the distribution of public key pairs 1819 and certificates. Since the SKDC is not a certificate authority (in 1820 the sense of RFC2459), issuing (signing) X509 certificates is out of 1821 scope for the current specification. If the SKDC receives from a 1822 client a request for a new certificate, the SKDC must obtain a 1823 certificate from a CA server (or CA service) located either in the 1824 same realm/zone or elsewhere on behalf of the requesting client. How 1825 the SKDC discovers CA services is out of scope for the current 1826 specification. 1828 In the following we provide additional message types to support a 1829 client requesting the SKDC to deliver a new public key pair and to 1830 return the key pair to the client. 1832 When a client seeks to obtain a new public key pair, the client sends 1833 a Public Key Pair Request (PKP-REQ) message to the SKDC. The 1834 requesting client must include an authenticator that is encrypted 1835 using the secret key it shares with the SKDC. The SKDC returns the 1836 key-pair in the receipt structure to the client (encrypted to the 1837 client). 1839 As a further option to the PKP-REQ message, if the client identifies 1840 a service principal in the SKDC-REQ-BODY of the PKP-REQ message, the 1841 SKDC would also return a miniticket that contains only the public 1842 half of the key-pair. The miniticket would be encrypted by the SKDC 1843 to the named service principal, using the secret key that the SKDC 1844 shares with the service principal. Note that this is a departure 1845 from the PSK-Request semantics (for symmetric key requests) because 1846 the miniticket contains a public key (instead of a symmetric key). 1848 The client (or the SKDC) then sends the miniticket to the service 1849 principal who can decrypt the miniticket using the secret key it 1850 shares with the SKDC. 1852 By encrypting the miniticket to the service principal, the SKDC is 1853 effectively attesting to the binding between the public key pair and 1854 the client's identity (without the use of digital certificates). The 1855 service principal trusts SKDC to provide this pseudo-attestation 1856 regarding the client as the owner of the new public key pair. 1858 Note that in this approach the security of the public key pair is 1859 only as a secure as the symmetric key algorithm used to encrypt the 1860 receipt and the miniticket. 1862 If additionally the client seeks to obtain a digital certificate for 1863 the new public key, then the client must indicate this option in the 1864 SKDC-Options field (in the SKDC-REQ-BODY) of the PKP-Request message. 1865 There are several options available related to digital certificates 1866 and CA certificates (trust anchors): 1868 No certificate: This is the default setting for the PKP-Request 1869 message. 1871 Certificate: This means the client additionally requests the 1872 return of a new X509 certificate corresponding to the new public 1873 key. 1875 Include certificate chain: This option is meaningful only of the 1876 client requests a new X509 certificate. When set, this option 1877 means that the client also requests the certificate chain 1878 consisting of copies of all signing certificates to the top of the 1879 certificate hierarchy. 1881 7.1. Public Key Pair Request (PKP-REQ) 1883 A client uses the PKP-Request message (PKP-REQ) to request a new 1884 public key pair from the SKDC. The client must include an 1885 authenticator when sending this message to the SKDC. The PKP-REQ 1886 message contains the following: 1888 o Protocol version (pvno): This the version of the protocol. 1890 o Message type (msg-type): The message type for this message is 1891 "PKP-REQ". 1893 o SKDC request body (req-body): The request body contains the 1894 parameters required by the SKDC in the context of this request. 1895 the See Section Section 2.1 for more information on the SKDC 1896 request body. The SKDC request body of a PKP-REQ message contains 1897 the following: 1899 * Key Type (kty): This is type of key being requested by the 1900 client from the SKDC. 1902 * Desired algorithm (etype): This is the algorithm that is 1903 desired (or supported) by the client. 1905 * SKDC options - optional (skdc-options): The client sets the 1906 "certificate request" option (and possibly the "certificate 1907 chain" option) in this field if it requests a digital 1908 certificate (and corresponding chain) to be returned together 1909 with the public key pair. 1911 * SKDC's realm (skdcrealm). 1913 * SKDC's identity (skdcname). 1915 * Service principal's realm - optional (sprealm): 1917 * Service principal's identity -- optional (spname): 1919 + spname is present: If the spname is present, this means that 1920 the client wishes for the SKDC to prepare copy of the new 1921 public key only for the named service principal via the 1922 miniticket structure. 1924 + spname is absent: If the spname is absent the SKDC delivers 1925 the public key pair only to the client via the receipt 1926 structure. 1928 * Client permissions - optional (cpac). 1930 o Authenticator (authenticator): This is the authenticator encrypted 1931 by the client to the SKDC using the secret key that the client 1932 shares with the SKDC. See Section Section 2.4 for more 1933 information on the authenticator structure. 1935 o Extensions - optional (ext): Reserved for future extensions. This 1936 field is optional. 1938 7.2. Public Key Pair Response (PKP-REP) 1940 In response to the PKP-Request message (PKP-REQ) from a client 1941 entity, the SKDC returns a copy of the new public key pair to the 1942 client in a receipt structure, encrypted using the secret key shared 1943 between the client and SKDC. This ensures that only the client is in 1944 possession of the new public key pair (notably the private key). 1946 If the SKDC-REQ-BODY of the client's previous PKP-request message 1947 contains the identity of a service principal (spname), the SKDC must 1948 also create a miniticket containing a copy of the public key only. 1949 The miniticket is encrypted to the service principal. 1951 The PKP-REP message contains the following: 1953 o Protocol version (pvno): This the version of the protocol. 1955 o Message type (msg-type): The message type for this message is 1956 "PKP-REP". 1958 o Client's realm (crealm): This the name of the realm, domain or 1959 zone in which the client belongs in connection to this request. 1961 o Client's identity (cname): This is the identity of the client. 1963 o Miniticket - optional (mticket): If the client identified a 1964 service principal in the previous PKP-REQ message (in its SKDC- 1965 REG-BODY), then a miniticket is included by the SKDC in this PKP- 1966 REP message. If present, the miniticket contains the following: 1968 * Issuing SKDC's realm (skdcrealm). 1970 * Issuing SKDC's identity (skdcname). 1972 * Service principal's realm - optional (sprealm). 1974 * Service Principal's identity (spname). 1976 * Encrypted miniticket part (enc-part): This is the part of the 1977 PKP-REP message that is encrypted by the SKDC to the service 1978 principal, using the secret key that the SKDC shares pair-wise 1979 with the service principal. It contains the following: 1981 + Ticket flags - optional (tflags). 1983 + Client's realm (crealm): This the name of the realm, domain 1984 or zone in which the client belongs in connection to this 1985 request. 1987 + Client's identity (cname). 1989 + Client permissions - optional (cpac). 1991 + Time of authentication (authtime). 1993 + Expiration time of this key - optional (endtime): This field 1994 is present if the SKDC returns a public key pair only. If a 1995 certificate accompanies the public key pair, then this field 1996 is absent. 1998 + Service principal permissions - optional (sppac). 2000 + Transited realms - optional (transited). 2002 + Key data (keydata): In a PKP-REP message, the key-data 2003 structure in the miniticket contains only the public key of 2004 the client. The private key must not be included. If the 2005 client had also requested a new certificate, the certificate 2006 is included here. See section Section 2.6 for the key-data 2007 structure. 2009 o Receipt (receipt): This is the part of the PKP-REP message that is 2010 encrypted by the SKDC to the client, using the secret key that the 2011 SKDC shares pair-wise with the client. It contains the following: 2013 * Receipts flags - optional (tflags). 2015 * Issuing SKDC's realm (skdcrealm). 2017 * Issuing SKDC's identity (skdcname). 2019 * Service principal's realm - optional (sprealm). 2021 * Service Principal's identity (spname). 2023 * Service Principal's SKDC - optional (spskdc). 2025 * Client permissions - optional (cpac). 2027 * Time of authentication (authtime): This is the time of the 2028 creation of this receipt. 2030 * Nonce from the Client's previous PSK-REQ request message 2031 (nonce). 2033 * Expiration time of this key (endtime). 2035 * Key data (keydata): In a PKP-REP message, the key-data 2036 structure in the receipt contains both the public key and 2037 private key belonging to the requesting client. If the client 2038 had also requested a new certificate, the certificate is 2039 included here. See section Section 2.6 for the key-data 2040 structure. 2042 o Extensions - optional (ext): Reserved for future extensions. This 2043 field is optional. 2045 8. JSON Message Format 2047 TBD. 2049 9. Encryption and Checksums 2051 TBD. 2053 10. Security Considerations 2055 TBD. 2057 11. Privacy Considerations 2059 TBD. 2061 12. IANA Considerations 2063 TBD. 2065 13. Acknowledgments 2067 We thank Jesse Walker for design inputs and initial review. 2069 14. References 2071 14.1. Normative References 2073 [JSON] Bray, T., "The JavaScript Object Notation (JSON) Data 2074 Interchange Format", March 2014, 2075 . 2077 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2078 Requirement Levels", BCP 14, RFC 2119, 2079 DOI 10.17487/RFC2119, March 1997, 2080 . 2082 [RFC6347] Rescorla, E., "Datagram Transport Layer Security Version 2083 1.2", January 2012, . 2085 [RFC7252] Shelby, Z., "The Constrained Application Protocol (CoAP)", 2086 June 2014, . 2088 14.2. Informative References 2090 [ACE] Seitz, L., Ed., "ACE Use Cases", October 2012, 2091 . 2093 [BR-3KPD] Bellare, M. and P. Rogaway, "Entity Authentication and Key 2094 Distribution (In Advances in Cryptology, pages 110-125. 2095 Springer-Verlag, 1993)", September 1993, 2096 . 2098 [Choo04] Choo, K., Boyd, C., Hitchcock, Y., and G. Maitland, "On 2099 Session Identifiers in Provably Secure Protocols (Security 2100 in Communication Networks 4th International Conference, 2101 SCN 2004)", September 2004, . 2103 [Choo06] Choo, R., "Key Establishment: Proofs and Refutations", May 2104 2006, . 2107 [EPID] Brickell, E. and J. Li, "Enhanced Privacy ID (in NIST 2108 Privacy Enhancing Cryptography Conference 2011)", December 2109 2011, 2110 . 2113 [MSKILE] Microsoft, ., "Kerberos Protocol Extensions (v20140502)", 2114 May 2014, . 2117 [MSPAC] Microsoft, ., "Privilege Attribute Certificate Data 2118 Structure (v20140502)", May 2014, 2119 . 2121 [NS] Needham, R. and M. Schroeder, "Using encryption for 2122 authentication in large networks of computers (CACM)", 2123 December 1978, 2124 . 2126 [OAuth2] Hardt, D., "The OAuth 2.0 Authorization Framework", 2127 October 2012, . 2129 [OIDC] Sakimura, N., "OpenID Connect Core 1.0 incorporating 2130 errata set 1", November 2014, 2131 . 2133 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 2134 Kerberos V5", February 2005, 2135 . 2137 [RFC3986] Berners-Lee, T., "Uniform Resource Identifier (URI): 2138 Generic Syntax", January 2005, 2139 . 2141 [RFC4120] Neuman, C., "The Kerberos Network Authentication Service 2142 (V5)", July 2005, . 2144 [RFC6113] Hartman, S., "A Generalized Framework for Kerberos Pre- 2145 Authentication", April 2011, 2146 . 2148 [TPM] TCG, ., "Trusted Platform Module (TPM) Main Specification 2149 Level 2 Version 1.2", March 2011, 2150 . 2153 [UMACORE] Hardjono, T., Ed., "User-Managed Access (UMA) Profile of 2154 OAuth 2.0", November 2014, 2155 . 2158 Appendix A. Document History 2160 NOTE: To be removed by RFC editor before publication as an RFC. 2162 Authors' Addresses 2164 Thomas Hardjono 2165 MIT 2167 Email: hardjono@mit.edu 2169 Ned Smith 2170 Intel Corp 2172 Email: ned.smith@intel.com