Skip to main content

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

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 2016-01-04
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-02
Network Working Group                                        T. Hardjono
Internet-Draft                                                       MIT
Intended status: Standards Track                                N. Smith
Expires: July 7, 2016                                         Intel Corp
                                                         January 4, 2016

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

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 July 7, 2016.

Copyright Notice

   Copyright (c) 2016 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 July 7, 2016                  [Page 1]
Internet-Draft           Simplified Key Exchange            January 2016

   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  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Notational Conventions  . . . . . . . . . . . . . . . . .   5
     1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   5
     1.3.  Design Considerations and Assumptions . . . . . . . . . .   7
     1.4.  Out of Scope and Non-Goals: . . . . . . . . . . . . . . .   8
   2.  Common Building Blocks  . . . . . . . . . . . . . . . . . . .   9
     2.1.  SKDC Request Body . . . . . . . . . . . . . . . . . . . .   9
     2.2.  Miniticket  . . . . . . . . . . . . . . . . . . . . . . .  10
     2.3.  Receipt . . . . . . . . . . . . . . . . . . . . . . . . .  12
     2.4.  Authenticator . . . . . . . . . . . . . . . . . . . . . .  14
     2.5.  Acknowledgement . . . . . . . . . . . . . . . . . . . . .  15
     2.6.  Key Data  . . . . . . . . . . . . . . . . . . . . . . . .  16
       2.6.1.  Symmetric Key Data  . . . . . . . . . . . . . . . . .  16
       2.6.2.  Asymmetric Key Data . . . . . . . . . . . . . . . . .  16
     2.7.  Key Envelope  . . . . . . . . . . . . . . . . . . . . . .  17
   3.  Pair-wise Shared Key Establishment  . . . . . . . . . . . . .  18
     3.1.  Basic Protocol Exchange . . . . . . . . . . . . . . . . .  18
     3.2.  PSK-Request Message (PSK-REQ) . . . . . . . . . . . . . .  21
     3.3.  PSK-Response Message (PSK-REP)  . . . . . . . . . . . . .  22
     3.4.  PSK-Establish Message (PSK-ESTB)  . . . . . . . . . . . .  24
     3.5.  PSK-Acknowledge Message (PSK-ACK) . . . . . . . . . . . .  25
   4.  Pair-wise Shared Key Deletion . . . . . . . . . . . . . . . .  26
     4.1.  PSK-Delete Message (PSK-DELT) . . . . . . . . . . . . . .  27
     4.2.  PSK-Delete-Confirm Message (PSK-DELC) . . . . . . . . . .  27
   5.  Group Shared Key Establishment  . . . . . . . . . . . . . . .  28
     5.1.  GSK-Request Message (GSK-REQ) . . . . . . . . . . . . . .  31
     5.2.  GSK-Response Message (GSK-REP)  . . . . . . . . . . . . .  33
     5.3.  GSK-Fetch Message (GSK-FET) . . . . . . . . . . . . . . .  34
     5.4.  GSK-Deliver Message (GSK-DLVR)  . . . . . . . . . . . . .  35
   6.  Group Shared Key Deletion . . . . . . . . . . . . . . . . . .  36
     6.1.  GSK-Delete Message (GSK-DELT) . . . . . . . . . . . . . .  37
     6.2.  GSK-Delete-Confirm Message (GSK-DELC) . . . . . . . . . .  38
   7.  Public Key Pair Establishment . . . . . . . . . . . . . . . .  39
     7.1.  Public Key Pair Request (PKP-REQ) . . . . . . . . . . . .  40
     7.2.  Public Key Pair Response (PKP-REP)  . . . . . . . . . . .  42
   8.  JSON Message Format . . . . . . . . . . . . . . . . . . . . .  44
   9.  Encryption and Checksums  . . . . . . . . . . . . . . . . . .  44
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  44
   11. Privacy Considerations  . . . . . . . . . . . . . . . . . . .  44
   12. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  44
   13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  44
   14. References  . . . . . . . . . . . . . . . . . . . . . . . . .  44

Hardjono & Smith          Expires July 7, 2016                  [Page 2]
Internet-Draft           Simplified Key Exchange            January 2016

     14.1.  Normative References . . . . . . . . . . . . . . . . . .  44
     14.2.  Informative References . . . . . . . . . . . . . . . . .  45
   Appendix A.  Document History . . . . . . . . . . . . . . . . . .  46
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  46

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
   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.  A
      further two messages are used to delete the key prior to its
      expiration.

   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

Hardjono & Smith          Expires July 7, 2016                  [Page 3]
Internet-Draft           Simplified Key Exchange            January 2016

      which new group members (e.g. client#2) must ask for a copy of the
      group-key from the SKDC.

   An additional set of exchanges are introduced to support the delivery
   of a public key pair to a client entity, with or without an
   accompanying digital certificate.

   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
   the human owner.  The topic of on-boarding and off-boarding of
   devices is outside the scope of the current specification.

   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.

Hardjono & Smith          Expires July 7, 2016                  [Page 4]
Internet-Draft           Simplified Key Exchange            January 2016

   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].

   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.

Hardjono & Smith          Expires July 7, 2016                  [Page 5]
Internet-Draft           Simplified Key Exchange            January 2016

   miniticket
         This is the data structure that carries the symmetric key to be
         shared between the client and service principal.

   receipt
         This is the data structure that carries the symmetric key from
         the SKDC to an entity (client or service principal).

   authenticator
         This is the data structure that carries proof-of-possession of
         a shared symmetric key between two entities.

   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
         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

Hardjono & Smith          Expires July 7, 2016                  [Page 6]
Internet-Draft           Simplified Key Exchange            January 2016

         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 and Assumptions

   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-
      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.  As such, the current Fluffy protocol begins with

Hardjono & Smith          Expires July 7, 2016                  [Page 7]
Internet-Draft           Simplified Key Exchange            January 2016

      the assumption that each entity (client and service principal)
      already shares pair-wise a secret key with the SDKC.  This secret
      key should be used only for key-management related messages as
      defined in this specification.  Additionally, in this
      specification we have avoided the use of the term "long-term key"
      to refer to this secret key due to the broad meaning of this term.

   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.

   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
      or TLS are out of scope in the current specification.

   Certificate Issuance and Management:  Issuance of X509 digital
      certificates and certificate management (in the sense of RFC2459,
      RFC2797 and RFC4210) is out of scope in the current specification.

Hardjono & Smith          Expires July 7, 2016                  [Page 8]
Internet-Draft           Simplified Key Exchange            January 2016

2.  Common Building Blocks

   The current protocol employs a number of data structures that are
   common across several message types.  A number of these data
   structures have semantic equivalents in RFC4120, while some are newly
   introduced.

   Depending on the message type, some fields may be overloaded in its
   usage.  For example, in the PSK-Request message the client states the
   identity and realm of the service principal within the SKDC-REQ-BODY.
   This is similar to RFC4120 because three (3) parties are involved in
   a PSK establishment (initiated by the client sending a PSK-Request
   message to the SKDC).  However, when the SKDC-REQ-BODY is used in GSK
   establishment (initiated by an entity sending the SKDC a GSK-Request
   (GSK-REQ) message) the identity and realm fields are used instead to
   communicate the desired identity and the realm of the multicast
   group.

   Two building blocks that do not have equivalents in RFC4120 are the
   Key Data and the Key Envelope structures:

      Key Data: The keydata structure is used to convey cryptographic
      key(s) together with the associated operational parameters for the
      key(s).  The structure of the keydata follows the JSON Web Key
      (JWK) definition of keys and keying material [RFC7517].  This is a
      departure from RFC4120.

      Key Envelope: The key envelope is used to convey parameters
      related to a key (e.g.  KeyID) but not the key itself.  It is used
      in cases where entities need to refer to a key (e.g. group-key)
      without having to carry the key in the message.

   In the following the common building blocks are discussed.

