Internet DRAFT - draft-abiggs-saag-primitives-for-conf-group-comms

draft-abiggs-saag-primitives-for-conf-group-comms







Network Working Group                                           A. Biggs
Internet-Draft                                                 S. Cooley
Intended status: Standards Track                           Cisco Systems
Expires: May 6, 2016                                   November 03, 2015


            Primitives for Confidential Group Communications
          draft-abiggs-saag-primitives-for-conf-group-comms-01

Abstract

   This specification defines generalized primitives for use in
   establishing end-to-end confidentiality in multiparty communications.
   These primitives address three essential elements of group privacy:
   authentication, group membership, and secure key exchange.  The
   purpose is to define these primitives in such a way as they may be
   leveraged as common constructs within new and existing secure group
   communications protocols, and in support of both centralized and
   decentralized architectures.

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 May 6, 2016.

Copyright Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must



Biggs & Cooley             Expires May 6, 2016                  [Page 1]

Internet-Draft       primitives-for-conf-group-comms       November 2015


   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Notational Conventions  . . . . . . . . . . . . . . . . .   5
   2.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     2.1.  Authentication by Entity Public Key . . . . . . . . . . .   5
     2.2.  Authorization by Group Membership Block Chain . . . . . .   5
     2.3.  Key Distribution by Group Keys  . . . . . . . . . . . . .   7
   3.  Group Models  . . . . . . . . . . . . . . . . . . . . . . . .   8
     3.1.  Decentralized Groups  . . . . . . . . . . . . . . . . . .   8
     3.2.  Centralized Groups  . . . . . . . . . . . . . . . . . . .   9
   4.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .  10
     4.1.  Decentralized Group File Sharing  . . . . . . . . . . . .  10
     4.2.  Centralized Group Instant Messaging . . . . . . . . . . .  11
   5.  Primitive Specifications  . . . . . . . . . . . . . . . . . .  12
     5.1.  Entity  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     5.2.  Group Membership Block Chain  . . . . . . . . . . . . . .  12
     5.3.  Group Key . . . . . . . . . . . . . . . . . . . . . . . .  13
   6.  Mandatory-to-Implement  . . . . . . . . . . . . . . . . . . .  14
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
   8.  Appendix A. Acknowledgments . . . . . . . . . . . . . . . . .  14
   9.  Appendix B. Document History  . . . . . . . . . . . . . . . .  15
   10. Normative References  . . . . . . . . . . . . . . . . . . . .  15
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16

1.  Introduction

   This specification defines generalized primitives for use in
   establishing end-to-end confidentiality in multiparty communications.
   These primitives address three essential elements of group privacy:

   o  Authentication

   o  Group Membership

   o  Secure Key Exchange

   Authentication is based on the identification of interoperating
   entities by acct URI [RFC7565] and proof of possession of the private
   counterpart of a public key discoverable through a public key
   discovery service [I-D.miller-saag-key-discovery].





Biggs & Cooley             Expires May 6, 2016                  [Page 2]

Internet-Draft       primitives-for-conf-group-comms       November 2015


   Authorization is based on the group membership classification of
   authenticated entities, as represented in the form of a Group
   Membership Block Chain (GMBC) structure defined by this
   specification.  Critical properties of the GMBC are tamper-
   resistance, efficient mutability, broad deployability, and integrity
   in the context of distributed handling.

   The secure exchange of keys is based on existing key wrapping
   standards which allow for the sharing of encrypted key material with
   multiple explicitly identified recipients.  This strategy builds on
   the GMBC based authorization model by taking advantage of reliable
   group membership classification when addressing wrapped keys to other
   members.

   A goal of this specification is to define these primitives in such a
   way as they may be suitable for both centralized and distributed
   management.  It is also a goal to describe these primitives in terms
   of accepted standards for cryptographic processing and
   infrastructure.

   A non-goal of this specification is to define the means by which
   these primitives are exchanged among interoperating entities.  The
   intent is only to define these as building blocks for extending group
   confidentiality to both new and existing communications and content
   sharing protocols.  With that in mind, however, this specification
   does advance the notion of recognizing two general classes of
   deployment for these primitives: "centralized" and "decentralized".

   An additional non-goal of this specification is the establishment of
   mechanisms for the authentication of sender identity in confidential
   group communications.  Care is taken to ensure that only
   authenticated members of a group may decipher secured communications,
   however the means by which group members may reliably identify
   originators of encrypted communications is out of scope for this
   specification.

