Skip to main content

Fluffy: Simplified Key Exchange for Constrained Environments
draft-hardjono-ace-fluffy-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Thomas Hardjono , Ned Smith
Last updated 2015-03-23
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-hardjono-ace-fluffy-00
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,
              <https://tools.ietf.org/html/rfc7159>.

   [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, <http://tools.ietf.org/html/rfc6347>.

   [RFC7252]  Shelby, Z., "The Constrained Application Protocol (CoAP)",
              June 2014, <http://tools.ietf.org/html/rfc7252>.

10.2.  Informative References

   [ACE]      Seitz, L., Ed., "ACE Use Cases", October 2012,
              <https://tools.ietf.org/wg/ace/draft-ietf-ace-usecases/>.

   [BR-3KPD]  Bellare, M. and P. Rogaway, "Entity Authentication and Key
              Distribution (In Advances in Cryptology, pages 110-125.
              Springer-Verlag, 1993)", September 1993,
              <http://link.springer.com/>.

   [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, <http://link.springer.com/>.

   [Choo06]   Choo, R., "Key Establishment: Proofs and Refutations", May
              2006, <http://eprints.qut.edu.au/16262/1/
              Kim-Kwang_Choo_Thesis.pdf>.

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,
              <http://csrc.nist.gov/groups/ST/PEC2011/presentations2011/
              brickell.pdf>.

   [MSKILE]   Microsoft, ., "Kerberos Protocol Extensions (v20140502)",
              May 2014, <https://msdn.microsoft.com/en-us/library/
              cc233855.aspx>.

   [MSPAC]    Microsoft, ., "Privilege Attribute Certificate Data
              Structure (v20140502)", May 2014,
              <https://msdn.microsoft.com/en-us/library/cc237917.aspx>.

   [NS]       Needham, R. and M. Schroeder, "Using encryption for
              authentication in large networks of computers (CACM)",
              December 1978,
              <http://en.wikipedia.org/wiki/Needham-Schroeder_protocol>.

   [OAuth2]   Hardt, D., "The OAuth 2.0 Authorization Framework",
              October 2012, <http://tools.ietf.org/html/rfc6749>.

   [OIDC]     Sakimura, N., "OpenID Connect Core 1.0 incorporating
              errata set 1", November 2014,
              <http://openid.net/specs/openid-connect-core-1_0.html>.

   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
              Kerberos V5", February 2005,
              <http://tools.ietf.org/html/rfc3961>.

   [RFC3986]  Berners-Lee, T., "Uniform Resource Identifier (URI):
              Generic Syntax", January 2005,
              <http://www.ietf.org/rfc/rfc3986.txt>.

   [RFC4120]  Neuman, C., "The Kerberos Network Authentication Service
              (V5)", July 2005, <http://tools.ietf.org/html/rfc4120>.

   [RFC6113]  Hartman, S., "A Generalized Framework for Kerberos Pre-
              Authentication", April 2011,
              <http://tools.ietf.org/html/rfc6113>.

   [TPM]      TCG, ., "Trusted Platform Module (TPM) Main Specification
              Level 2 Version 1.2", March 2011,
              <http://www.trustedcomputinggroup.org/resources/
              tpm_main_specification>.

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,
              <https://docs.kantarainitiative.org/uma/draft-uma-
              core.html>.

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]