2.1.  SKDC Request Body

   The SKDC request body (SKDC-REQ-BODY) carries specific information
   regarding the type of request and the entities involved in the
   message.  This data structure is used in the initial request send
   from a client (or SP) to the SKDC.

   The SKDC-REQ-BODY varies slightly when used in the PSK-REQ and GSK-
   REQ messages.

   SKDC-REQ-BODY:

   o  Key Type (kty): This denotes the type of key being requested by
      the sender (client or SP) of the request.

Hardjono & Smith          Expires July 7, 2016                  [Page 9]
Internet-Draft           Simplified Key Exchange            January 2016

   o  Desired algorithm (etype): This is the algorithm that is desired
      (or supported) by the sender of the request (client or SP) .

   o  SKDC options - optional (skdc-options): These are flags that are
      intended for the SKDC only.  This field is optional.

   o  SKDCs realm (skdcrealm): This the name of the realm, domain or
      zone of the SKDC.

   o  SKDC's identity (skdcname): This is the identity of the SKDC.

   o  Service principal's realm - optional (sprealm): This the name of
      the realm, domain or zone of the service principal in a PSK-REQ
      message.  In a GSK-REQ message it is the realm of the multicast
      group.  This field is optional.

   o  Service principal's identity (spname): In a PSK-REQ message this
      is the identity of the service principal.  In a GSK-REQ message it
      is the identity or name of the multicast group.

   o  Client permissions - optional (cpac): In a PSK-REQ message this is
      the permisions desired by the client for itself.  In a GSK-REQ
      message this is the permisions desired by the client for the
      multicast group.  This field is optional.

2.2.  Miniticket

   The miniticket is always created by the SKDC and is always intended
   for the service principal (although it is delivered via the client
   who initiates with the PSK-REQ message).  The SKDC responds to the
   client by sending a PSK-Response (PSK-REP) message containing the
   miniticket and a receipt.  The miniticket contains a copy of the
   session encryption key to be delivered to the service principal by
   the client in a PSK-Establish (PSK-ESTB) message.  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 is functionally equivalent to the service-
   ticket in RFC4120.

   The miniticket contains the following:

   o  Issuing SKDC's realm (skdcrealm): This the name of the realm,
      domain or zone of the SKDC that issued this miniticket.

   o  Issuing SKDC's identity (skdcname): This is the identity of the
      SKDC that issued this miniticket.

Hardjono & Smith          Expires July 7, 2016                 [Page 10]
Internet-Draft           Simplified Key Exchange            January 2016

   o  Service principal's realm - optional (sprealm): This the name of
      the realm, domain or zone of the service principal for whom this
      miniticket is destined.  This field is optional.

   o  Service Principal's identity (spname): This is the identity of the
      service principal for whom this miniticket is destined.

   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:

      *  Ticket flags - optional (tflags): This is the flags set by the
         SKDC for the service principal concerning this ticket.  This
         field is optional.

      *  Client's realm (crealm): This the name of the realm, domain or
         zone of the client with whom the receiver of this miniticket
         shares the enclosed key.

      *  Client's identity (cname): This is the identity of the client
         with whom the receiver of this miniticket shares the enclosed
         key.

      *  Client permissions - optional (cpac): This is the permissions
         and access control (PAC) structure containing permissions
         granted to the client associated with the enclosed key.  This
         field is optional.

      *  Time of authentication (authtime): This is the time at the SKDC
         when it created this miniticket in response to a request.

      *  Expiration time of key (endtime): The is the expiration time of
         the key in this miniticket.

      *  Service principal permissions - optional (sppac): This is the
         permissions and access control (PAC) structure granted to the
         service principal associated with the enclosed key.  This field
         is optional.

      *  Transited realms - optional (transited): This is the set of
         SKDCs and 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.

      *  Key data (keydata): This fields contains the key-data structure
         that carries the cryptographic key and other parameters

Hardjono & Smith          Expires July 7, 2016                 [Page 11]
Internet-Draft           Simplified Key Exchange            January 2016

         necessary for operating the key.  See section Section 2.6 for
         the key-data structure.

2.3.  Receipt

   The receipt is always created by the SKDC and is used for the SKDC to
   deliver a key to a requesting party (be it client, service principal
   or multicast group members).  The receipt is functionally equivalent
   to the SKDC-Response part in RFC4120.

   In The PSK estabslishment flows the receipt is used to deliver the
   new session encryption key to the requesting client in a PSK-REP
   message from the SKDC.

   In The GSK establishment flows the receipt is used to deliver the new
   group encryption key to the requesting entity using the GSK-Response
   (GSK-REP) message.  Similarly, members of a multicast group must
   individually request a copy of the group key using the GSK-Fetch
   message (GSK-FET), to which the SDKC will send a receipt structure
   containing a copy of the group key via the GSK-Deliver (GSK-DLVR)
   message.

   When used in a PSK-REP message as a response to the client's request
   for a new session encryption key, the receipt names the service
   principal who is to share the key with the client.  The service
   principal identified in this receipt is the same as that stated in
   the matching miniticket.

   When used in a GSK-REP message for a new group-key creation, the
   receipt instead names the multicast group with associated with this
   key.  Note that the GSK-REP message has no accompanying miniticket
   because the SKDC is reponding solely to the requester of the new
   group-key in a 2-party flow.  The receipt in a GSK-Deliver (GSK-DLVR)
   message (to deliver a copy of the group-key to members of the
   multicast group) is functionally identical to the receipt in the GSK-
   REP message.

   A note about convention: in the remainder of this specification the
   entity that requests the creation of a group-key is denoted as the
   service principal (SP).  The members of the multicast group are
   denoted as the client.

   Receipt:

   o  Receipts flags - optional (rflags): This is the flags set by the
      SKDC concerning this receipt.  This field is optional.

Hardjono & Smith          Expires July 7, 2016                 [Page 12]
Internet-Draft           Simplified Key Exchange            January 2016

   o  Issuing SKDC's realm (skdcrealm): This the name of the realm,
      domain or zone of the SKDC that issued this receipt.

   o  Issuing SKDC's identity (skdcname): This is the identity of the
      SKDC that issued this receipt.

   o  Realm - optional (sprealm or mcastrealm): This field is optional,
      and is used as follows:

      *  sprealm: In a PSK-REP message, sprealm is used.  This is the
         name of the realm, domain or zone of the service principal with
         whom the client (recipient of this receipt) shares the enclosed
         session encryption key.

      *  mcastrealm: In a GSK-REP message and GSK-DLVR message, the
         mcastrealm is used.  This is the realm of the multicast group
         associated with the enclose group encryption key.

   o  Name of entity sharing this key (spname or mcastname):

      *  spname: In a PSK-REP message, spname is used.  This is the
         identity of the service principal who will be sharing the
         enclosed session encryption key with requesting client.

      *  mcastname: In a GSK-REP message and GSK-DLVR message, mcastname
         is used.  This is the identity of the multicast group
         associated with the enclosed group encryption key.

   o  Service Principal's SKDC - optional (spskdc): This field is
      optional.  In a PSK-REP message, this is the identity of the
      service principal's SKDC.  This field is absent in receipts used
      in a GSK-REP message or GSK-DLVR message.

   o  Permissions - optional (cpac or grppac): This field is optional.
      This is the permissions and access control (PAC) structure
      containing permissions granted, associated with the enclosed key.

      *  cpac: In a PSK-REP message, the permissions pertains to the
         client who requested the session encryption key.

      *  grppac: In a GSK-REP message or GSK-DLVR message, the
         permissions pertain to the members of the multicast group who
         share this common group encryption key.

   o  Time of authentication (authtime): This is the time at the SKDC
      when it created this receipt.