1.1.  Terminology

   curator

      An entity optionally identified in the genesis block of a GMBC as
      a permanent member of a group that performs the function of
      accepting and distributing GMBC updates and GKs among group
      members.

   entity





Biggs & Cooley             Expires May 6, 2016                  [Page 3]

Internet-Draft       primitives-for-conf-group-comms       November 2015


      An entity is a user or automated agent that is uniquely
      identifiable by an acct URI and for which there exists a key
      discovery service [I-D.miller-saag-key-discovery] through which
      public keys may be obtained for that URI.

   genesis block

      The first block in a group membership block chain.

   group

      A group is a set of entities whose membership wish to engage in
      secure and authenticated multiparty communications over some group
      communications resource.

      member

   A member is an entity that is classified as such with respect to a
   particular group membership block chain.  A non-member is any entity
   not classified as a member.

   group communications resource

      A group communications resource is any uniquely identifiable
      streamed or discrete data path that represents an exchange of
      personal communications between two or more entities.

   group key (GK)

      A group key is a signed and encrypted object containing symmetric
      key material and associated metadata secured by the public key(s)
      of group members.

   group membership block chain (GMBC)

      A group membership block chain is a primitive defined by this
      specification for the purpose of providing an effective means for
      defining, updating, sharing, and verifying the membership of a
      group.

   This document uses the terminology from [RFC7515], [RFC7516],
   [RFC7517], and [RFC7518] when discussing JOSE technologies.  Most
   security-related terms in this document are to be understood in the
   sense defined in [RFC4949].







Biggs & Cooley             Expires May 6, 2016                  [Page 4]

Internet-Draft       primitives-for-conf-group-comms       November 2015


1.2.  Notational Conventions

   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
   and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119
   [RFC2119].

2.  Overview

   This section provides a general overview of three basic constructs
   for enabling authentication, authorization, and secure key exchange
   in confidential group communications.

2.1.  Authentication by Entity Public Key

   In the context of this specification entity authentication is defined
   as the demonstration of possession of the private component of an
   asymmetric key pair.  Specifically, an entity uniquely identified by
   an acct URI [RFC7565] may be authenticated by demonstrating
   possession of the private counterpart of one or more public keys as
   may be discovered using that acct URI and the mechanisms described in
   [I-D.miller-saag-key-discovery].

2.2.  Authorization by Group Membership Block Chain

   In the context of this specification authorization is defined as the
   classification of any given entity as either a "member" or "non-
   member" with respect to a group.  A member of the group is by
   definition authorized to receive keying material used to encrypt
   group communications, and likewise a non-member is not.  A member is
   also entitled to alter the membership of the group.  The means by
   which group membership classification established, updated, and
   validated, is through operations on a Group Membership Block Chain
   (GMBC).

   A GMBC is an ordered list of data blocks representing a tamper-
   resistant chronological account of group membership updates.  The
   first block in the GMBC defines the initial set of group members and
   each subsequent block represents an addition/removal of one or more
   other entities to/from the group.  Any entity can create a GMBC, but
   only a member can update an existing GMBC by appending new blocks to
   it.

   Each block consists of a JSON object signed with the private key of
   the entity that created that block within the chain.  That JSON
   object includes attributes representing the following:

   o  the acct URI of the entity that created the block,



Biggs & Cooley             Expires May 6, 2016                  [Page 5]

Internet-Draft       primitives-for-conf-group-comms       November 2015


   o  an array of group membership update operations,

   o  a timestamp indicating the date and time of the block's creation,
      and

   o  a hash of the preceding block in the membership chain (if any).

   A group membership update operation is a JSON object with two fields:

   o  a tag indicating the operation type ("add" or "remove"), and

   o  the acct URI of the entity being either added to or removed from
      the group.

   In addition to the above attributes the first block of the chain, or
   genesis block, also includes the following attributes:

   o  a URI that uniquely identifies the GMBC,

   o  the acct URI of the group's curator (optional), and

   o  a nonce.

   The genesis block must also include at least one "add" operation,
   though it need not necessarily represent the addition of the entity
   that created it (i.e. entities may create new groups within which
   they are not themselves members).

   The membership of the group is implicit and may be determined by
   processing the GMBC in chronological order.  At any given point in
   time the membership of the group is defined as that set of entities
   for which there exists, for each entity, a previously introduced
   block containing an "add" operation, and for which there does not
   exist a later but also previously introduced block containing a
   "remove" operation.

   To protect against unauthorized tampering the GMBC is validated by
   verifying the signatures of each block, verifying that each non-
   genesis block contains a valid hash of the preceding block, and
   verifying that each block was created and signed by an entity that is
   among the group's membership as determined by the segment of chain
   preceding that block.  Block signature verification is made possible
   through the key discovery mechanisms defined in
   [I-D.miller-saag-key-discovery] and the knowledge of each member's
   acct URI.






