[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 07

Network Working Group                                          J. Herzog
Internet-Draft                                                 R. Khazan
Intended status: Informational                    MIT Lincoln Laboratory
Expires: September 23, 2010                               March 22, 2010


             A set-key attribute for symmetric-key packages
                         draft-herzog-setkey-00

Abstract

   A set-key is a symmetric key (or set of keys) associated with an
   immutable set of participants.  This document defines a set-key
   attribute for use in the CMS-based symmetric-key package structure
   defined in in RFC XXXX. {{{ RFC Editor, please replace XXXX with the
   number assigned to draft-ietf-keyprov-symmetrickeyformat when it is
   published. }}}

Disclaimer

   This work is sponsored by the United States Air Force under Air Force
   Contract FA8721-05-C-0002.  Opinions, interpretations, conclusions
   and recommendations are those of the authors and are not necessarily
   endorsed by the United States Government.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on September 23, 2010.




Herzog & Khazan        Expires September 23, 2010               [Page 1]


Internet-Draft             A set-key attribute                March 2010


Copyright Notice

   Copyright (c) 2010 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
   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 BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Set-keys . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.2.  Symmetric key packages . . . . . . . . . . . . . . . . . .  3
     1.3.  Intended Usage . . . . . . . . . . . . . . . . . . . . . .  5
     1.4.  Requirements Terminology . . . . . . . . . . . . . . . . .  5
   2.  The set-key attribute  . . . . . . . . . . . . . . . . . . . .  5
   3.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
   4.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     4.1.  Normative References . . . . . . . . . . . . . . . . . . .  8
     4.2.  Informative References . . . . . . . . . . . . . . . . . .  9
   Appendix A.  ASN.1 Module  . . . . . . . . . . . . . . . . . . . .  9
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10





















Herzog & Khazan        Expires September 23, 2010               [Page 2]


Internet-Draft             A set-key attribute                March 2010


1.  Introduction

   This document defines a new set-key attribute for the symmetric-key
   package structure defined in [Housley-symmkey].

1.1.  Set-keys

   A 'set-key' is a symmetric key associated with (and to be limited to)
   a specific set of participants.  Such a key can be used in many ways,
   including:

   o  To secure broadcast or multicasts of e.g., pay-per-view movies,

   o  To secure group-communication such as chat rooms, or

   o  To secure data-at-rest which belongs to a group (such as on an
      encrypted file-system or on a server).

   The only requirement of a set-key is that it be associated with a
   specific and unchanging set of participants.  That is, we make a
   distinction between sets and groups.  Sets are immutable structures:
   a set S of participants is a mathematical entity and does not change.
   A group, on the other hand, is a mutable structure that might have a
   certain name or set of names; may be under the control of a given
   administration; and may be mapped to a sequence of sets over time
   according to the needs of some particular application.  This document
   considers only sets, and therefore will not consider issues such as
   group-administration, adding or removing members, revoking keys, and
   so on.  Set-keys can be used to build group-keying protocols, but
   such issues are outside the scope of this document.

   We note that the participant-set of a set-key can be partitioned into
   two sub-sets: the active participants and the passive participants.
   In some set-key applications, such as group-chat, all participants
   may be active: both sending and receiving.  In other applications,
   such as multicast of pay-per-view movies, most participants are
   passive: only receiving.  Becuase it may be important, in some
   applications, to know which partipants are active and which are
   passive, we will allow these two sub-sets to be explicitly
   distinguished from each other.

1.2.  Symmetric key packages

   The Cryptographic Message Syntax (CMS) [RFC5652] is a standard
   notation and representation for cryptographic messages.  CMS is based
   on ASN.1 [X.680], [X.681], [X.682], [X.683] and uses that notation to
   define a number of structures relevant to cryptography such as
   certificates, encrypted or signed messages, and so on.



Herzog & Khazan        Expires September 23, 2010               [Page 3]


Internet-Draft             A set-key attribute                March 2010


   A current Internet Draft [Housley-symmkey] uses CMS to define a
   structure for symmetric key packages: collections of symmetric keys
   which share common properties and are intended for the same
   participants.  The syntax for this structure follows:


   SymmetricKeyPackage ::= SEQUENCE {
     version           KeyPkgVersion DEFAULT v1,
     sKeyPkgAttrs  [0] SEQUENCE SIZE (1..MAX) OF Attribute
                                    {{ SKeyPkgAttributes }} OPTIONAL,
     sKeys             SymmetricKeys,
     ... }


   SymmetricKeys ::= SEQUENCE SIZE (1..MAX) OF OneSymmetricKey

   OneSymmetricKey ::= SEQUENCE {
     sKeyAttrs  SEQUENCE SIZE (1..MAX) OF Attribute
                                    {{ SKeyAttributes }}  OPTIONAL,
     sKey       OCTET STRING OPTIONAL }
     ( WITH COMPONENTS { ..., sKeyAttrs PRESENT } |
       WITH COMPONENTS { ..., sKey PRESENT } )

   KeyPkgVersion ::= INTEGER  { v1(1) } ( v1, ... )

   A key-package (SymmetricKeyPackage) contains some meta-information,
   including attributes (sKeyPkgAttrs) [Housley-symmkey], and a sequence
   of key-structures.  Each individual key-structure (OneSymmetricKey)
   contains some attributes (sKeyAttrs) and some actual keying material
   (sKey).  Attributes in the sKeyPkgAttrs field apply to every key in
   the package, while attributes in a sKeyAttrs field apply only to the
   key in the containing OneSymmetricKey structure.  The same attribute
   cannot appear at both the package-level and the key-level.  That is,
   a given attribute can:

   o  appear in the sKeyPkgAttrs field but not in the sKeyAttrs field of
      any OneSymmetricKey structure,

   o  appear in the sKeyAttrs field of one or more OneSymmetricKey
      structures but not the sKeyPkgAttrs field, or

   o  not be included in the key-package at all.

   Also, it is not required that every attribute be applicable at both
   levels.  That is, [Housley-symmkey] allows a given attribute to be
   valid for only the sKeyPkgAttrs field or for only the sKeyAttrs
   field.




Herzog & Khazan        Expires September 23, 2010               [Page 4]


Internet-Draft             A set-key attribute                March 2010


   The grammar for attributes is quite complex and given in
   [Housley-symmkey].  We intend to use only a small subset of this
   grammar, however, and therefore do not reproduce it here.  We note,
   however, that it can be used to define a wide variety of attributes,
   such as attributes to represent the expiration date of a key or key-
   package, the intended cryptographic algorithm for a key, an
   identifier for a key or key-package, or the creator of a key or key-
   package.  As such attributes do not apply only to set-keys, however,
   we will not consider them futher in this document.

1.3.  Intended Usage

   The attribute defined in this document is meant to be embedded in a
   SymmetricKeyPackage structure, perhaps with other attributes as well.
   The resulting value will then hold a set-key in a common and standard
   format.  This format is appropriate both for transporting set-keys
   and for holding set-keys computed from some higher-level protocol.
   That is, one could create and distribute set-keys in this format
   through some distribution protocol, or one could use this format to
   hold set-keys computed by some protocol as Logical Key Heirarchy
   [RFC2627].

1.4.  Requirements Terminology

   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.


2.  The set-key attribute

   The set-key attribute is used to associate a participant-set with a
   symmetric key-package, where the participant-set MAY be divided into
   the active and passive participants.  It has the following syntax:

















Herzog & Khazan        Expires September 23, 2010               [Page 5]


Internet-Draft             A set-key attribute                March 2010


   aa-setkey-information ATTRIBUTE ::= {
        TYPE SetKeyInformation
        IDENTIFIED BY id-aa-setkey-information }

   id-aa-setkey-information OBJECT IDENTIFIER ::= {
     iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
            smime(16) aa(2) XX }

   SetKeyInformation::= SEQUENCE {
        active     SetKeyParticipantSet,
        passive    SetKeyParticipantSet OPTIONAL }

   SetKeyParticipantSet ::= CHOICE {
        union        [0] SEQUENCE SIZE (1..MAX) OF SetKeyParticipantSet,
        intersection [1] SEQUENCE SIZE (1..MAX) OF SetKeyParticipantSet,
        setdiff      [2] SEQUENCE {
                          orig SetKeyParticipantSet,
                          without SetKeyParticipantSet },
        community    [3] Community,
        groupName    [4] OCTET STRING,
        explicit     [5] SEQUENCE OF SetMember }

   SetMember ::= CHOICE {
        issuerAndSerialNumber  [0] IssuerAndSerialNumber,
        publicKey              [1] SubjectPublicKeyInfo,
        participantName        [2] OCTET STRING }


   This attribute SHOULD NOT appear in the sKeyAttrs field of a
   OneSymmetricKey structure.  That is, it is defined to apply only to
   symmetric-key packages, not individual keys.

   The SetKeyInformation fields are used as follows:

   o  The 'active' and 'passive' fields jointly identify the
      participant-set of this set-key.  The 'active' field identifies
      the active members of this set, meaning those which may send
      messages secured by the set-key.  The 'passive' field identifies
      the passive members of this set, meaning those participants who
      are expected to never send a message secured by this key.  (The
      internal structures of these sets are described below.)  Any
      member which could possibly send messages under some scenario
      SHOULD be in the 'active' field.  A member MAY appear in both
      fields, in which case it SHOULD be considered to be active.

   Both the 'active' and 'passive' field will be values of type
   SetKeyParticipantSet.  These values can be any of:




Herzog & Khazan        Expires September 23, 2010               [Page 6]


Internet-Draft             A set-key attribute                March 2010


   o  A 'union' of other SetKeyParticipantSet values.  This sequence
      MUST be non-empty.  The semanitics of this sequence is as follows:
      a participant is in the union if and only if it is any of the
      SetKeyParticipantSet values of the sequence.  If any set in the
      sequence is non-empty, then the union will be non-empty.  If all
      sets in the union sequence are empty, then the union is empty too.

   o  The 'intersection' of other SetKeyParticipantSet values.  This
      sequence MUST be non-empty.  The semantics of this sequence is as
      follows: a participant is in intersection if and only if it is all
      of the SetKeyParticipantSet values of the sequence.  If any set in
      the sequence is empty, the intersection is empty, too.  If all
      sets in the sequence are non-empty, the intersection might still
      be empty (which it would be if there is no element common to all
      sets in the sequence).

   o  The set-difference ('setdiff') of two other SetKeyParticipantSet
      values.  The semantics of this is as follows: a participant is in
      the set-difference if and only if it is in the set identified in
      the 'orig' field and not in the set identified by the 'without'
      field.  If the set identified in the 'orig' field is empty is
      empty, then the set-difference will be empty.  If the set
      identified in the 'orig' field is a subset of the set identified
      in the 'without' field, then the set-difference will be empty.  If
      neither of the two previous cases apply, the set-difference will
      be non-empty.

   o  A community, which is used byt the Trust Anchor Management
      Protocol (TAMP) [Housley-TAMP] to identify a set of 'cryptographic
      modules.'

   o  A 'groupName', which is interpreted in an application-independent
      way.  One possible use for this option is to name pre-established
      groups such as organizational departments or roles.  The details
      of establishing or using such a name-space are outside the scope
      of this document.

   o  An 'explicit' list of SetMember values.  In this sequence, order
      is not given any meaning.  This sequence MAY be empty, in which
      case it represents the empty set of participants.

   A SetMember value, meant to identify a specific unique participant,
   can be any of:

   o  An IssuerAndSerialNumber value, defined in [Hoffman-CMS],

   o  A SubjectPublicKeyInfo, defined in [Hoffman-PKIX], or




Herzog & Khazan        Expires September 23, 2010               [Page 7]


Internet-Draft             A set-key attribute                March 2010


   o  A freeform ('participantName') octet-string, which is interpreted
      in an application-dependent way.  One possible use of this option
      is to use pre-established names for participants.  The details of
      establishing or using such a name-space are outside the scope of
      this document.

   If the set-key attribute is present, it MUST contain a single value.


3.  Security Considerations

   As with the entire symmetric-key package, the set-key attribute is
   not protected.  The symmetric key package content type can be
   combined with a security protocol to protect the contents of the
   attribute.


4.  References

4.1.  Normative References

   [Hoffman-CMS]
              Hoffman, P. and J. Schaad, "New ASN.1 Modules for CMS and
              S/MIME", Internet Draft draft-ietf-smime-new-asn1-07.txt,
              August 2009.

   [Hoffman-PKIX]
              Hoffman, P. and J. Schaad, "New ASN.1 Modules for PKIX",
              Internet Draft draft-ietf-pkix-new-asn1-07.txt,
              August 2009.

   [Housley-TAMP]
              Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor
              Management Protocol (TAMP)", Internet
              Draft draft-ietf-pkix-tamp.txt, December 2009.

   [Housley-symmkey]
              Turner, S. and R. Housley, "Symmetric Key Package Content
              Type", Internet
              Draft draft-ietf-keyprov-symmetrickeyformat-07.txt,
              February 2010.

   [RFC5652]  Housley, R., "Cryptographic Message Syntax (CMS)", Request
              For Comments 5652, September 2009.

   [X.680]    ITU-T, "Information Technology - Abstract Syntax Notation
              One", Recommendation X.680, ISO/IEC 8824-1:2002, 2002.




Herzog & Khazan        Expires September 23, 2010               [Page 8]


Internet-Draft             A set-key attribute                March 2010


   [X.681]    ITU-T, "Information Technology - Abstract Syntax Notation
              One: Information Object Specification",
              Recommendation X.681, ISO/IEC 8824-2:2002, 2002.

   [X.682]    ITU-T, "Information Technology - Abstract Syntax Notation
              One: Constraint Specification", Recommendation X.682, ISO/
              IEC 8824-3:2002, 2002.

   [X.683]    ITU-T, "Information Technology - Abstract Syntax Notation
              One: Parameterization of ASN.1 Specifications",
              Recommendation X.683, ISO/IEC 8824-4:2002, 2002.

4.2.  Informative References

   [RFC2627]  Wallner, D., Harder, E., and R. Agee, "Key Management for
              Multicast: Issues and Architectures", RFC 2627, June 1999.


Appendix A.  ASN.1 Module

   This appendix provides the normative ASN.1 definitions for the
   structures described in this specification using ASN.1 as defined in
   [X.680] through [X.683].

SetKeyAttributev1
  { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
    smime(16) modules(0) XX }

DEFINITIONS IMPLICIT TAGS ::=

BEGIN

-- EXPORTS ALL

IMPORTS


   ATTRIBUTE
     FROM PKIX-CommonTypes-2009
       {iso(1) identified-organization(3) dod(6) internet(1) security(5)
       mechanisms(5) pkix(7) id-mod(0) id-mod-pkixCommon-02(57)}
   IssuerAndSerialNumber
     FROM CryptographicMessageSyntax-2009
       { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
         smime(16) modules(0) id-mod-cms-2004-02(41)}
   SubjectPublicKeyInfo
     FROM PKIX1Explicit-2009
       { iso(1) identified-organization(3) dod(6) internet(1)



Herzog & Khazan        Expires September 23, 2010               [Page 9]


Internet-Draft             A set-key attribute                March 2010


         security(5) mechanisms(5) pkix(7) id-mod(0)
         id-mod-pkix1-explicit-02(51) }
   Community
     FROM TAMP-Protocol-v2
       { joint-iso-ccitt(2) country(16) us(840) organization(1)
         gov(101) dod(2) infosec(1) modules(0) 30 }
   ;


aa-setkey-information ATTRIBUTE ::= {
     TYPE SetKeyInformation
     IDENTIFIED BY id-aa-setkey-information }

id-aa-setkey-information OBJECT IDENTIFIER ::= {
  iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
         smime(16) aa(2) XX }

SetKeyInformation::= SEQUENCE {
     active     SetKeyParticipantSet,
     passive    SetKeyParticipantSet OPTIONAL }

SetKeyParticipantSet ::= CHOICE {
     union        [0] SEQUENCE SIZE (1..MAX) OF SetKeyParticipantSet,
     intersection [1] SEQUENCE SIZE (1..MAX) OF SetKeyParticipantSet,
     setdiff      [2] SEQUENCE {
                       orig SetKeyParticipantSet,
                       without SetKeyParticipantSet },
     community    [3] Community,
     groupName    [4] OCTET STRING,
     explicit     [5] SEQUENCE OF SetMember }

SetMember ::= CHOICE {
     issuerAndSerialNumber  [0] IssuerAndSerialNumber,
     publicKey              [1] SubjectPublicKeyInfo,
     participantName        [2] OCTET String }
END


Authors' Addresses

   Jonathan C. Herzog
   MIT Lincoln Laboratory
   244 Wood St.
   Lexington, MA  02144
   USA

   Email: jherzog@ll.mit.edu




Herzog & Khazan        Expires September 23, 2010              [Page 10]


Internet-Draft             A set-key attribute                March 2010


   Roger Khazan
   MIT Lincoln Laboratory
   244 Wood St.
   Lexington, MA  02144
   USA

   Email: rkh@ll.mit.edu












































Herzog & Khazan        Expires September 23, 2010              [Page 11]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/