Hardjono & Smith          Expires July 7, 2016                 [Page 13]
Internet-Draft           Simplified Key Exchange            January 2016

   o  Nonce from the sender's request (nonce): This is the nonce found
      in the previous request message (either PSK-REQ message or GSK-REQ
      message).

   o  Expiration time of key (endtime): The is the expiration time of
      the key in this receipt.

   o  Key data (keydata): This fields contains the key-data structure
      that carries the cryptographic key and other parameters necessary
      for operating the key.  In a PSK-REP message, this key is the
      session encryption key to be shared between the client and service
      principal.  In a GSK-REP message or GSK-DLVR message this is the
      group encryption key to be shared by the multicast group members.
      See section Section 2.6 for the key-data structure.

2.4.  Authenticator

   The authenticator is used by a sender to provide proof-of-possession
   (POP) to a receiver of a given key that the sender shares with the
   receiver.  The authenticator here is functionally equivalent to the
   authenticator in RFC4120.

   In the PSK-REQ and GSK-REQ messages, the requesting entity uses the
   authenticator to "authenticate" itself to the SKDC by providing
   proof-of-possession of the secret key which it shares pair-wise with
   the SKDC.  Note that this mode of usage of the authenticator departs
   from RFC4120 where a key request message (namely the AP-REQ in
   RFC4120) is not accompanied by an authenticator.

   In the PSK establishment flows, the authenticator is used also in the
   PSK-ESTB message that is sent from the client to the service
   principal.  More specifically, in the PSK-ESTB message the client
   encrypts the authenticator using the session encryption key that the
   client obtained in the previous PSK-REP message it received from the
   SKDC.  Here the authenticator proves to the service principal that
   the client knows the session encryption key that is enclosed in the
   accompanying miniticket.

   The authenticator is also used in the PSK deletion and GSK deletion
   flows where the SKDC accompanies its PSK-DELT and GSK-DELT messages
   respectively with an authenticator that proves to the intended
   recipient of the message that the SKDC knows the secret key shared
   pair-wise with that recipient.  As such, the authenticator can be
   used as a generic mechanism to provide proof-of-possession of a
   shared key between two entities.

   Using the example of a client sending an authenticator to a service
   principal, the authenticator contains the following:

Hardjono & Smith          Expires July 7, 2016                 [Page 14]
Internet-Draft           Simplified Key Exchange            January 2016

   o  Client's realm (crealm): This the identity of the realm, domain or
      zone of the client that created the authenticator.

   o  Client's identity (cname): This is the identity of the client that
      created the authenticator.

   o  Client's current time (ctime): This is the time at the client when
      it created the authenticator.

   o  Nonce (nonce): This is a new nonce generated by the client (for
      the recipient of the authenticator).

   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.5.  Acknowledgement

   The acknowledgement structure (ack) is used by one entity to send a
   positive acknowledgement to another entity regarding a message that
   was previously exchanged.  The acknowledgement would carry a nonce
   that was found in the related previous message.  The type of
   acknowledgement is expressed in the enveloping header message (e.g.
   PSK-ACK type acknowleges a previous PSK-ESTB message).

   Note that the acknowledgement structure is intended to be generic,
   and as such can also be used by the SKDC to send an acknowledgement
   to a client or service principal.

   Using the example of a service principal (sender) sending the an
   acknowledgement to a client (receiver), the acknowledgement structure
   contains the following:

   o  Service principal's realm - optional (sprealm): This the identity
      of the realm, domain or zone of the service principal who created
      this acknowledment.  This field is optional.

   o  Service Principal's identity (spname): This is the identity of the
      service principal for who created this acknowledgement.

   o  Nonce from the client's previous message (nonce): This is the
      nonce found in the previous message being acknowledged.

   o  Time of authentication (authtime): This is the time at the service
      principal when it created this acknowledgement message.

Hardjono & Smith          Expires July 7, 2016                 [Page 15]
Internet-Draft           Simplified Key Exchange            January 2016

   o  Sequence number - optional (seqnum): This is the sequence number
      used to detect attacks.  This field is optional.

2.6.  Key Data

   The key-data structure is used to carry cryptographic keys and the
   related parameters needed to operate the keys.  The construction of
   the key-data structure follows that of the JSON Web Keys [RFC7517]
   which supports not only symmetric keys, but also public key pairs and
   X509 certificates.

   The intent is to support the delivery of either a single symmetric
   key, a public key pair or one key (half) of a public key pair.

   Delivery of an array of keys is for future consideration.

2.6.1.  Symmetric Key Data

   The key-data structure for carrying a symmetric key is as follows.

   o  Key type (kty): This is the type of key contained in the current
      key-data structure.

   o  Key ID - optional (keyid): This is the name or handle for the key
      that can be be referred to by parties sharing they key.  This
      field is optional.

   o  Key (key): This is the symmetric key.

   o  Key operations parameters (keyops): This is parameters required to
      operate the cryptographic key.

   o  Algorithm (alg): This is the algorithm name for the use of the
      key.

2.6.2.  Asymmetric Key Data

   The key-data structure for carrying an asymmetric key and parameters
   is as follows.

   o  Key type (kty): This is the type of key contained in the current
      key-data structure.

   o  Key ID - optional (keyid): This is the name or handle for the key
      that can be be referred to by parties sharing they key.  This
      field is optional.

   o  Key (key): This is the public key.

Hardjono & Smith          Expires July 7, 2016                 [Page 16]
Internet-Draft           Simplified Key Exchange            January 2016

   o  Key operations parameters (keyops): This is parameters required to
      operate the cryptographic key.

   o  Algorithm (alg): This is the algorithm name for the use of the
      key.

   o  Public key usage (pkuse): For public keys this field indicates the
      use of the key.  See RFC7517.

   o  X509 URL parameter (x5u): This parameter is a URI [RFC3986] that
      refers to a resource for an X.509 public key certificate or
      certificate chain [RFC5280].  See RFC7517.

   o  X509 certificate chains parameter - optional (x5c): This parameter
      contains a chain of one or more PKIX certificates [RFC5280].  See
      RFC7517.

   o  X509 thumbprint parameter - optional (x5t): This parameter
      contains a base64url-encoded SHA-1 thumbprint (a.k.a. digest) of
      the DER encoding of an X.509 certificate [RFC5280].  See RFC7517.

   o  X509 SHA256 thumbprint parameter - optional (x5t256): This
      parameter contains a base64url-encoded SHA-256 thumbprint (a.k.a.
      digest) of the DER encoding of an X.509 certificate [RFC5280].
      See RFC7517.

2.7.  Key Envelope

   The key envelope structure is used in messages that refer to a
   cryptographic key by its KeyID.  As such, the key envelope structure
   by definition must never carry any cryptographic keys or keying
   material.

   The key envelope is used primarily in the deletion of a a PSK or a
   GSK.  When the SKDC wishes to delete a given PSK that it shares with
   an entity, it can refer to the target key by way of the KeyID in the
   key envelope.

   In order to delete a PSK that a client and service principal shares
   (through the mediation of the SKDC via a previous 3-party PSK
   establishment flow), the SKDC must separately delete the PSK at the
   client and at the service principal (i.e. using two separate PSK-
   Delete (PSK-DELT) messages).

   The key envelope is encrypted using the secret key shared between the
   SKDC and the entity (client or service principal) for whom the
   envelope is destined.