Biggs & Cooley             Expires May 6, 2016                  [Page 6]

Internet-Draft       primitives-for-conf-group-comms       November 2015


2.3.  Key Distribution by Group Keys

   A Group Key (GK) is signed object containing encrypted symmetric key
   material with associated metadata.  A GK exists for the purpose of
   sharing the contained symmetric key with other members of the group.
   The exclusivity of access to the key material is achieved by
   encrypting the key material in such a way that it may be decrypted
   with the private entity key(s) of any one of the other group members.
   The creator signs the GK such that the authenticity of the associated
   metadata may be verified by its recipients.

   The payload of the GK is a JSON object includes attributes
   representing the following:

   o  a URI that uniquely identifies the GK,

   o  the acct URI of the creator of the GK,

   o  a hash of the GMBC tail block at the time this key was created,

   o  an encrypted JWK [RFC7517] that contains the symmetric key
      material, and

   o  a timestamp indicating the date and time the GK was created.

   The JWK attribute value is encrypted in a JWE [RFC7516] JSON
   serialization with one or more recipients.  In decentralized groups
   the resulting JWE JSON serialization must include each other member
   of the group as determined by the current and validated GMBC.  In
   centralized groups the resulting JWE JSON serialization may include
   as a recipient just the curator (e.g. when an entity shares a new GK)
   or just one member (e.g. when the curator shares a GK with a member
   that has requested it).  The full JSON payload of the GK is signed as
   a JWS [RFC7515] using the creator's private entity key.

   GKs may be created by members and non-members alike.  A non-member
   may generate a GK as described above and use it to encrypt its own
   communications to the group.  This can be a useful property as it
   provides for a confidential "write only" capability to the group
   communications resource.

   A group may have any number of GKs associated with it.  Where
   practical, it is recommended that each member of a group use its own
   GK for purposes of encryption and share this GK with the remainder of
   the group for purposes of decryption.  A member must not re-use the
   keying material of a GK created by another entity to encrypt it's own
   communications unless it has verified that GK is signed by a current
   member of the group as defined by the GMBC.



Biggs & Cooley             Expires May 6, 2016                  [Page 7]

Internet-Draft       primitives-for-conf-group-comms       November 2015


   Upon receiving and validating an update to the GMBC, each entity must
   discard their encryption GK and produce a new encryption GK for which
   the recipients reflect the updated GMBC membership.  This is
   necessary to ensure that new members are able to decrypt subsequent
   communications but not prior communications.  Perhaps more
   importantly, this also ensures that former members are not able to
   decrypt subsequent group communications.  In centralized groups the
   curator may implement a policy where it permits new group members to
   request previously created GKs.

   It is recommended that all entities that share encrypted content over
   the group communications resource rotate their GKs regularly so as to
   mitigate against vulnerabilities that are exacerbated by the extended
   use of individual keys.

3.  Group Models

   While this specification provides definition for constructs that
   enable confidential group communications, the means by which these
   objects may be exchanged among group members is intentionally omitted
   as this is regarded as out of scope for this specification.  It
   remains worthwhile, however, to discuss two general classes of
   confidential group communications and how the primitives defined by
   this specification may be leveraged in each.  These classes may be
   described as "centralized groups" and "decentralized groups".

