Network Working Group T. Hardjono Internet-Draft MIT Intended status: Standards Track N. Smith Expires: September 24, 2015 Intel Corp March 23, 2015 Fluffy: Simplified Key Exchange for Constrained Environments draft-hardjono-ace-fluffy-00 Abstract This document proposes a simplified key exchange protocol for the establishment of a symmetric key shared between two devices or entities within a constrained environment. The pair-wise key establishment is performed using the mediation of a trusted Simple Key Distribution Center (SKDC) entity. The protocol also supports the mediated distribution of a group-key among multiple devices or entities for the purposes of protecting multicast messages. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 24, 2015. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must Hardjono & Smith Expires September 24, 2015 [Page 1] Internet-Draft Simplified Key Exchange March 2015 include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.3. Design Considerations . . . . . . . . . . . . . . . . . . 6 1.4. Out of Scope and Non-Goals: . . . . . . . . . . . . . . . 7 2. Pair-wise Shared Key (PSK) Establishment . . . . . . . . . . 8 2.1. Basic Protocol Exchange . . . . . . . . . . . . . . . . . 8 2.2. Common Building Blocks . . . . . . . . . . . . . . . . . 10 2.3. PSK-Request Message . . . . . . . . . . . . . . . . . . . 11 2.3.1. SKDC request body . . . . . . . . . . . . . . . . . . 12 2.4. PSK-Response Message . . . . . . . . . . . . . . . . . . 12 2.4.1. Miniticket . . . . . . . . . . . . . . . . . . . . . 13 2.4.2. Receipt for PSK . . . . . . . . . . . . . . . . . . . 14 2.5. PSK-Establish Message . . . . . . . . . . . . . . . . . . 15 2.5.1. Authenticator . . . . . . . . . . . . . . . . . . . . 15 2.6. PSK-Acknowledge Message . . . . . . . . . . . . . . . . . 16 3. Group Shared Key (GSK) Establishment . . . . . . . . . . . . 17 3.1. GSK-Request Message . . . . . . . . . . . . . . . . . . . 19 3.2. GSK-Response Message . . . . . . . . . . . . . . . . . . 20 3.2.1. Receipt for GSK . . . . . . . . . . . . . . . . . . . 21 3.3. GSK-Fetch Message . . . . . . . . . . . . . . . . . . . . 22 3.4. GSK-Deliver Message . . . . . . . . . . . . . . . . . . . 23 4. JSON Message Format . . . . . . . . . . . . . . . . . . . . . 23 5. Encryption and Checksums . . . . . . . . . . . . . . . . . . 23 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 23 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 10.1. Normative References . . . . . . . . . . . . . . . . . . 24 10.2. Informative References . . . . . . . . . . . . . . . . . 24 Appendix A. Document History . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 1. Introduction This document proposes a simplified key exchange protocol for constrained environments for the establishment of a symmetric key shared between two constrained devices. The pair-wise key establishment is performed using the mediation of a trusted Simple Key Distribution Center (SKDC) entity. The protocol also supports Hardjono & Smith Expires September 24, 2015 [Page 2] Internet-Draft Simplified Key Exchange March 2015 the mediated distribution of a group-key among multiple devices or entities for the purposes of protecting multicast messages. The simplified key exchange protocol is referred to here as "Fluffy" and is based on a reduced set of Kerberos [RFC4120] messages, adjusting the message flows, types and features to the needs and capabilities of constrained devices and environments. It does not seek to be backward compatible with Kerberos implementations. The protocol aims to be independent of the underlying transport protocol, and as such the protocol messages are integrity-protected against modifications in-transit. Similar to Kerberos [RFC4120], messages that carry sensitive information (such as keys and/or keying material) are protected using authenticated-encryption. Non- sensitive fields of the messages are integrity-protected using checksums or keyed-hash in the manner of RFC3961. A separate specification will be developed to address in more detail these cryptographic aspects of the current proposed protocol. Two families of protocol messages are defined here: o Pairwise key establishment between two entities: When a client seeks to establish a pairwise shared key (called the session encryption key) with a service principal (SP), it invokes the mediation of the SKDC. A four (4) message flow among the client, SKDC and SP are used to establish the pairwise shared key. o Group-shared key establishment among multiple entities: When a client (e.g. client#1) seeks to create a group-shared key (called the group encryption key), it invokes the SKDC to create the group-key, to retain a copy at the SKDC and to return a copy to the requesting client. The distribution of the group-key to other members of a multicast group uses a simple fetch/deliver model in which new group members (e.g. client#2) must ask for a copy of the group-key from the SKDC. The current simplified key exchange protocol does not address the initial secret establishment between an entity and the SKDC. This is referred to in RFC4120 and RFC6113 as "pre-authentication". We anticipate that many types of constrained devices would need to undergo "on-boarding" into an operational state within a constrained environment, and that the on-boarding process may include (directly or as a side-effect) the establishment of the initial secret between the new device and the SKDC already operating in the environment. Thus, for example, the on-boarding process of a device (e.g. door- lock) into a constrained environment (e.g. home basement) with an SKDC entity (e.g. within the alarm panel) may consist of the device and the SKDC running a Diffie-Hellman exchange with the assistance of Hardjono & Smith Expires September 24, 2015 [Page 3] Internet-Draft Simplified Key Exchange March 2015 the human owner. The topic of on-boarding and off-boarding of devices is outside the scope of the current specification. The security of current proposed protocol seeks to be independent of is underlying messaging transport, and its messages are protected independent of any underlying secure transport layer (such as TLS [RC5246] and DTLS [RFC6347]). However, in this specification we assume that a transport such as CoAP [RFC7252] will be deployed in constrained environments where the IP protocol is operating at the network layer. Environments that are using non-IP transport are out of scope currently for this specification. The current protocol uses JSON [RFC7159] and CBOR [RFC7049] for its message format. This is in-line with the RESTful paradigm and provides the greatest flexibility for the current protocol to be integrated with other protocols such as OAuth2.0 [RFC6749] for authorization and UMA [UMACORE] for user-centric consent management. Since the intended deployment environment for the current protocol is a constrained environment, devices and entities there are assumed to use the UUID as the basis for identification. How a device is assigned a UUID is out of scope for the current specification. The current specification acknowledges that in certain types of constrained environments there is the need for devices to not only operate autonomously for long periods of time, but also for devices to have the capability to take-on different roles with respect to other devices in the environment. Thus, a device (D1) acting as a client to another device (D2) that is acting as an SKDC could also be acting as an SKDC for yet a third device (D3). Thus, the device D1 may have the capability to be both a client and SKDC depending on the operational environment. As in many deployment environments generally, often security is a trade-off among several factors (e.g. usability, assurance levels, cost, economic risk/benefits, and others). As such, it is realistic to acknowledge that the degree of trustworthiness of an SKDC is dependent on the value of the data and connections within the deployment environment. Thus, an SKDC within a home environment may not be expected to feature the same level of resistance to attacks as an enterprise deployment of a Kerberos KDC. 1.1. Notational Conventions The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in [RFC2119]. Hardjono & Smith Expires September 24, 2015 [Page 4] Internet-Draft Simplified Key Exchange March 2015 Unless otherwise noted, all protocol properties and values are case sensitive. JSON [JSON] data structures defined by this specification MAY contain extension properties that are not defined in this specification. Any entity receiving or retrieving a JSON data structure SHOULD ignore extension properties it is unable to understand. Extension names that are unprotected from collisions are outside the scope of this specification. 1.2. Terminology The current specification seeks to share terminology as much as possible with the terminology defined for CoAP [RFC7252]. However, since the intended Application(s) play a crucial role within constrained networks, we also refer to terminology used by OAuth 2.0 and UMA. Note that within a given constrained network, an device make take multiple roles (client or server) depending on the exchange and layers of the exchange in which they participate. client The client is the entity in a constrained environment seeking to share a key pair-wise with the service principal. service principal The entity with whom the client seeks to establish a pair-wise symmetric key is refereed to as the service principal (SP). This terminology is used to avoid confusion as much as possible with the generic term "server" or "service". simple key distribution center The simple key distribution center (SKDC) is the entity which mediates the establishment of the pair-wise shared key between the client and service principal. miniticket This is the data structure that carries the symmetric key to be shared between the client and service principal. pair-wise shared key A pair-wise shared key (PSK) is symmetric key shared only between a client and service principal. group shared key A group shared key (GSK) is symmetric key shared by two or more entities. session encryption key The session encryption key is the symmetric key generated by the SKDC to be shared pair-wise between the client and the Hardjono & Smith Expires September 24, 2015 [Page 5] Internet-Draft Simplified Key Exchange March 2015 service principal. A session encryption key is an instance of a PSK. group encryption key The group encryption key is the symmetric key generated by the SKDC to be shared among members of a multicast group. A group encryption key is an instance of a GSK. secret key The secret key is the symmetric key that is uniquely shared pair-wise between a client (or service principal) and the SKDC. This term is borrowed from RFC4120. Thus, the client secret key is the symmetric key that is uniquely shared pair-wise between the client and the SKDC. The SP secret key is the symmetric key that is uniquely shared pair-wise between the SP and the SKDC. set-up keying material The cryptographic keying material (including possibly keys) resulting from the initial on-boarding process of a device into a constrained environment is referred to generally as "set-up keying material". permissions and access control The permissions and access control (PAC) is the set of information pertaining to permissions for entities within a constrained environment. resource The resource refers to the end-point at the service principal to which the application seeks access. 1.3. Design Considerations There are a number of design considerations and background for the current protocol. Transport: We assume that the entities in the constrained environment are deploying the CoAP protocol as transport [RFC7252]. However, the design of the current protocol seeks to be transport-independent as much as possible because we anticipate that not all constrained networks may be running CoAP. JSON data structures: The data structures in this specification are expressed in JSON. We believe this provides the greatest flexibility for the protocol to be integrated into existing protocols for authorization (such as OAuth2.0 [Oauth2] and OpenID- Hardjono & Smith Expires September 24, 2015 [Page 6] Internet-Draft Simplified Key Exchange March 2015 Connect [OIDC]) and consent management by the resource/device owner (such as the User Managed Access (UMA) protocol [UMACORE]). On-boarding and off-boarding: We assume that constrained devices will undergo the phase of "on-boarding" into a constrained environment. Similarly, "off-boarding" will be required when a constrained device leaves (or is removed) from a constrained environment. The notion of on-boarding is closely related to that of "take-ownership" of certain types of devices. Technologies such as the TPM [TPM] and EPID [EPID] play a crucial role in providing both cryptographic proof (technical trust) and human proof (social trust) in the process of changing the ownership of a device when it is activated and introduced into a constrained environment. We see a close relationship between on-boarding and the current protocol for establishing PSKs and GSKs within a constrained environment. Secret key establishment or derivation: Following the on-boarding process of a client (resulting in the client and SKDC possessing set-up keying material), the client and the SKDC are assumed to generated the secret key which is shared pair-wise between the client and the SKDC. Methods include using PRFs and other one-way functions. The exact process of generating a secret key from the set-up keying material is out of scope of the current specification. Realms and zones: We have borrowed the notion of "realms" from RFC4120 because we anticipate that a constrained environment may consists of one or more physical networks, and which may be arranged (logically or physically) into "zones". Furthermore, we anticipate that in some use-cases the notion of a "realm" or "zone" may be more ephemeral than is commonly understood for RFC4120 deployments. Thus, there may be constrained use-cases where realms or zones are short-lived. 1.4. Out of Scope and Non-Goals: The following are out of scope (non-goals) for the current specification: Authorization and permissions: The issue of permissions and authorization is out of scope for this specification. However, the current specification anticipates the close integration between permissions, authentication and key establishment. Discovery: Discovery of endpoints, identities, services and other aspects of a constrained environment is out of scope for the current specification. Hardjono & Smith Expires September 24, 2015 [Page 7] Internet-Draft Simplified Key Exchange March 2015 Backward compatibility with Kerberos: It is not a goal of this specification to achieve backward compatibility with RFC1510 or RFC4120. Similarly, it is not the goal of this specification to be compatible with the MS-PAC [MSPAC] and MS-KILE [MSKILE] specifications. Pre-authentication: RFC4120, RFC4556 and RFC613 uses the term "pre- authentication" to denote a client obtaining keying material for its secret key prior executing the Kerberos. It is not a goal of this specification to address pre-authentication. Channel Binding for TLS and DTLS: Channel binding [RFC5929] for DTLS and TLS are out of scope in the current specification. 2. Pair-wise Shared Key (PSK) Establishment This section describes the pair-wise key establishment between the client and the service principal. 2.1. Basic Protocol Exchange Prior to executing the Fluffy protocol, a client must first be in possession of a secret key that it shares pair-wise with the SKDC. The process or method of obtaining the client secret key is outside the scope of the current specification, but for a device operating within a constrained environment this may be related to the on- boarding or take-ownership process. For example, the manufacturer of the device may ship the device containing some fixed cryptographic parameter (e.g. Diffie-Hellman group and modulo values). When the new owner (e.g. home consumer) seeks to introduce the device into a constrained network, he or she may need to enter commands that result in the device becoming a client of second device already operating as the SKDC. We refer to the key resulting from on-boarding or take-ownership as the "set-up keying material". The set-up keying material in turn can be used to derive or generate the shared secret key at the client and the SKDC. The Fluffy protocol consists of a 4-message flow from the client to SKDC, the SKDC back to the client, and between the client and the service principal. Authentication of the client to the SKDC is achieved by virtue of proof of possession by the client of the client's secret key. Authentication of the client to the service principal is achieved by proof of possession by the client of a copy of the session encryption key (which the SKDC issued for only the client and the service principal). Hardjono & Smith Expires September 24, 2015 [Page 8] Internet-Draft Simplified Key Exchange March 2015 The message flows consists of the following steps and are summarized in Figure Figure 1. o PSK-Request: The client sends a PSK-Request message to the SKDC asking for the SKDC to mediate the sharing of a new session encryption key between the client and the service principal. The client must indicate the intended service principal in this message. o PSK-Response: The SKDC responds by generating a new session encryption key and placing the key into a miniticket intended for the service principal. The miniticket is encrypted using the secret key which is pair-wise shared only between the SKDC and the service principal. Additionally, the SKDC places a copy of this new session encryption key into a receipt structure, and encrypting it using the secret key pair-wise shared between the SKDC and the client. Both the miniticket and the receipt are then returned to the client. o PSK-Establish: The client then decrypts the receipt to obtain the session encryption key. The client uses this session encryption key to encrypt an authenticator structure as proof of possession for the service principal. The client then sends the authenticator and the miniticket (unmodified from the SKDC) to the service principal. The service principal decrypts the miniticket to obtain the session encryption key, and then it uses the session encryption key to decrypt the authenticator. At this point the client and the service principal shares the session encryption key. o PSK-Acknowledge: The service principal exercises the newly received session encryption key by encrypting a message for the client. Similar to RC4120, the integrity of the messages containing cleartext data is protected using a checksum mechanism (e.g. keyed hash) based on the client's secret key [RFC3961]. Hardjono & Smith Expires September 24, 2015 [Page 9] Internet-Draft Simplified Key Exchange March 2015 The PSK Establishment Flows +------------+ +--------------+ | | | | | |-----(1) PSK-Request ---->| | | | | SKDC | | |<---(2) PSK-Response -----| | | | | | | Client | +--------------+ | | | | +--------------+ | |---- (3)PSK-Establish --->| | | | | SP | | |<--- (4)PSK-Acknowledge --| | | | | | +------------+ +--------------+ Figure 1 2.2. Common Building Blocks The Fluffy protocol messages employ a number of data structures that are common across several messages. Many of these are borrowed from RFC4120 though not necessarily compatible with it. These are as follows: o SKDC-request body: This is part of the request message that carries parameters regarding the client's identity, service principal's identity, the client's nonce and others. o Receipt: The receipt is the data structure created by the SKDC to carry the key to be delivered to the client (either session-key or group-key). The receipt is always encrypted to the client by the SKDC using the client's secret key (shared pair-wise with the SKDC). The receipt is functionally equivalent to the SKDC- Response part in RFC4120. The contents of the receipt for PSK Establishment (session encryption key) is slightly different from the receipt use for GSK Establishment (group encryption key), with the later carrying more fields. o Miniticket: The miniticket is the data structure created by the SKDC to carry the session encryption key to be delivered (via the client) to the service principal in the PSK Establishment. The miniticket has an encrypted-part which is encrypted to the service principal by the SKDC. The miniticket is functionally equivalent to the service-ticket in RFC4120. Hardjono & Smith Expires September 24, 2015 [Page 10] Internet-Draft Simplified Key Exchange March 2015 o Authenticator: The authenticator is the data structure created and encrypted by the client with the aim of authenticating itself (by virtue of proof of possession) to the recipient of the authenticator. For the PSK Establishment the authenticator is encrypted by the client using the session encryption key shared between the client and the service principal. For the GSK Establishment the authenticator is encrypted by the client using the client's secret key which it shares with the SKDC. A time- stamp prevents replay attacks. The authenticator here is functionally equivalent to the authenticator in the AP-REQ message in RFC4120. The message components as used in the protocol are summarized in Figure 2. Note that all protocol messages are integrity-protected, and some are encrypted. The PSK Message Components Client SKDC | | | | | -------- (1) PSK-REQ, SKDC-REQ-BODY ------> | | | | <--- (2) PSK-REP, Miniticket*, Receipt* --- | | | | | Client SP | | | | | -(3) PSK-ESTB, Miniticket*, Authenticator* --> | | | | <----- (4) PSK-ACK, Acknowledgement* -------- | | | Figure 2 2.3. PSK-Request Message The psk-request message is sent from the client to the SKDC asking for the SKDC to mediate the establishment of a pair-wise shared key between the client and the service principal. The client must indicate the intended service principal in this message. o Protocol version (pvno): This the version of the protocol. Hardjono & Smith Expires September 24, 2015 [Page 11] Internet-Draft Simplified Key Exchange March 2015 o Message type (msg-type): The message type for this message is "PSK-REQ". o SKDC request body (req-body): The request body contains the parameters required by the SKDC to mediate key establishment for the client. See section Section 2.3.1 for the SKDC request body. 2.3.1. SKDC request body The SKDC request body contains the following: o SKDC options - optional (skdc-options): These are optional flags that the client can set. This field is optional. o Client's realm (crealm): This the identity of the realm, domain or group in which the client belongs in connection to this request. o Client's identity (cname): This is the identity of the client. o Service principal's identity (spname): This is the identity of the service principal. o Service principal's realm - optional (sprealm): This the identity of the realm, domain or group in which the service principal belongs in connection to this request. This field is optional. o Client's nonce (nonce): This is the nonce generated by the client. o Desired encryption algorithm (etype): This is the encryption algorithm desired/supported by the client to be used with the service principal. 2.4. PSK-Response Message This psk-response message is sent by the SKDC in response to a received psk-request message from a client. The psk-response message contains the following: o Protocol version (pvno): This the version of the protocol. o Message type (msg-type): The message type for this message is "PSK-REP". o Client's realm (crealm): This the identity of the realm, domain or group in which the client belongs in connection to this request. This is obtained from the psk-request message. Hardjono & Smith Expires September 24, 2015 [Page 12] Internet-Draft Simplified Key Exchange March 2015 o Client's identity (cname): This is the identity of the client obtained from the previous sdkc-request message. o Miniticket (mticket): This is the miniticket structure that is intended for the service principal. See section Section 2.4.1 for the miniticket. o Receipt (receipt): This is the part of the psk-response message that encrypted to the client. It is encrypted using the client's secret key that it shared pair-wise with the SKDC. See section Section 2.4.2 for the receipt. 2.4.1. Miniticket The miniticket is always created by the SKDC and is always intended for the service principal. The miniticket contains a copy of the session encryption key to be delivered to the service principal. As such, the sensitive parts (enc-part) of the miniticket is encrypted using the service principal's secret key (which it shares pair-wise with the KDC). The miniticket contains the following: o Issuing SKDC's realm (skdcrealm): This is the realm of the SKDC that issued the miniticket. o Service Principal's identity (spname): This is the identity of the service principal. o Service principal's realm - optional (sprealm): This the identity of the realm, domain or group in which the service principal belongs in connection to this request. This field is optional. o Encrypted miniticket part (enc-part): This is the encrypted part of the miniticket intended for the service principal. It is encrypted using the secret key shared pair-wise between the SKDC and the service principal. The encrypted part contains the following: * Session encryption key (key): This is the symmetric key generated by the SKDC and to be shared pair-wise between the client and service principal. * Client's realm (crealm): This the identity of the realm, domain or group in which the client belongs in connection to this request. * Client's identity (cname): This is the identity of the client. Hardjono & Smith Expires September 24, 2015 [Page 13] Internet-Draft Simplified Key Exchange March 2015 * Time of authentication (authtime): This is the time at the SKDC when it received the psk-request message. * Expiration time of key (endtime): The is the expiration time of the current session encryption key in this miniticket. * Service principal permissions - optional (sppac): This is the permissions and access control (PAC) structure related to the service principal. This field is optional. * Transited realms - optional (transited): This is the set of SKDC/realms that was involved in the issuance of the miniticket for the service principal. This field is used for cross-realm ticket issuance. This field is optional. 2.4.2. Receipt for PSK The receipt is always created by the SKDC and is always intended for the client. The receipt contains a copy of the session encryption key to be delivered to the client. As such, the receipt is encrypted using the client's secret key (which it shares pair-wise with the KDC). The receipt (receipt) contains the following: o Issuing SKDC's realm (skdcrealm): This is the realm of the SKDC that issued the miniticket. o Service principal's identity (spname): This is the identity of the service principal. o Service principal's realm - optional (sprealm): This the identity of the realm, domain or group in which the service principal belongs in connection to this request. This field is optional. o Session encryption key (key): This is the symmetric key generated by the SKDC and to be shared pair-wise between the client and service principal. o Time of authentication (authtime): This value is the same as found in the encrypted miniticket part. o Expiration time of key (endtime): This value is the same as found in the encrypted miniticket part. o Nonce from the client's request (nonce): This is the nonce from the client's psk-request message. Hardjono & Smith Expires September 24, 2015 [Page 14] Internet-Draft Simplified Key Exchange March 2015 o Client permissions - optional (cpac): This is the permissions and access control (PAC) structure related to the client. This field is optional. 2.5. PSK-Establish Message The psk-establish message is sent from the client to the service principal requesting it to share a key (i.e. the session encryption key) with the service principal. The psk-establish message contains two parts. The first is the miniticket obtained from the SKDC in the previous psk-response message. The second is the authenticator created by the client. The authenticator is encrypted using the session encryption key (which the client obtained in the receipt within the psk-response message). The authenticator authenticates the client to the service principal by virtue of the proof of possession (POP) of the session encryption key by the client to the service principal. This psk-establish message is sent by the client to the service principal. It contains the following: o Protocol version (pvno): This the version of the protocol. o Message type (msg-type): The message type for this message is "PSK-ESTB". o Miniticket (mticket): This is the miniticket structure (unmodified) that the client received from the SKDC in the psk- response message. See Section 2.4.1 for the miniticket. o Authenticator: In the case of a PSK-ESTB message, the authenticator is encrypted using the session encryption key obtained by the client in the receipt (within the psk-response message). See section Section 2.5.1 for the authenticator. 2.5.1. Authenticator The authenticator is the data structure encrypted by the client with the aim of providing proof of possession (of either a PSK or GSK) to the recipient of the authenticator. It is used both in the PSK Establishment flows and the GSK Establishment flows. For the PSK Establishment the authenticator is encrypted by the client using the session encryption key shared between the client and the service principal. The intended recipient of the authenticator in the PSK Establishment flows is the service principal. Hardjono & Smith Expires September 24, 2015 [Page 15] Internet-Draft Simplified Key Exchange March 2015 For the GSK Establishment the authenticator is encrypted by the client using the client's secret key which it shares with the SKDC. The intended recipient of the authenticator in the GSK Establishment flows is the SKDC. The authenticator contains the following: o Client's realm (crealm): This the identity of the realm, domain or group in which the client belongs in connection to this request. o Client's identity (cname): This is the identity of the client. o Client's current time (ctime): This is the time of the client's clock. o Sequence number - optional (seqnum): This is the sequence number used by the client to detect attacks. This field is optional. o Checksum - optional (cksum): This is the keyed-checksum (based on the session encryption key) used by the client as sender. This field is optional. 2.6. PSK-Acknowledge Message The psk-acknowledge message is sent from the service principal to the client in response to the previous psk-establish message. The message contains an acknowledgement part that is encrypted by the service principal using the session encryption key (which the service principal obtain in the miniticket in the previous psk-establsh message). The psk-establish message is sent by the service principal to the client. It contains the following: o Protocol version (pvno): This the version of the protocol. o Message type (msg-type): The message type for this message is "PSK-ACK". o Acknowledgement (sp-ack): This is the acknowledgement structure that contains the following: * Service principal's identity (spname). * Client's current time (ctime). Hardjono & Smith Expires September 24, 2015 [Page 16] Internet-Draft Simplified Key Exchange March 2015 * Sequence number - optional (seqnum): This is the incremented sequence-number, which was found in the previous psk-establish message. This field is optional. 3. Group Shared Key (GSK) Establishment The current protocol supports the establishment of a group-shared key (referred to as the group encryption key) among a number of entities within a constrained environment. The group encryption key affords group-authenticity for messages but not source-authenticity since the symmetric key is shared among multiple entities (members of the multicast group). A client must posses a secret key (shared pair-wise with the SKDC) before the client can request the creation of a new group encryption key at the SKDC. Each group encryption key is associated with an owner (creator) who requested its creation at the SKDC. When a client (e.g. Client#1) seeks to establish a new group encryption key, it sends a GSK-Request message to the SKDC asking that the SKDC generate a new symmetric key (i.e. the group encryption key), return a copy of the group encryption key to the client (via a receipt inside a GSK-Response message) and for the SKDC to retain a copy of the key (for subsequent fetches by other clients). The sensitive parameters of the GSK- Response message (including the group encryption key) inside the receipt is encrypted using the secret key pair-wise shared between the client and the SKDC. When a different client (e.g. Client#2) seeks to obtain a copy of a group encryption key belonging to another client (e.g. Client#1), the Client#2 sends a GSK-Fetch message to the SKDC identifying the multicast group (mcastname) of interest. If a corresponding group or group encryption key does not exist at the SKDC, the SKDC returns an error message. Otherwise, the SKDC returns a copy of the group encryption key (inside a receipt) to the requesting client using the GSK-Deliver message. The sensitive parameters of the GSK-Deliver message (including the group encryption key) inside the receipt is encrypted using the secret key pair-wise shared between the requesting client and the SKDC. Hardjono & Smith Expires September 24, 2015 [Page 17] Internet-Draft Simplified Key Exchange March 2015 The GSK Establishment Flows +------------+ +--------------+ | | | | | |-----(1) GSK-Request ---->| | | Client1 | | | | |<---(2) GSK-Response -----| | | | | | | | | | +------------+ | | | | SKDC | | | | | multicast | | v | | +------------+ | | | | | | | |---- (3) GSK-Fetch ----->| | | Client2 | | | | |<-- (4) GSK-Deliver ----| | | | | | +------------+ +--------------+ Figure 3 The GSK establishment in the protocol consists of two sets of 2-messages each: o Creation of the GSK at the SKDC: * GSK-Request: A client who has a secret key (shared pair-wise with the SKDC) can request the SKDC to create a new group encryption key. The SKDC will retain a copy of the group encryption key (until it expires) and associate it with the multicast group name (mcastname). The client authenticates itself to the SKDC by including an authenticator (encrypted using the client's secret key) in the gsk-request message. * GSK-Response: The requesting client obtains a copy of the new group encryption key via the gsk-response message from the SKDC. The gsk-response message uses the receipt structure to carry the group encryption key. The receipt is encrypted using the client's secret key. o Fetching of a copy of the GSK from the SKDC: * GSK-Fetch: A client who has a secret key (shared pair-wise with the SKDC) can request a copy of a group encryption key from the Hardjono & Smith Expires September 24, 2015 [Page 18] Internet-Draft Simplified Key Exchange March 2015 SKDC. The client must indicate the desired multicast group (mcastname) in the gsk-fetch message. The client authenticates itself to the SKDC by including an authenticator (encrypted using the client's secret key) in the gsk-fetch message. * GSK-Deliver: The requesting client obtains a copy of the group encryption key via the gsk-deliver message from the SKDC. The gsk-deliver message uses the receipt structure to carry the group encryption key. The receipt is encrypted using the client's secret key. The message components as used in the protocol are summarized in Figure 4. Note that all protocol messages are integrity-protected, and some are encrypted. The GSK Message Components Client (Sender) SKDC | | | | | -- (1) GSK-REQ, SKDC-REQ-BODY, Authenticator* --> | | | | <----------- (2) GSK-REP, Receipt* -------------- | | | | | Client (Receiver) SKDC | | | | | -- (1) GSK-FET, SKDC-REQ-BODY, Authenticator* --> | | | | <---------- (2) GSK-DELV, Receipt* -------------- | | | | | Figure 4 3.1. GSK-Request Message The GSK-Request message is sent from the client to the SKDC asking the SKDC to create a new group encryption key. The client authenticates itself to the SKDC by including an authenticator (encrypted using the client's secret key) in the gsk-request message. The contents of the gsk-request message is as follows: Hardjono & Smith Expires September 24, 2015 [Page 19] Internet-Draft Simplified Key Exchange March 2015 o Protocol version (pvno): This the version of the protocol. o Message type (msg-type): The message type for this message is "GSK-REQ". o SKDC request body: The request body contains the parameters required by the SKDC to create a new group encryption key. In the case of the gsk-request message, the service principal name is instead the desired name of the multicast group (mcastname) to be owned by the client. The SKDC keeps an association between the multicast group name and group encryption key. * SKDC options - optional (skdc-options): These are optional flags that the client can set. This field is optional. * Client's realm (crealm): This the identity of the realm, domain or group in which the client belongs in connection to this request. * Client's identity (cname): This is the identity of the client requesting the new group encryption key. * Multicast group identity (mcastname): This is the multicast group name desired by the client. * Multicast group realm - optional (mcastrealm): This is the multicast group realm as desired by the client. This field is optional. * Client's nonce (nonce): This is the nonce generated by the client. * Desired encryption algorithm (etype): This is the encryption algorithm desired/supported by the client for the group encryption key. o Authenticator: In the case of the gsk-request message, the authenticator is encrypted using the client's secret key shared between the client and the SKDC. See section Section 2.5.1 for the authenticator. 3.2. GSK-Response Message The GSK-Response message is sent from the SKDC to the client in response to the client's GSK-Request message. The contents of the GSK-Response message is as follows: Hardjono & Smith Expires September 24, 2015 [Page 20] Internet-Draft Simplified Key Exchange March 2015 o Protocol version (pvno): This the version of the protocol. o Message type (msg-type): The message type for this message is "GSK-REP". o Client's realm (crealm): This the identity of the realm, domain or group in which the client belongs in connection to this request. This is obtained from the gsk-request message. o Client's identity (cname): This is the identity of the client obtained from the previous gsk-request message. o Miniticket (mticket): In the case of the GSK-REP message, miniticket field is empty. o Receipt (receipt): See Section Section 3.2.1for the receipt structure in the case of the GSK-REP (GSK-DELV) message. 3.2.1. Receipt for GSK In the case of the GSK-REP and GSK-DELV messages, the receipt contains the following: o Issuing SKDC's realm (skdcrealm): This is the realm of the SKDC that generated the group encryption key. o Multicast group identity (mcastname): This is the identity of the multicast group. o Multicast group realm - optional (mcastrealm): This is the multicast group realm as desired by the client. This field is optional. o Group encryption key (key): This is the group encryption key generated by the SKDC. o Time of authentication (authtime): This is the time at the SKDC when it received the gsk-request message. o Expiration time of key (endtime): The is the expiration time of the group encryption key. o Nonce from the client's GSK-REQ (GSK-FET) message (nonce): This is the nonce from the client's gsk-request (gsk-fetch) message. o Group permissions - optional (grp-pac): This is the permissions and access control (PAC) structure related to the multicast group. This field is optional. Hardjono & Smith Expires September 24, 2015 [Page 21] Internet-Draft Simplified Key Exchange March 2015 o Transited realms - optional (transited): This is the set of SKDC/ realms that was involved in the issuance of the group encryption key. This field is optional. 3.3. GSK-Fetch Message The GSK-Fetch message is sent by a client to the SKDC asking for a copy of a group encryption key belonging to a group owner. The client must identify the desired multicast group name (mcastname) in the SKDC request body part of the message. The client authenticates itself to the SKDC by including an authenticator (encrypted using the client's secret key) in the gsk-fetch message. The contents of the GSK-Fetch message is as follows: o Protocol version (pvno): This the version of the protocol. o Message type (msg-type): The message type for this message is "GSK-FET". o SKDC request body: The request body in a GSK-FET message has the main purpose of the client identifying the desired multicast group and for the client to deliver a nonce to the SKDC. The SKDC request body contains the following: * SKDC options - optional (skdc-options): These are optional flags that the client can set. This field is optional. * Client's realm (crealm): This the identity of the realm, domain or group in which the client belongs in connection to this request. * Client's identity (cname): This is the identity of the client. * Multicast group identity (mcastname): This is the identity of the desired multicast group as known by the client. * Multicast group realm - optional (mcastrealm): This is the multicast group realm as known by the client. This field is optional. * Client's nonce (nonce): This is the nonce generated by the client. o Authenticator: In the case of the GSK-FET message, this is the data structure encrypted by the client for the SKDC and provides proof of possession to the SKDC of the client secret key. Here the authenticator is encrypted using the secret key shared between Hardjono & Smith Expires September 24, 2015 [Page 22] Internet-Draft Simplified Key Exchange March 2015 the client and the SKDC. See section Section 2.5.1 for the authenticator. 3.4. GSK-Deliver Message The GSK-Deliver message is sent from the SKDC to the client in response to the client's GSK-Fetch message. The GSK-Deliver message uses the receipt structure to carry the group encryption key. The receipt is encrypted using the client's secret key. The contents of the GSK-Deliver message is as follows: o Protocol version (pvno): This the version of the protocol. o Message type (msg-type): The message type for this message is "GSK-DELV". o Client's realm (crealm): This the identity of the realm, domain or group in which the client belongs in connection to this request. This is obtained from the gsk-fetch message. o Client's identity (cname): This is the identity of the client obtained from the previous gsk-fetch message. o Miniticket (mticket): In the case of the GSK-DELV message, the miniticket is empty. o Receipt (receipt): See Section Section 3.2.1 for the receipt structure in the case of the GSK-REP (GSK-DELV) message. 4. JSON Message Format TBD. 5. Encryption and Checksums TBD. 6. Security Considerations TBD. 7. Privacy Considerations TBD. Hardjono & Smith Expires September 24, 2015 [Page 23] Internet-Draft Simplified Key Exchange March 2015 8. IANA Considerations TBD. 9. Acknowledgments We thank Jesse Walker for design inputs and initial review. 10. References 10.1. Normative References [JSON] Bray, T., "The JavaScript Object Notation (JSON) Data Interchange Format", March 2014, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC6347] Rescorla, E., "Datagram Transport Layer Security Version 1.2", January 2012, . [RFC7252] Shelby, Z., "The Constrained Application Protocol (CoAP)", June 2014, . 10.2. Informative References [ACE] Seitz, L., Ed., "ACE Use Cases", October 2012, . [BR-3KPD] Bellare, M. and P. Rogaway, "Entity Authentication and Key Distribution (In Advances in Cryptology, pages 110-125. Springer-Verlag, 1993)", September 1993, . [Choo04] Choo, K., Boyd, C., Hitchcock, Y., and G. Maitland, "On Session Identifiers in Provably Secure Protocols (Security in Communication Networks 4th International Conference, SCN 2004)", September 2004, . [Choo06] Choo, R., "Key Establishment: Proofs and Refutations", May 2006, . Hardjono & Smith Expires September 24, 2015 [Page 24] Internet-Draft Simplified Key Exchange March 2015 [EPID] Brickell, E. and J. Li, "Enhanced Privacy ID (in NIST Privacy Enhancing Cryptography Conference 2011)", December 2011, . [MSKILE] Microsoft, ., "Kerberos Protocol Extensions (v20140502)", May 2014, . [MSPAC] Microsoft, ., "Privilege Attribute Certificate Data Structure (v20140502)", May 2014, . [NS] Needham, R. and M. Schroeder, "Using encryption for authentication in large networks of computers (CACM)", December 1978, . [OAuth2] Hardt, D., "The OAuth 2.0 Authorization Framework", October 2012, . [OIDC] Sakimura, N., "OpenID Connect Core 1.0 incorporating errata set 1", November 2014, . [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for Kerberos V5", February 2005, . [RFC3986] Berners-Lee, T., "Uniform Resource Identifier (URI): Generic Syntax", January 2005, . [RFC4120] Neuman, C., "The Kerberos Network Authentication Service (V5)", July 2005, . [RFC6113] Hartman, S., "A Generalized Framework for Kerberos Pre- Authentication", April 2011, . [TPM] TCG, ., "Trusted Platform Module (TPM) Main Specification Level 2 Version 1.2", March 2011, . Hardjono & Smith Expires September 24, 2015 [Page 25] Internet-Draft Simplified Key Exchange March 2015 [UMACORE] Hardjono, T., Ed., "User-Managed Access (UMA) Profile of OAuth 2.0", November 2014, . Appendix A. Document History NOTE: To be removed by RFC editor before publication as an RFC. Authors' Addresses Thomas Hardjono MIT Email: hardjono@mit.edu Ned Smith Intel Corp Email: ned.smith@intel.com Hardjono & Smith Expires September 24, 2015 [Page 26]