Hardjono & Smith          Expires July 7, 2016                 [Page 17]
Internet-Draft           Simplified Key Exchange            January 2016

   The key envelope must never be encrypted using the target key that is
   to be deleted.

   The key envelope structure contains the following:

   o  Envelope Flags - optional (envflags): This is the flags related to
      the envelope.  This field is optional.

   o  Issuing SKDC's realm (skdcrealm): This the name of the realm,
      domain or zone of the SKDC that issued this envelope.

   o  Issuing SKDC's identity (skdcname): This is the identity of the
      SKDC that issued this envelope.

   o  Current time (authtime): This is the time at the SKDC when it
      created the encrypted envelope.

   o  Nonce (nonce): This is a new nonce generated by the SKDC (for the
      recipient of the envelope).

   o  Sequence number - optional (seqnum): This is the sequence number
      to detect attacks.  This field is optional.

   o  Key data (keydata): This is the key-data structure which contains
      the KeyID of the target key.  The key-data in a key envelope must
      not contain any cryptographic keys.  See section Section 2.6 for
      the key-data structure.

3.  Pair-wise Shared Key Establishment

   This section describes the pair-wise key establishment between the
   client and the service principal.

3.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 a direct consequence of
   the on-boarding or take-ownership process.

   The PSK establishment 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.

   Note that unlike RFC4120, the client must provide an authenticator in
   its first message (PSK-Request) to the SKDC.  This authenticator is

Hardjono & Smith          Expires July 7, 2016                 [Page 18]
Internet-Draft           Simplified Key Exchange            January 2016

   encrypted by the client using the secret key it shares pair-wise with
   the SKDC.

   The message flows consists of the following steps and are summarized
   in Figure 1.

   o  PSK-Request (PSK-REQ): 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.  Unlike RFC4120 the client must include
      an authenticator that is encrypted to the SKDC as a proof of
      possession of the secret key it shares with the SKDC.

   o  PSK-Response (PSK-REP): 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.  The client must forward the
      miniticket unmodified to the service principal in the PSK-
      Establish message.

   o  PSK-Establish (PSK-ESTB): 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 verify the authenticator (by decrypting it).  At
      this point the client and the service principal shares the session
      encryption key.

   o  PSK-Acknowledge (PSK-ACK): The service principal exercises the
      newly received session encryption key by encrypting an
      acknowledgement message to 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 July 7, 2016                 [Page 19]
Internet-Draft           Simplified Key Exchange            January 2016

                        The PSK Establishment Flows

      +------------+                          +--------------+
      |            |                          |              |
      |            |-----(1) PSK-Request ---->|              |
      |            |                          |     SKDC     |
      |            |<---(2) PSK-Response -----|              |
      |            |                          |              |
      |   Client   |                          +--------------+
      |            |
      |            |                          +--------------+
      |            |---- (3)PSK-Establish --->|              |
      |            |                          |     SP       |
      |            |<--- (4)PSK-Acknowledge --|              |
      |            |                          |              |
      +------------+                          +--------------+

                                 Figure 1

   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

Hardjono & Smith          Expires July 7, 2016                 [Page 20]
Internet-Draft           Simplified Key Exchange            January 2016

3.2.  PSK-Request Message (PSK-REQ)

   The PSK-Request (PSK-REQ) 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.

   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.1 for more information on the
      SKDC request body.  The SKDC request body of a PSK-REQ message
      contains the following:

      *  Key Type (kty): This is type of key being requested by the
         client from the SKDC.

      *  Desired algorithm (etype): This is the algorithm that is
         desired (or supported) by the client.

      *  SKDC options - optional (skdc-options).

      *  SKDC's realm (skdcrealm).

      *  SKDC's identity (skdcname).

      *  Service principal's realm - optional (sprealm).

      *  Service principal's identity (spname).

      *  Client permissions - optional (cpac).

   o  Authenticator (authenticator): This is the authenticator encrypted
      by the client to the SKDC using the secret key that the client
      shares with the SKDC.  See Section Section 2.4 for more
      information on the authenticator structure.

   o  Extensions - optional (ext): Reserved for future extensions.  This
      field is optional.

Hardjono & Smith          Expires July 7, 2016                 [Page 21]
Internet-Draft           Simplified Key Exchange            January 2016

3.3.  PSK-Response Message (PSK-REP)

   The PSK-Response (PSK-REP) is sent by the SKDC to the client as a
   response to the client's previous PSK-REQ message.  The PSK-REP
   message carries two crucial data structures, namely the miniticket
   and the receipt.

   The miniticket here is intended solely for the service principal and
   carries a copy of the session encryption key (key) intended for the
   service principal.  As such the miniticket is encrypted to the
   service principal using the secret key shared between the SKDC and
   service principal.  Although the miniticket is returned to the
   client, the client is unable to view or modify the encrypted parts of
   the miniticket.

   The receipt here is intended solely for the client and carries a copy
   of the session encryption key (key) intended for the client.  The
   receipt is encrypted to the client using the secret key shared
   between the SKDC and client.

   The PSK-REP 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 name of the realm, domain or
      zone in which the client belongs in connection to this request.

   o  Client's identity (cname): This is the identity of the client.

   o  Miniticket (mticket): The miniticket contains the following:

      *  Issuing SKDC's realm (skdcrealm).

      *  Issuing SKDC's identity (skdcname).

      *  Service principal's realm - optional (sprealm).

      *  Service Principal's identity (spname).

      *  Encrypted miniticket part (enc-part): This is the part of the
         PSK-REP message that is encrypted by the SKDC to the service
         principal, using the secret key that the SKDC shares pair-wise
         with the service principal.  It contains the following:

         +  Ticket flags - optional (tflags).

Hardjono & Smith          Expires July 7, 2016                 [Page 22]
Internet-Draft           Simplified Key Exchange            January 2016

         +  Client's realm (crealm): This the name of the realm, domain
            or zone in which the client belongs in connection to this
            request.

         +  Client's identity (cname).

         +  Client permissions - optional (cpac).

         +  Time of authentication (authtime).

         +  Expiration time of this key (endtime).

         +  Service principal permissions - optional (sppac).

         +  Transited realms - optional (transited).

         +  Key data (keydata): This key-data structure contains a copy
            of the session encryption key destined for the service
            principal.  See section Section 2.6 for the key-data
            structure.

   o  Receipt (receipt): This is the part of the PSK-REP message that is
      encrypted by the SKDC to the client, using the secret key that the
      SKDC shares pair-wise with the client.  It contains the following:

      *  Receipts flags - optional (tflags).

      *  Issuing SKDC's realm (skdcrealm).

      *  Issuing SKDC's identity (skdcname).

      *  Service principal's realm - optional (sprealm).

      *  Service Principal's identity (spname).

      *  Service Principal's SKDC - optional (spskdc).

      *  Client permissions - optional (cpac).

      *  Time of authentication (authtime).

      *  Nonce from the Client's previous PSK-REQ request message
         (nonce).

      *  Expiration time of this key (endtime).

Hardjono & Smith          Expires July 7, 2016                 [Page 23]
Internet-Draft           Simplified Key Exchange            January 2016

      *  Key data (keydata): This key-data structure contains a copy of
         the session encryption key destined for the client.  See
         section Section 2.6 for the key-data structure.

   o  Extensions - optional (ext): Reserved for future extensions.  This
      field is optional.

3.4.  PSK-Establish Message (PSK-ESTB)

   The PSK-Establish (PSK-ESTB) message is sent from the client to the
   service principal requesting it to share a key (i.e. the session
   encryption key).  The PSK-ESTB message contains two parts.  The first
   is the miniticket obtained by the client from the SKDC in the
   previous PSK-Response (PSK-REP) 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 from the previous PSK-REP from the
   SKDC).

   The authenticator proves to the service principal that the client is
   in possession of the session encryption key.

   This PSK-ESTB 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  Client's realm (crealm): This the name of the realm, domain or
      zone of the client.

   o  Client's identity (cname): This is the identity of the client.

   o  Miniticket (mticket): This is the miniticket structure
      (unmodified) that the client received from the SKDC in the
      previous PSK-REP message.  See Section Section 3.3 for the
      miniticket in the PSK-REP message.

   o  Authenticator: The authenticator in the PSK-ESTB contains the
      following:

      *  Client's realm (crealm).

      *  Client's identity (cname).