3.1.  Decentralized Groups

   A decentralized group is characterized by the absence of a curator
   attribute in the GMBC genesis block and therefore the absence of a
   permanent member within the group through which GMBC and GK objects
   may be exchanged.  In a decentralized group these objects may instead
   be exchanged either in-band through the group communications resource
   itself, or through in-band references to external repositories from
   whence GMBC and GK objects may be retrieved.

   Both the GMBC and GK objects are designed to be hardened against
   tampering and protect sensitive data such that they may be reasonably
   exchanged through either public or private transports and stores.
   Note, however, that regardless of the employed mechanisms of exchange
   a protocol utilizing a decentralized group pattern must provide a
   means by which any GMBC update or new GK produced by a member may be
   delivered to each other group member in a timely fashion.

   In a decentralized group the fact that there is no single entity
   providing an authoritative and definitively current version of the
   GMBC means that members can make concurrent updates to their own
   copies of the GMBC and thereby create conflicts in their collective



Biggs & Cooley             Expires May 6, 2016                  [Page 8]

Internet-Draft       primitives-for-conf-group-comms       November 2015


   understanding of group membership history.  Such conflicts are
   manifest as a divergence where each GMBC has a different block, let
   us call them B and B', appended to some block A that they have in
   common.  A member encountering this condition must select either one
   of the two GMBCs in its entirety and discard the other.  This
   selection is performed by observing the hash values of blocks B and
   B' and selecting the GMBC to which the block with the numerically
   smallest hash belongs.  If, as a result of this selection, an entity
   finds that a block that it had itself previously introduced to the
   discarded GMBC is not represented in the retained GMBC, then that
   entity is responsible for appending a new block to the retained GMBC
   to represent that membership update (and, of course, share that
   update to other members).

3.2.  Centralized Groups

   A centralized group is characterized by the presence of a curator
   attribute in the GMBC genesis block.  The curator attribute
   identifies an entity by its acct URI and declares that entity as a
   permanent member of the group which will serve as a facilitator for
   the exchange of GMBC and GK objects among all group members.  In
   particular, a curator will respond to the following types of requests
   from other entities.  Note that the means by which these operations
   are carried out between members and the curator is out of scope for
   this document.

   GMBC Post

      When adding or removing members from a group, a member will submit
      a new GMBC block to the curator representing that change.  The
      curator will verify that the block is signed by a member of the
      group and that the hash attribute of the block represents the hash
      of the current tail end of the chain.  If both checks succeed then
      the curator will make the new block a permanent part of the GMBC
      and indicate to the requesting entity that the update was
      successful.

   GMBC Get

      Entities may request all or part of the current GMBC from the
      curator by providing to the curator a hash of the last GMBC block
      of which they are aware (or 0x0 if they are requesting the entire
      chain).

   GMBC Notify (optional)

      In some deployments it may be desirable for a curator to
      immediately multicast GMBC updates to all current members of the



Biggs & Cooley             Expires May 6, 2016                  [Page 9]

Internet-Draft       primitives-for-conf-group-comms       November 2015


      group.  This may be based on either an explicit or automatic/
      implicit subscription model.

   GK Post

      Entities may inform the curator of new GKs which they have
      generated for the purpose of encrypting data they emit to the
      group communications resource.  The curator will store a received
      GKs such that it may subsequently service requests for that GK
      from other members that wish to decrypt these communications.

   GK Get

      Members may request from the curator GKs which have been generated
      by other entities.  In doing so, an entity must indicate the URI
      of the requested GK and the curator must verify that the
      requesting entity was a member of the group at the time the GK was
      created by processing the GMBC from the genesis block up to and
      including the block whose hash is indicated in the metadata of the
      requested GK.  A successful confirmation of the requesting entity
      as a member of the group at that point in time will result in the
      curator generating a new GK which is in every way identical to the
      requested GK except that the key material is re-encrypted using
      the public key of the requesting entity and the GK itself is
      signed using the curator's own public entity key.

4.  Use Cases

   The following are non-normative examples of how the primitives
   described in this specification may be employed to facilitate
   confidential group communications.

4.1.  Decentralized Group File Sharing

   This use case describes an application that utilizes some third party
   file sharing service to store confidential information and employs
   this specification as part of a scheme to secure that confidentiality
   among the members of self defined group.

   1.  User A generates a symmetric key to be used for file encryption.

   2.  User A encrypts a file using the symmetric key and posts it to
       the file sharing service.

   3.  User A generates a new GMBC by creating a genesis block.  In that
       block user A includes a reference to the URL of the encrypted
       file on the file sharing service.  User A also adds to the




Biggs & Cooley             Expires May 6, 2016                 [Page 10]

