tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 5275

 Errata 
Proposed STD
Pages: 89
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: SMIME

CMS Symmetric Key Management and Distribution

Part 1 of 5, p. 1 to 7
None       Next RFC Part

 


Top       ToC       Page 1 
Network Working Group                                          S. Turner
Request for Comments: 5275                                          IECA
Category: Standards Track                                      June 2008


             CMS Symmetric Key Management and Distribution

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Abstract

   This document describes a mechanism to manage (i.e., set up,
   distribute, and rekey) keys used with symmetric cryptographic
   algorithms.  Also defined herein is a mechanism to organize users
   into groups to support distribution of encrypted content using
   symmetric cryptographic algorithms.  The mechanism uses the
   Cryptographic Message Syntax (CMS) protocol and Certificate
   Management over CMS (CMC) protocol to manage the symmetric keys.  Any
   member of the group can then later use this distributed shared key to
   decrypt other CMS encrypted objects with the symmetric key.  This
   mechanism has been developed to support Secure/Multipurpose Internet
   Mail Extensions (S/MIME) Mail List Agents (MLAs).

Top       Page 2 
Table of Contents

   1. Introduction ....................................................4
      1.1. Conventions Used in This Document ..........................4
      1.2. Applicability to E-mail ....................................5
      1.3. Applicability to Repositories ..............................5
      1.4. Using the Group Key ........................................5
   2. Architecture ....................................................6
   3. Protocol Interactions ...........................................7
      3.1. Control Attributes .........................................8
           3.1.1. GL Use KEK .........................................10
           3.1.2. Delete GL ..........................................14
           3.1.3. Add GL Member ......................................14
           3.1.4. Delete GL Member ...................................15
           3.1.5. Rekey GL ...........................................16
           3.1.6. Add GL Owner .......................................16
           3.1.7. Remove GL Owner ....................................17
           3.1.8. GL Key Compromise ..................................17
           3.1.9. GL Key Refresh .....................................18
           3.1.10. GLA Query Request and Response ....................18
                  3.1.10.1. GLA Query Request ........................18
                  3.1.10.2. GLA Query Response .......................19
                  3.1.10.3. Request and Response Types ...............19
           3.1.11. Provide Cert ......................................19
           3.1.12. Update Cert .......................................20
           3.1.13. GL Key ............................................21
      3.2. Use of CMC, CMS, and PKIX .................................23
           3.2.1. Protection Layers ..................................23
                  3.2.1.1. Minimum Protection ........................23
                  3.2.1.2. Additional Protection .....................24
           3.2.2. Combining Requests and Responses ...................24
           3.2.3. GLA Generated Messages .............................26
           3.2.4. CMC Control Attributes and CMS Signed Attributes ...27
                  3.2.4.1. Using cMCStatusInfoExt ....................27
                  3.2.4.2. Using transactionId .......................30
                  3.2.4.3. Using Nonces and signingTime ..............30
                  3.2.4.4. CMC and CMS Attribute Support
                           Requirements ..............................31
           3.2.5. Resubmitted GL Member Messages .....................31
           3.2.6. PKIX Certificate and CRL Profile ...................31
   4. Administrative Messages ........................................32
      4.1. Assign KEK to GL ..........................................32
      4.2. Delete GL from GLA ........................................36
      4.3. Add Members to GL .........................................38
           4.3.1. GLO Initiated Additions ............................39
           4.3.2. Prospective Member Initiated Additions .............47
      4.4. Delete Members from GL ....................................49
           4.4.1. GLO Initiated Deletions ............................50

Top      ToC       Page 3 
           4.4.2. Member Initiated Deletions .........................56
      4.5. Request Rekey of GL .......................................57
           4.5.1. GLO Initiated Rekey Requests .......................59
           4.5.2. GLA Initiated Rekey Requests .......................62
      4.6. Change GLO ................................................63
      4.7. Indicate KEK Compromise ...................................65
           4.7.1. GL Member Initiated KEK Compromise Message .........66
           4.7.2. GLO Initiated KEK Compromise Message ...............67
      4.8. Request KEK Refresh .......................................69
      4.9. GLA Query Request and Response ............................70
      4.10. Update Member Certificate ................................73
           4.10.1. GLO and GLA Initiated Update Member Certificate ...73
           4.10.2. GL Member Initiated Update Member Certificate .....75
   5. Distribution Message ...........................................77
      5.1. Distribution Process ......................................78
   6. Algorithms .....................................................79
      6.1. KEK Generation Algorithm ..................................79
      6.2. Shared KEK Wrap Algorithm .................................79
      6.3. Shared KEK Algorithm ......................................79
   7. Message Transport ..............................................80
   8. Security Considerations ........................................80
   9. Acknowledgements ...............................................81
   10. References ....................................................81
      10.1. Normative References .....................................81
      10.2. Informative References ...................................82
   Appendix A. ASN.1 Module ..........................................83