Hardjono & Smith          Expires July 7, 2016                 [Page 24]
Internet-Draft           Simplified Key Exchange            January 2016

      *  Client's current time (ctime).

      *  A new nonce generated by the client for the service principal
         (nonce).

      *  Sequence number - optional (seqnum).

      *  Checksum - optional (cksum).

   o  Extensions - optional (ext): Reserved for future extensions.  This
      field is optional.

3.5.  PSK-Acknowledge Message (PSK-ACK)

   The PSK-Acknowledge (PSK-ACK) message is sent from the service
   principal to the client in response to the previous PSK-ESTB message.

   The message contains an acknowledgement part that is encrypted by the
   service principal using the session encryption key (which the service
   principal obtained in the miniticket in the previous PSK-ESTB
   message).

   The PSK-ACK 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-ACK".

   o  Client's realm (crealm).

   o  Client's identity (cname).

   o  Acknowledgement (ack): This is the acknowledgement structure that
      contains the following:

      *  Service principal's identity (spname).

      *  Service principal's realm - optional (sprealm).

      *  Nonce from the Client's previous PSK-ESTB message (nonce).

      *  Time of authentication (authtime).

      *  Sequence number (inremented) from PSK-ESTB message - optional
         (seqnum).

Hardjono & Smith          Expires July 7, 2016                 [Page 25]
Internet-Draft           Simplified Key Exchange            January 2016

   o  Extensions - optional (ext): Reserved for future extensions.  This
      field is optional.

4.  Pair-wise Shared Key Deletion

   The current protocol supports the proactive deletion by the SKDC of a
   pairwise shared key (PSK) prior to the expiration of the key.  The
   target PSK to be deleted must be a PSK that a client and service
   principal had established through the mediation of the SKDC using the
   PSK establishment flow.

   Only the SKDC has the authority to send a key-deletion message (PSK-
   DELT) to an entity (client or service principal).  A client or
   service principal MUST ignore key-deletion messages which did not
   come from the SKDC.

   The SKDC authenticates itself to the client (service principal) by
   including a key envelope that is encrypted using the secret key
   shared between the SKDC and the client (service principal).  The key
   envelope identifies the target key to be deleted by its key-ID.

   If a PSK-DELT message issued by the SKDC is received at the client
   after the named key has in fact expired, the client must still
   respond with a PSK-Delete-Confirm (PSK-DELC) message.  This confirms
   to the SKDC that the named key no longer exists at the client.

   In order to delete a PSK that a client and service principal shares
   (through the mediation of the SKDC via a PSK establishment flow), the
   SKDC must delete the PSK at the client and at the service principal
   separately (using two separate PSK-DELT messages respectively).

   The message components as used in the protocol are summarized in
   Figure 3.

                     The PSK Delete Message Components

        SKDC                                         Client
          |                                             |
          |                                             |
          | ------- (1) PSK-DELT, Kenvelope*  --------> |
          |                                             |
          | <--- (2) PSK-DELC, Acknowledgement* ------- |
          |                                             |
          |                                             |

                                 Figure 3

Hardjono & Smith          Expires July 7, 2016                 [Page 26]
Internet-Draft           Simplified Key Exchange            January 2016

4.1.  PSK-Delete Message (PSK-DELT)

   The PSK-DELT message is sent from the SKDC to a client (or service
   principal) asking for the delition or erasure of the PSK identified
   in the message.  The SKDC must indicate the intended recipient in
   this message.

   o  Protocol version (pvno): This is the version of the protocol.

   o  Message type (msg-type): The message type for this message is
      "PSK-DELT".

   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  Key Envelope (kenvelope): The key envelope is encrypted using the
      client's secret key that it shared with the SKDC.  The key
      envelope contains the following:

      *  Envelope Flags - optional (envflags).

      *  Issuing SKDC's realm (skdcrealm).

      *  Issuing SKDC's identity (skdcname).

      *  Current time (authtime).

      *  New nonce generated by the SKDC (nonce).

      *  Sequence number - optional (seqnum).

      *  Key data (keydata): This key-data structure contains the KeyID
         of the target key to be deleted.  The key-data in a key
         envelope must never contain a cryptographic key.  See section
         Section 2.6 for the key-data structure.

   o  Extensions - optional (ext): Reserved for future extensions.  This
      field is optional.

4.2.  PSK-Delete-Confirm Message (PSK-DELC)

   The psk-delete-confirm (PSK-DELC) message is sent from the client (or
   service) to the SKDC confirming the removal of the PSK identified in
   the previous PSK-DELT message.  A client (or service principal) must
   only send the PSK-DELC message after it has successfully remove or
   erase the target key from its key store.

Hardjono & Smith          Expires July 7, 2016                 [Page 27]
Internet-Draft           Simplified Key Exchange            January 2016

   The acknowledgement in the PSK-DELC message is encrypted by the
   client using the secret key that the client shares with the SKDC.
   See Section Section 2.5 for more information on the acknowledgement
   structure.

   The PSK-DELC message contains the following:

   o  Protocol version (pvno): This is the version of the protocol.

   o  Message type (msg-type): The message type for this message is
      "PSK-DELC".

   o  SKDC's realm - optional (skdcrealm).

   o  SKDC's identity (skdcname).

   o  Acknowledgement (ack):

      *  Client's identity (cname).

      *  Client's realm - optional (crealm).

      *  Nonce from the SKDC's previous PSK-DELT message (nonce).

      *  Client's current time (authtime).

      *  Sequence number - optional (seqnum): This field is optional.

   o  Extensions - optional (ext): Reserved for future extensions.  This
      field is optional.

5.  Group Shared Key Establishment

   The current protocol supports the establishment of a group-shared
   symmetric key (referred to as the "group encryption key" or "group-
   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).  See RFC3740 for
   further discussion regarding multicast group security.

   In the following we use the notation of the service principal (SP) as
   the entity that initiates the multicast group creation by requesting
   the SKDC to create a new group encryption key and to maintain a copy
   of that group-key until such time it expires or is deleted.  The
   clients that request and obtain a copy of the group-key are denoted
   as "members" of the group.  The current specification follows the