Internet-Draft       primitives-for-conf-group-comms       November 2015


       genesis block three group membership "add" operations: one for
       itself, one for user B, and one for user C.

   4.  User A creates a GK that includes a hash of the GMBC genesis
       block, and encrypts the key material portion of the GK using a
       multi-recipient JWE JSON serialization that indicates users B and
       C as recipients.

   5.  User A posts the GMBC and GK as text files to the same file
       sharing service, and sends the URLs of the encrypted content
       file, the GMBC, and GK to users B and C.

   6.  User B recognizes user A's acct URI as the identity of a trusted
       correspondent, retrieves the GMBC and GK from the file service,
       and verifies the signatures on the GMBC genesis block and GK by
       discovering and retrieving user A's public entity key through
       [I-D.miller-saag-key-discovery].

   7.  User B uses its own private entity key to decrypt the key
       material contained within the GK, downloads the file indicated by
       the resource URL in the GMBC genesis block, and decrypts the
       contents of that file.

   8.  User C repeats the procedure outlined for user B in steps 6 and
       7.

4.2.  Centralized Group Instant Messaging

   This use case describes an application that utilizes some instant
   messaging service to exchange confidential messages among a group of
   users and employs this specification as part of a scheme to secure
   that confidentiality among the members as a centralized group.

   1.  User A establishes a messaging thread on the messaging service
       that includes users B and C.  We presume it can be associated
       with some unique URI for purposes of identification.

   2.  User A generates a new GMBC by creating a genesis block.  In that
       block user A includes a reference to the URI of the messaging
       thread created in step 2, and three group membership "add"
       operations: one for itself, one for user B, and one for user C.
       User A also identifies itself as the curator of the group by
       provisioning the genesis block with its own acct URI in the
       curator field.

   3.  User A creates a GK that includes a hash of the GMBC genesis
       block.




Biggs & Cooley             Expires May 6, 2016                 [Page 11]

Internet-Draft       primitives-for-conf-group-comms       November 2015


   4.  User A encrypts a message using the keying material of the GK and
       sends it over the instant messaging service.  As metadata within
       that message it also includes the URI of the GK it used to
       encrypt the message and the current GMBC.

   5.  User B recognizes user A's acct URI as the identity of a trusted
       correspondent and validates the GMBC as originating from user A
       by discovering and retrieving user A's public entity key through
       [I-D.miller-saag-key-discovery].

   6.  User B observes that the GMBC indicates user A as the curator for
       this group and sends a request (perhaps as an in-band extension
       to the instant messaging protocol) to user A for the GK used to
       encrypt the message sent in step 3.

   7.  User A receives the GK request from user B, validates that user B
       was a member of the GMBC at the time the requested GK was
       created, and returns a copy of the GK created in step 3 with the
       keying material portion encrypted using the public entity key of
       user B.

   8.  User C repeats the procedure outlined for user B in steps 5
       through 7.

5.  Primitive Specifications

   This section provides normative definition for the objects introduced
   in this document.

5.1.  Entity

   An entity is identified by an acct URI [RFC7565], its associated
   public entity key is discovered through key discovery as described in
   [I-D.miller-saag-key-discovery], and that key is represented as a JWK
   [RFC7517] also as defined in that specification.

5.2.  Group Membership Block Chain

   A GMBC is composed of JSON encoded blocks, each signed with the
   private key of the entity that introduced that block to the chain.
   Signing is performed in conformance with the JWS [RFC7515]
   specification and the block is communicated between entities in the
   form of a JWS compact serialization.

   The basic payload of a GMBC block is defined as follows, using JSON
   content rules notation [I-D.newton-json-content-rules].





Biggs & Cooley             Expires May 6, 2016                 [Page 12]

Internet-Draft       primitives-for-conf-group-comms       November 2015


   operation "Operation" {
       "entity": uri,                ; acct URI of entity added/removed
       "optype": < "add" "remove" >  ; tag indicating type of operation
   }

   gmbc-block {
       "creator": uri,               ; acct URI of creator of the block
       "created": date-time,         ; date and time of block creation
       "operations" [ *: operation ] ; membership update operations
   }

   A GMBC genesis block is specified as a basic block with three
   additional payload fields, as defined below.

   gmbc-genesis-block {
       "uri": uri,                   ; URI to identify the GMBC itself
       "curator": ?uri,              ; (optional) acct URI of curator
       "nonce": integer,             ; a random one-time numeric value
       gmbc-block                    ; standard block attributes
   }

   root gmbc-genesis-block

   A GMBC non-genesis block is specified as a basic block with one
   additional payload field, as defined below.

   gmbc-appended-block {
       "antecedent": string,         ; SHA-256 hash of preceding block
       gmbc-block                    ; standard block attributes
   }

   root gmbc-appended-block

