RFC 5275
CMS Symmetric Key Management and Distribution
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).
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
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
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].
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.
+----> +----> +----> PK +-----+ S | S +-----+ S | S | ----> | MLA | --+----> ----> | MLA | --+----> ----+----> +-----+ | +-----+ | | +----> +----> +----> Scenario 1 Scenario 2 Scenario 32. 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
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)