Hardjono & Smith          Expires July 7, 2016                 [Page 28]
Internet-Draft           Simplified Key Exchange            January 2016

   convention that only the group-creator and the SKDC are permitted to
   proactively delete a group encryption key.

   Using the service principal as the group-creator, the service
   principal must accompany its request to the SKDC with an
   authenticator.

   Each group encryption key is associated with an owner (creator) who
   requested its creation at the SKDC.  When an SP 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
   service principal (via a receipt inside a GSK-Response message) and
   for the SKDC to retain a copy of the group key (for subsequent
   fetches by the 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 SP and the SKDC.

   When a client seeks to obtain a copy of a group encryption key
   associated with a multicast group, the client sends a GSK-Fetch
   message to the SKDC identifying the multicast group (mcastname) of
   interest.  The requesting client must accompany the request with an
   authenticator that is encrypted using the secret key shared between
   the client and the SKDC.

   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 July 7, 2016                 [Page 29]
Internet-Draft           Simplified Key Exchange            January 2016

                        The GSK Establishment Flows

      +------------+                          +--------------+
      |            |                          |              |
      |            |-----(1) GSK-Request ---->|              |
      |     SP     |                          |              |
      |            |<---(2) GSK-Response -----|              |
      |            |                          |              |
      |            |                          |              |
      +------------+                          |              |
             |                                |     SKDC     |
             |                                |              |
             | multicast                      |              |
             v                                |              |
      +------------+                          |              |
      |            |                          |              |
      |            |---- (3) GSK-Fetch  ----->|              |
      |   Client   |                          |              |
      |            |<-- (4) GSK-Deliver   ----|              |
      |            |                          |              |
      +------------+                          +--------------+

                                 Figure 4

   The GSK establishment in the protocol consists of two sets of
   2-messages each:

   o  Creation of the group-key at the SKDC:

      *  GSK-Request: A service principal sends a GSK-Request (GSK-REQ)
         message to the SKDC asking for a new group key to be created.
         The service principal provides the desired name (mcastname) of
         the multicast group.  It must accompany the request with an
         authenticator to the SKDC.  After generating the new group-key
         the SKDC retains a copy of the group-key (until it expires) and
         associates it with the multicast group name (mcastname).

      *  GSK-Response: The requesting service principal obtains a copy
         of the new group-key via the GSK-Response (GSK-REP) message
         from the SKDC.  A receipt structure to carries the group-key.
         The receipt is encrypted by the SKDC using the secret key it
         shares with the service principal.

   o  Fetching of a copy of the group-key from the SKDC:

      *  GSK-Fetch: To request a copy of the group-key, a client sends
         the GSK-Fetch (GSK-FET) message to the SKDC with an

Hardjono & Smith          Expires July 7, 2016                 [Page 30]
Internet-Draft           Simplified Key Exchange            January 2016

         authenticator.  The client must indicate the desired multicast
         group (mcastname) in the GSK-FET message.

      *  GSK-Deliver: The SKDC returns a copy of the group-key to the
         client via the GSK-Deliver (GSK-DLVR) message.  A receipt
         structure to carries the group-key.  The receipt is encrypted
         by the SKDC using the secret key it shares with the client.

   The message components as used in the protocol are summarized in
   Figure 5.  Note that all protocol messages are integrity-protected,
   and some are encrypted.

                        The GSK Message Components

      SP (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-DLVR, Receipt* -------------- |
       |                                                   |
       |                                                   |

                                 Figure 5

5.1.  GSK-Request Message (GSK-REQ)

   The GSK-Request message is sent from the service principal to the
   SKDC asking the SKDC to create a new group-key.  The service
   principal authenticates itself to the SKDC by including an
   authenticator in the GSK-REQ message.

   The contents of the GSK-REQ message is as follows:

   o  Protocol version (pvno): This the version of the protocol.

Hardjono & Smith          Expires July 7, 2016                 [Page 31]
Internet-Draft           Simplified Key Exchange            January 2016

   o  Message type (msg-type): The message type for this message is
      "GSK-REQ".

   o  SKDC request body (req-body): The request body contains the
      parameters related to the group-key and multicast group.  See
      Section Section 2.1 for more information on the SKDC request body.
      The SKDC request body in a GSK-REQ message contains the following:

      *  Key Type (kty): This is type of key being requested.  For a
         group shared key the type is "SYMM".

      *  Desired algorithm (etype): This is the algorithm that is
         desired (or supported) by the service principal.

      *  SKDC options - optional (skdc-options).

      *  SKDC's realm (skdcrealm).

      *  SKDC's identity (skdcname).

      *  Multicast group realm - optional (mcastrealm): This is the
         desired realm name associated with the multicast group.

      *  Multicast group identity (mcastname): This is the desired
         identity or name for the multicast group.

      *  Group permissions - optional (grppac): This is the desired set
         of permissions associated with the multicast group.

   o  Authenticator: In the case of a GSK-REQ message, the authenticator
      is encrypted by the service principal (SP) using the secret key it
      shares with the SKDC.  The authenticator in the GSK-REQ contains
      the following:

      *  SP's realm (sprealm).

      *  SP's identity (spname).

      *  SP's current time (sptime).

      *  A new nonce generated by the SP (nonce).

      *  Sequence number - optional (seqnum).

      *  Checksum - optional (cksum).

   o  Extensions - optional (ext): Reserved for future extensions.  This
      field is optional.

Hardjono & Smith          Expires July 7, 2016                 [Page 32]
Internet-Draft           Simplified Key Exchange            January 2016

5.2.  GSK-Response Message (GSK-REP)

   The GSK-Response (GSK-REP) message is sent from the SKDC to the
   service principal in response to the service principal's GSK-Request
   message.  The GSK-Response message contains a receipt structure which
   carries the new group-key for the requesting service principal.

   Note that the GSK-REP message does not contain a miniticket.

   The Receipt in the GSK-Response message is encrypted by the SKDC to
   the requesting service principal using the secret key that is shared
   between the SKDC and the service principal.

   The GSK-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
      "GSK-REP".

   o  SP's realm (sprealm): This the name of the realm, domain or zone
      in which the SP belongs in connection to this request.

   o  SP's identity (spname): This is the identity of the SP requesting
      the group-key in the previous GSK-REQ message.

   o  Receipt (receipt): The receipt carries the group-key and relevant
      parameters.  It is encrypted by the SKDC to the SP using the
      secret key shared between the SKDC and the cSP.  The receipt
      (receipt) contains the following:

      *  Receipts flags - optional (rflags).

      *  Issuing SKDC's realm (skdcrealm).

      *  Issuing SKDC's identity (skdcname).

      *  Multicast group realm - optional (mcastrealm).

      *  Multicast group identity (mcastname).

      *  Group permissions - optional (grppac).

      *  Current time (authtime).

      *  Nonce from the GSK-REQ request (nonce).

      *  Expiration time of key (endtime).

Hardjono & Smith          Expires July 7, 2016                 [Page 33]
Internet-Draft           Simplified Key Exchange            January 2016

      *  Group key (keydata): The key-data structure contains the group-
         key destined for the requesting SP.  See section Section 2.6
         for the key-data structure.

   o  Extensions - optional (ext): Reserved for future extensions.  This
      field is optional.

5.3.  GSK-Fetch Message (GSK-FET)

   The GSK-Fetch message is sent by a client to the SKDC asking for a
   copy of a group-key asociated with a multicast group.  The client
   must identify the desired multicast group name (mcastname) in the
   SKDC-REQ-BODY of the message.  The client authenticates itself to the
   SKDC by including an authenticator.

   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 (req-body): The req-body contains the parameters
      required by the SKDC identify the multicast group.  See
      Section Section 2.1 for more information on the SKDC request body.
      The SKDC request body of a GSK-FET message contains the following:

      *  SKDC options - optional (skdc-options).

      *  SKDC's realm - optional (skdcrealm).

      *  SKDC's identity (skdcname).

      *  Multicast group realm - optional (mcastrealm).

      *  Multicast group identity (spname): This is the name of the
         multicast group whose group-key is being fetched.

      *  KeyID - optional (keyid).

   o  Authenticator (authenticator): The authenticator in the GSK-FET is
      encrypted by the client to the SKDC using the secret key that the
      client shares with the SKDC.  See Section Section 2.4 for more
      information the the authenticator structure.  The authenticator in
      the GSK-FET contains the following:

      *  Client's realm (crealm).

Hardjono & Smith          Expires July 7, 2016                 [Page 34]
Internet-Draft           Simplified Key Exchange            January 2016

      *  Client's identity (cname).

      *  Client's current time (ctime).

      *  A new nonce generated by the client (nonce).

      *  Sequence number - optional (seqnum).

      *  Checksum - optional (cksum).

   o  Extensions - optional (ext): Reserved for future extensions.  This
      field is optional.

5.4.  GSK-Deliver Message (GSK-DLVR)

   The GSK-Deliver (GSK-DLVR) 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 secret key which is
   shared pair-wise between the client and the SKDC.

   The contents of the GSK-Deliver message is as follows:

   o  Protocol version (pvno): This is the version of the protocol.

   o  Message type (msg-type): The message type for this message is
      "GSK-DLVR".

   o  Client's realm (crealm): This the name 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  Receipt (receipt): This is the part of the GSK-Deliver message
      carries the group-key.  It is encrypted by the SKDC to the client
      using the secret key shared between the SKDC and the client.  The
      receipt contains the following:

      *  Receipts flags - optional (rflags).

      *  Issuing SKDC's realm (skdcrealm).

      *  Issuing SKDC's identity (skdcname).

      *  Multicast group realm - optional (mcastrealm).

      *  Multicast group identity (mcastname): This is the name of the
         multicast group whose group-key is being delivered.

Hardjono & Smith          Expires July 7, 2016                 [Page 35]
Internet-Draft           Simplified Key Exchange            January 2016

      *  Group permissions - optional (grppac).

      *  Current time (authtime).

      *  Nonce from the previous GSK-FET message (nonce).

      *  Expiration time of key (endtime).

      *  Group key (keydata): This key-data structure contains the group
         key destined for the requesting client.  See section
         Section 2.6 for the key-data structure.

   o  Extensions - optional (ext): Reserved for future extensions.  This
      field is optional.

6.  Group Shared Key Deletion

   The current protocol supports the proactive removal of a group-key
   associated with a multicast group prior to the expiration of the
   group-key.  Only the creator (owner) of the multicast group can
   request the SKDC to delete a group-key (or the SKDC itself could
   perform a group-key deletion in response to an external authorized
   trigger).

   Due to the nature of a symmetric group-key, the removal of a group-
   key from a multicast group requires the SKDC to issue unicast PSK-
   Delete messages to each known member of the group.  When the SKDC
   sends the PSK-Delete message to a client who is a group member, the
   SKDC must identify the group-key via its KeyID.  Each group member
   must respond to the SKDC with a PSK-Delete-Confirm (PSK-DELC) message
   to confirm the deletion or erasure of the group-key.  See
   Section Section 4.1 for more information on the PSK-DELT and PSK-DELC
   messages.

   The SKDC must wait for all known group members to individually
   confirm (via a PSK-DELC message) their deletion of the group-key.
   Only then should the SKDC return a GSK-Delete-Confirmation (GSK-DELC)
   message to the service principal who requested the group-key
   deletion.

   When the SKDC is in the process of deleting a group-key, it must deny
   further requests for the group-key from new members.

   The group-key deletion process involves four types of messages:

   o  GSK-Delete (GSK-DELT): The SP (as group-owner) sends a GSK-Delete
      request to the SKDC.

Hardjono & Smith          Expires July 7, 2016                 [Page 36]
Internet-Draft           Simplified Key Exchange            January 2016

   o  PSK-Delete (KeyID): For each member of the group (i.e. clients who
      previosuly requested a copy of the group-key), the SKDC sends a
      unicast PSK-Delete (PSK-DELT) message to that client identifying
      the target key to be deleted (by KeyID).  See Section Section 4.1
      for the PSK-DELT message.

   o  PSK-Delete-Confirm (KeyID): Each group member responds after key-
      deletion with a PSK-DELC message to the SKDC.  See
      Section Section 4.2for the PSK-DELC message.

   o  GSK-Delete-Confirmed (GSK-DELC): The SKDC responds with a GSK-
      Delete-Confirmed message to the SP (as group-owner) once all
      copies of the group-key has been deleted at the group-members.

   The message flow for GSK deletion is shown in Figure 6.

                    The GSK Deletion Message Components

    SP (Group Owner)                 SKDC                         Client
     |                                 |                               |
     |                                 |                               |
     |-- (1) GSK-DELT, Kenvelope*  --> |                               |
     |                                 |                               |
     |                                 |-- (2) PSK-DELT, Kenvelope* -->|
     |                                 |                               |
     |                                 |                               |
     |                                 |<-(3)PSK-DELC,Acknowledgement*-|
     |                                 |                               |
     |                                 |                               |
     |<-(4) GSK-DELC, Acknowledgement*-|                               |
     |                                 |                               |
     |                                 |                               |

                                 Figure 6

6.1.  GSK-Delete Message (GSK-DELT)

   The GSK-Delete (GSK-DELT) request message is sent from an SP (group
   owner) to the SKDC asking for the deletion or erasure of the group-
   key of the multicst group identified in the message.

   The GSK-DELT message contains the following.

   o  Protocol version (pvno): This is the version of the protocol.

Hardjono & Smith          Expires July 7, 2016                 [Page 37]
Internet-Draft           Simplified Key Exchange            January 2016

   o  Message type (msg-type): The message type for this message is
      "GSK-DELT".

   o  SP's realm (sprealm): This the name of the realm, domain or group
      in which the SP belongs in connection to this request.

   o  SP's identity (spname): This is the identity of the SP.

   o  Key Envelope (kenvelope): The key envelope is encrypted using the
      SP's secret key that it shares with the SKDC.  The key envelope
      contains the following:

      *  Envelope Flags - optional (envflags).

      *  Multicast group realm - optional (mcastcrealm): This is the
         realm of the multicast group whose group-key is being deleted.

      *  Multicast group identity (skdcname): This is the name of the
         multicast group whose group-key is being deleted.

      *  Current time (authtime).

      *  New nonce generated by the SP (nonce).

      *  Sequence number - optional (seqnum).

      *  Key data (keydata): This key-data structure contains the KeyID
         of the target key to be deleted.  The key-data in a key
         envelope must never contain a cryptographic key.  See section
         Section 2.6 for the key-data structure.

   o  Extensions - optional (ext): Reserved for future extensions.  This
      field is optional.

6.2.  GSK-Delete-Confirm Message (GSK-DELC)

   In response to a GSK-Delete request from a service principal (as
   group owner), the SKDC sends a GSK-Delete-Confirm (GSK-DELC) message
   to the service principal for the successful deletion of not only its
   copy of the group-key, but also the successful deletion of the copies
   of the group-key at each group member (client).

   The GSK-DELC message contains the following:

   o  Protocol version (pvno): This is the version of the protocol.

   o  Message type (msg-type): The message type for this message is
      "GSK-DELC".

Hardjono & Smith          Expires July 7, 2016                 [Page 38]
Internet-Draft           Simplified Key Exchange            January 2016

   o  SP's realm - optional (sprealm).

   o  SP's identity (spname).

   o  Acknowledgement (ack): The acknowledgement is encrypted by the
      SKDC to the SP using the secret key shared only between the SKDC
      and SP.

      *  Multicast group identity (mcastname): This is the name of the
         multicast group whose group-key has been deleted.

      *  Multicast group realm - optional (mcastrealm).

      *  Nonce from the SP's previous GSK-DELT message (nonce).

      *  Current time (authtime).

      *  Sequence number - optional (seqnum): This field is optional.

   o  Extensions - optional (ext): Reserved for future extensions.  This
      field is optional.

7.  Public Key Pair Establishment

   The current protocol supports the distribution of public key pairs
   and certificates.  Since the SKDC is not a certificate authority (in
   the sense of RFC2459), issuing (signing) X509 certificates is out of
   scope for the current specification.  If the SKDC receives from a
   client a request for a new certificate, the SKDC must obtain a
   certificate from a CA server (or CA service) located either in the
   same realm/zone or elsewhere on behalf of the requesting client.  How
   the SKDC discovers CA services is out of scope for the current
   specification.

   In the following we provide additional message types to support a
   client requesting the SKDC to deliver a new public key pair and to
   return the key pair to the client.

   When a client seeks to obtain a new public key pair, the client sends
   a Public Key Pair Request (PKP-REQ) message to the SKDC.  The
   requesting client must include an authenticator that is encrypted
   using the secret key it shares with the SKDC.  The SKDC returns the
   key-pair in the receipt structure to the client (encrypted to the
   client).

   As a further option to the PKP-REQ message, if the client identifies
   a service principal in the SKDC-REQ-BODY of the PKP-REQ message, the
   SKDC would also return a miniticket that contains only the public

Hardjono & Smith          Expires July 7, 2016                 [Page 39]
Internet-Draft           Simplified Key Exchange            January 2016

   half of the key-pair.  The miniticket would be encrypted by the SKDC
   to the named service principal, using the secret key that the SKDC
   shares with the service principal.  Note that this is a departure
   from the PSK-Request semantics (for symmetric key requests) because
   the miniticket contains a public key (instead of a symmetric key).

   The client (or the SKDC) then sends the miniticket to the service
   principal who can decrypt the miniticket using the secret key it
   shares with the SKDC.

   By encrypting the miniticket to the service principal, the SKDC is
   effectively attesting to the binding between the public key pair and
   the client's identity (without the use of digital certificates).  The
   service principal trusts SKDC to provide this pseudo-attestation
   regarding the client as the owner of the new public key pair.

   Note that in this approach the security of the public key pair is
   only as a secure as the symmetric key algorithm used to encrypt the
   receipt and the miniticket.

   If additionally the client seeks to obtain a digital certificate for
   the new public key, then the client must indicate this option in the
   SKDC-Options field (in the SKDC-REQ-BODY) of the PKP-Request message.
   There are several options available related to digital certificates
   and CA certificates (trust anchors):

      No certificate: This is the default setting for the PKP-Request
      message.

      Certificate: This means the client additionally requests the
      return of a new X509 certificate corresponding to the new public
      key.

      Include certificate chain: This option is meaningful only of the
      client requests a new X509 certificate.  When set, this option
      means that the client also requests the certificate chain
      consisting of copies of all signing certificates to the top of the
      certificate hierarchy.

7.1.  Public Key Pair Request (PKP-REQ)

   A client uses the PKP-Request message (PKP-REQ) to request a new
   public key pair from the SKDC.  The client must include an
   authenticator when sending this message to the SKDC.  The PKP-REQ
   message contains the following:

   o  Protocol version (pvno): This the version of the protocol.

Hardjono & Smith          Expires July 7, 2016                 [Page 40]
Internet-Draft           Simplified Key Exchange            January 2016

   o  Message type (msg-type): The message type for this message is
      "PKP-REQ".

   o  SKDC request body (req-body): The request body contains the
      parameters required by the SKDC in the context of this request.
      the See Section Section 2.1 for more information on the SKDC
      request body.  The SKDC request body of a PKP-REQ message contains
      the following:

      *  Key Type (kty): This is type of key being requested by the
         client from the SKDC.

      *  Desired algorithm (etype): This is the algorithm that is
         desired (or supported) by the client.

      *  SKDC options - optional (skdc-options): The client sets the
         "certificate request" option (and possibly the "certificate
         chain" option) in this field if it requests a digital
         certificate (and corresponding chain) to be returned together
         with the public key pair.

      *  SKDC's realm (skdcrealm).

      *  SKDC's identity (skdcname).

      *  Service principal's realm - optional (sprealm):

      *  Service principal's identity -- optional (spname):

         +  spname is present: If the spname is present, this means that
            the client wishes for the SKDC to prepare copy of the new
            public key only for the named service principal via the
            miniticket structure.

         +  spname is absent: If the spname is absent the SKDC delivers
            the public key pair only to the client via the receipt
            structure.

      *  Client permissions - optional (cpac).

   o  Authenticator (authenticator): This is the authenticator encrypted
      by the client to the SKDC using the secret key that the client
      shares with the SKDC.  See Section Section 2.4 for more
      information on the authenticator structure.

   o  Extensions - optional (ext): Reserved for future extensions.  This
      field is optional.

Hardjono & Smith          Expires July 7, 2016                 [Page 41]
Internet-Draft           Simplified Key Exchange            January 2016

7.2.  Public Key Pair Response (PKP-REP)

   In response to the PKP-Request message (PKP-REQ) from a client
   entity, the SKDC returns a copy of the new public key pair to the
   client in a receipt structure, encrypted using the secret key shared
   between the client and SKDC.  This ensures that only the client is in
   possession of the new public key pair (notably the private key).

   If the SKDC-REQ-BODY of the client's previous PKP-request message
   contains the identity of a service principal (spname), the SKDC must
   also create a miniticket containing a copy of the public key only.
   The miniticket is encrypted to the service principal.

   The PKP-REP 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
      "PKP-REP".

   o  Client's realm (crealm): This the name of the realm, domain or
      zone in which the client belongs in connection to this request.

   o  Client's identity (cname): This is the identity of the client.

   o  Miniticket - optional (mticket): If the client identified a
      service principal in the previous PKP-REQ message (in its SKDC-
      REG-BODY), then a miniticket is included by the SKDC in this PKP-
      REP message.  If present, the miniticket contains the following:

      *  Issuing SKDC's realm (skdcrealm).

      *  Issuing SKDC's identity (skdcname).

      *  Service principal's realm - optional (sprealm).

      *  Service Principal's identity (spname).

      *  Encrypted miniticket part (enc-part): This is the part of the
         PKP-REP message that is encrypted by the SKDC to the service
         principal, using the secret key that the SKDC shares pair-wise
         with the service principal.  It contains the following:

         +  Ticket flags - optional (tflags).

         +  Client's realm (crealm): This the name of the realm, domain
            or zone in which the client belongs in connection to this
            request.

Hardjono & Smith          Expires July 7, 2016                 [Page 42]
Internet-Draft           Simplified Key Exchange            January 2016

         +  Client's identity (cname).

         +  Client permissions - optional (cpac).

         +  Time of authentication (authtime).

         +  Expiration time of this key - optional (endtime): This field
            is present if the SKDC returns a public key pair only.  If a
            certificate accompanies the public key pair, then this field
            is absent.

         +  Service principal permissions - optional (sppac).

         +  Transited realms - optional (transited).

         +  Key data (keydata): In a PKP-REP message, the key-data
            structure in the miniticket contains only the public key of
            the client.  The private key must not be included.  If the
            client had also requested a new certificate, the certificate
            is included here.  See section Section 2.6 for the key-data
            structure.

   o  Receipt (receipt): This is the part of the PKP-REP message that is
      encrypted by the SKDC to the client, using the secret key that the
      SKDC shares pair-wise with the client.  It contains the following:

      *  Receipts flags - optional (tflags).

      *  Issuing SKDC's realm (skdcrealm).

      *  Issuing SKDC's identity (skdcname).

      *  Service principal's realm - optional (sprealm).

      *  Service Principal's identity (spname).

      *  Service Principal's SKDC - optional (spskdc).

      *  Client permissions - optional (cpac).

      *  Time of authentication (authtime): This is the time of the
         creation of this receipt.

      *  Nonce from the Client's previous PSK-REQ request message
         (nonce).

      *  Expiration time of this key (endtime).

Hardjono & Smith          Expires July 7, 2016                 [Page 43]
Internet-Draft           Simplified Key Exchange            January 2016

      *  Key data (keydata): In a PKP-REP message, the key-data
         structure in the receipt contains both the public key and
         private key belonging to the requesting client.  If the client
         had also requested a new certificate, the certificate is
         included here.  See section Section 2.6 for the key-data
         structure.

   o  Extensions - optional (ext): Reserved for future extensions.  This
      field is optional.

8.  JSON Message Format

   TBD.

9.  Encryption and Checksums

   TBD.

10.  Security Considerations

   TBD.

11.  Privacy Considerations

   TBD.

12.  IANA Considerations

   TBD.

13.  Acknowledgments

   We thank Jesse Walker for design inputs and initial review.

14.  References

14.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,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

Hardjono & Smith          Expires July 7, 2016                 [Page 44]
Internet-Draft           Simplified Key Exchange            January 2016

   [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>.

14.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>.

   [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>.

Hardjono & Smith          Expires July 7, 2016                 [Page 45]
Internet-Draft           Simplified Key Exchange            January 2016

   [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>.

   [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 July 7, 2016                 [Page 46]