5.3.  Group Key

   A GK is composed of JSON encoded blocks, each signed with the private
   key of the entity that created it (or the curator when servicing GK
   requests in centralized groups).  Signing is performed in conformance
   with the JWS specification and the block is communicated between
   entities in the form of a JWS compact serialization.

   The payload of a GK is defined as follows.









Biggs & Cooley             Expires May 6, 2016                 [Page 13]

Internet-Draft       primitives-for-conf-group-comms       November 2015


   group-key {
       "uri": uri,                   ; URI to identify the GK itself
       "creator": uri,               ; acct URI of creator of the GK
       "created": date-time,         ; the date and time of GK creation
       "block": string,              ; SHA-256 hash of GMBC block
       "key": wrapped-key            ; encrypted symmetric key material
   }

   root group-key

   The "key" attribute's value is a JWE JSON serialization as defined in
   [RFC7516] with one or more recipients (either one recipient for each
   member of the group at the time the key was created, or the group
   curator).  The payload of that JWE is a JWK [RFC7517] representing a
   symmetric key.

6.  Mandatory-to-Implement

   Implementations MUST support the following JWK key types from
   [I-D.ietf-jose-json-web-algorithms]:

   o  "RSA" for entity static public/private key

   o  "oct" for all symmetric keys

   Implementations MUST support "PS256" (RSASSA-PSS using SHA-256 and
   MGF1 with SHA-256) from [I-D.ietf-jose-json-web-algorithms] for
   signatures using entity static public/private key.

   Implementations MUST support "RSA-OAEP" (RSAES OAEP using default
   parameters) from [I-D.ietf-jose-json-web-algorithms] for key
   encryption using entity static public/private keys.

   Implementations MUST support "A256GCM" (AES GCM using 256 bit key)
   from [I-D.ietf-jose-json-web-algorithms] for content encryption.

7.  Security Considerations

   Security considerations are discussed throughout this document.
   Additional considerations may be added here as needed.

8.  Appendix A.  Acknowledgments

   This specification is the work of several contributors.  In
   particular, the following individuals contributed ideas, feedback,
   and wording that influenced this specification:

   Matt Miller



Biggs & Cooley             Expires May 6, 2016                 [Page 14]

Internet-Draft       primitives-for-conf-group-comms       November 2015


9.  Appendix B.  Document History

   -00

   o  Initial draft.

   -01

   o  Updates to accommodate flows identified in dependent drafts.

10.  Normative References

   [I-D.ietf-jose-json-web-algorithms]
              Jones, M., "JSON Web Algorithms (JWA)", draft-ietf-jose-
              json-web-algorithms-33 (work in progress), September 2014.

   [I-D.miller-saag-key-discovery]
              Miller, M. and S. Nandakumar, "Key Discovery Service",
              draft-miller-saag-key-discovery-00 (work in progress),
              July 2015.

   [I-D.newton-json-content-rules]
              Newton, A., "A Language for Rules Describing JSON
              Content", draft-newton-json-content-rules-02 (work in
              progress), August 2014.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4949]  Shirey, R., "Internet Security Glossary, Version 2", RFC
              4949, August 2007.

   [RFC7515]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web
              Signature (JWS)", RFC 7515, May 2015.

   [RFC7516]  Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
              RFC 7516, May 2015.

   [RFC7517]  Jones, M., "JSON Web Key (JWK)", RFC 7517, May 2015.

   [RFC7518]  Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, May
              2015.

   [RFC7565]  Saint-Andre, P., "The 'acct' URI Scheme", RFC 7565, May
              2015.






Biggs & Cooley             Expires May 6, 2016                 [Page 15]

Internet-Draft       primitives-for-conf-group-comms       November 2015


Authors' Addresses

   Andrew Biggs
   Cisco Systems

   Email: adb@cisco.com


   Shaun Cooley
   Cisco Systems

   Email: shcooley@cisco.com







































Biggs & Cooley             Expires May 6, 2016                 [Page 16]