Top      ToC       Page 4 
1.  Introduction

   With the ever-expanding use of secure electronic communications
   (e.g., S/MIME [MSG]), users require a mechanism to distribute
   encrypted data to multiple recipients (i.e., a group of users).
   There are essentially two ways to encrypt the data for recipients:
   using asymmetric algorithms with public key certificates (PKCs) or
   symmetric algorithms with symmetric keys.

   With asymmetric algorithms, the originator forms an originator-
   determined content-encryption key (CEK) and encrypts the content,
   using a symmetric algorithm.  Then, using an asymmetric algorithm and
   the recipient's PKCs, the originator generates per-recipient
   information that either (a) encrypts the CEK for a particular
   recipient (ktri RecipientInfo CHOICE) or (b) transfers sufficient
   parameters to enable a particular recipient to independently generate
   the same KEK (kari RecipientInfo CHOICE).  If the group is large,
   processing of the per-recipient information may take quite some time,
   not to mention the time required to collect and validate the PKCs for
   each of the recipients.  Each recipient identifies its per-recipient
   information and uses the private key associated with the public key
   of its PKC to decrypt the CEK and hence gain access to the encrypted
   content.

   With symmetric algorithms, the origination process is slightly
   different.  Instead of using PKCs, the originator uses a previously
   distributed secret key-encryption key (KEK) to encrypt the CEK (kekri
   RecipientInfo CHOICE).  Only one copy of the encrypted CEK is
   required because all the recipients already have the shared KEK
   needed to decrypt the CEK and hence gain access to the encrypted
   content.

   The techniques to protect the shared KEK are beyond the scope of this
   document.  Only the members of the list and the key manager should
   have the KEK in order to maintain confidentiality.  Access control to
   the information protected by the KEK is determined by the entity that
   encrypts the information, as all members of the group have access.
   If the entity performing the encryption wants to ensure that some
   subset of the group does not gain access to the information, either a
   different KEK should be used (shared only with this smaller group) or
   asymmetric algorithms should be used.

1.1.  Conventions Used in This Document

   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 BCP 14, RFC 2119
   [RFC2119].

Top      ToC       Page 5 
1.2.  Applicability to E-mail

   One primary audience for this distribution mechanism is e-mail.
   Distribution lists, sometimes referred to as mail lists, support the
   distribution of messages to recipients subscribed to the mail list.
   There are two models for how the mail list can be used.  If the
   originator is a member of the mail list, the originator sends
   messages encrypted with the shared KEK to the mail list (e.g.,
   listserv or majordomo) and the message is distributed to the mail
   list members.  If the originator is not a member of the mail list
   (does not have the shared KEK), the originator sends the message
   (encrypted for the MLA) to the Mail List Agent (MLA), and then the
   MLA uses the shared KEK to encrypt the message for the members.  In
   either case, the recipients of the mail list use the previously
   distributed-shared KEK to decrypt the message.

1.3.  Applicability to Repositories

   Objects can also be distributed via a repository (e.g., Lightweight
   Directory Access Protocol (LDAP) servers, X.500 Directory System
   Agents (DSAs), Web-based servers).  If an object is stored in a
   repository encrypted with a symmetric key algorithm, anyone with the
   shared KEK and access to that object can then decrypt that object.
   The encrypted object and the encrypted, shared KEK can be stored in
   the repository.

1.4.  Using the Group Key

   This document was written with three specific scenarios in mind: two
   supporting Mail List Agents and one for general message distribution.
   Scenario 1 depicts the originator sending a public key (PK) protected
   message to an MLA who then uses the shared KEK(s) to redistribute the
   message to the members of the list.  Scenario 2 depicts the
   originator sending a shared KEK protected message to an MLA who then
   redistributes the message to the members of the list (the MLA only
   adds additional recipients).  The key used by the originator could be
   a key shared either amongst all recipients or just between the member
   and the MLA.  Note that if the originator uses a key shared only with
   the MLA, then the MLA will need to decrypt the message and reencrypt
   the message for the list recipients.  Scenario 3 shows an originator
   sending a shared KEK protected message to a group of recipients
   without an intermediate MLA.

Top      ToC       Page 6 
                   +---->                   +---->       +---->
    PK   +-----+ S |         S    +-----+ S |         S  |
   ----> | MLA | --+---->   ----> | MLA | --+---->   ----+---->
         +-----+   |              +-----+   |            |
                   +---->                   +---->       +---->

       Scenario 1               Scenario 2           Scenario 3

2.  Architecture

   Figure 1 depicts the architecture to support symmetric key
   distribution.  The Group List Agent (GLA) supports two distinct
   functions with two different agents:

   -  The Key Management Agent (KMA), which is responsible for
      generating the shared KEKs.

   -  The Group Management Agent (GMA), which is responsible for
      managing the Group List (GL) to which the shared KEKs are
      distributed.

   +----------------------------------------------+
   |              Group List Agent                |    +-------+
   | +------------+    + -----------------------+ |    | Group |
   | |    Key     |    | Group Management Agent | |<-->| List  |
   | | Management |<-->|     +------------+     | |    | Owner |
   | |   Agent    |    |     | Group List |     | |    +-------+
   | +------------+    |     +------------+     | |
   |                   |       /  |  \          | |
   |                   +------------------------+ |
   +----------------------------------------------+
                            /     |      \
                           /      |       \
               +----------+ +---------+ +----------+
               | Member 1 | |   ...   | | Member n |
               +----------+ +---------+ +----------+

        Figure 1 - Key Distribution Architecture

   A GLA may support multiple KMAs.  A GLA in general supports only one
   GMA, but the GMA may support multiple GLs.  Multiple KMAs may support
   a GMA in the same fashion as GLAs support multiple KMAs.  Assigning a
   particular KMA to a GL is beyond the scope of this document.

   Modeling real-world GL implementations shows that there are very
   restrictive GLs, where a human determines GL membership, and very
   open GLs, where there are no restrictions on GL membership.  To
   support this spectrum, the mechanism described herein supports both

Top      ToC       Page 7 
   managed (i.e., where access control is applied) and unmanaged (i.e.,
   where no access control is applied) GLs.  The access control
   mechanism for managed lists is beyond the scope of this document.
   Note: If the distribution for the list is performed by an entity
   other than the originator (e.g., an MLA distributing a mail message),
   this entity can also enforce access control rules.

   In either case, the GL must initially be constructed by an entity
   hereafter called the Group List Owner (GLO).  There may be multiple
   entities who 'own' the GL and who are allowed to make changes to the
   GL's properties or membership.  The GLO determines if the GL will be
   managed or unmanaged and is the only entity that may delete the GL.
   GLO(s) may or may not be GL members.  GLO(s) may also set up lists
   that are closed, where the GLO solely determines GL membership.

   Though Figure 1 depicts the GLA as encompassing both the KMA and GMA
   functions, the two functions could be supported by the same entity or
   they could be supported by two different entities.  If two entities
   are used, they could be located on one or two platforms.  There is
   however a close relationship between the KMA and GMA functions.  If
   the GMA stores all information pertaining to the GLs and the KMA
   merely generates keys, a corrupted GMA could cause havoc.  To protect
   against a corrupted GMA, the KMA would be forced to double check the
   requests it receives to ensure that the GMA did not tamper with them.
   These duplicative checks blur the functionality of the two components
   together.  For this reason, the interactions between the KMA and GMA
   are beyond the scope of this document.

   Proprietary mechanisms may be used to separate the functions by
   strengthening the trust relationship between the two entities.
   Henceforth, the distinction between the two agents is not discussed
   further; the term GLA will be used to address both functions.  It
   should be noted that a corrupt GLA can always cause havoc.



(page 7 continued on part 2)

Next RFC Part