SMIME Working Group S. Turner INTERNET DRAFT IECA Expires in on 20 June, 2000 December 20, 1999 S/MIME Symmetric Key Distribution Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. This document is an Internet-Draft. 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 6 months and may be updated, replaced, or may become obsolete 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 current Internet-Drafts Shadow Directories can be accessed at http://www.ietf.org/shadow.html.http://www.ietf.org/shadow.html. Abstract This document describes a mechanism to manage (i.e., setup, distribute, and rekey) keys used with symmetric cryptographic algorithms. The mechanisms use the CMSCryptographic Message Syntax (CMS) protocol [CMS] to encrypt the key for each member of the group. Any member of the group can then later use this key to decrypt other CMS encrypted objects with the symmetric or 'group' key. This draft is being discussed on the 'ietf-smime' mailing list. To subscribe, send a message to: ietf-smime-request@imc.org with the single word subscribe in the body of the message. There is a Web site for the mailing list at . 1 Introduction With the ever expanding use of secure electronic communications (e.g., S/MIME [CMS]), 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 the recipients: using asymmetric algorithms with public key certificates (PKCs) or symmetric algorithms with shared secret keys. With asymmetric algorithms, the encrypting user forms an originator-determined content-encryption key (CEK) and encrypts the content, using a symmetric algorithm. Then, using an asymmetric algorithm and PKCs, the encrypting user generates per-recipient information that either (a) encrypts the CEK for a particular recipient (ktri ReipientInfo CHOICE), or (b) transfers sufficient parameters to enable a particular recipient to independently generate the same CEK (kari RecipientInfo CHOICE). If the group is large the number of per- recipient information that needs to be generated may take quite some time, not to mention the time required to collect the PKCs for each of the recipients. With symmetric algorithms, all members of the group use a previously shared distributed secret key-encryption key (KEK). The originating user only needs to encrypt the content with the shared KEK, which is then used by every member in the group to decrypt the message. A mechanism is defined herein to support distribution of shared KEKs in order to enable symmetric algorithms. [ST - I interchangeable use group key to mean shared KEK. In the next version I will use the term shared KEK through out the document.] The security provided by the symmetric key is only as good as the sum of the techniques employed by each member of the group to keep the symmetric key secret from nonmembers. These techniques are beyond the scope of this document. Only the members of the list and the key manager should have the key in order to maintain the secrecy of the group. Access control to the information protected by the symmetric key is determined by the entity that encrypts the information, as all members of the group have access. If the entity that is performing the encryption wants to ensure some subset of the group does not gain access to the information either a different symmetric key should be used (shared with this smaller group) or asymmetric algorithms should be used. 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 [MUSTSHOULD]. 1.1 Applicability to E-mail One primary audience for this distribution mechanism is e-mail. Distribution lists sometimes referred to as mail lists, have been defined to support distribution of messages to a group of recipients subscribed to the originatormail 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 the encrypted message with the symmetric 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 group key), the originator sends the message to the mail list agent (MLA) and the MLA then forms the KEK key needed for the message. In either case the recipients of the mail list use the previously distributed group key to decrypt the message. 1.2 Applicability to Repositories Objects can also be distributed via a repository (e.g., Light Weight Directory 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, any one with access to that object can then decrypt that object. The encrypted object and the encrypted key can be stored in the repository. 2. Architecture Figure 1 depicts the architecture to support symmetric key distribution. Two different functions are required: generating the keys and distributing the keys. These functions are performed by two conceptually different entities. The Key Management Agent (KMA) is responsible for generating the keys and the Group Management Agent (GMA) holds the group list (GL) to which it is responsible for distributing the keys. Either the KMA or GMA MAY: - Support one GL or multiple GLs; - Be collocated one a single platform or on separate platforms. GLs are managed either through an automated process or by a human (an GL Owner). Members of the GLs require access to the symmetric key therefore adding and removing members is an important part of maintaining the security for the entire group. If the GL is managed through an automated process, mechanisms, beyond the scope of this document, may be used to limit the addition of new members (e.g., using an access control list) or the GL may be configured to allow anyone to join or depart from the GL. If the GL is managed by a human, messages, beyond the scope of this document, may be sent between the new member and the GL Owner requesting the new member be added to the GL. The GL Owner may then decide whether the new member should be added or not or the GL Owner may simply add a new member, knowing the new member requires access to the messages. The GL Owner may or may not be a member of the GL, but the GL Owner is the only person(s) able to add or delete a GL. +----------------------+ | Key Management Agent | +----------------------+ | +------------------+ | Group Management | | Agent | | +-------+ | | | Group | | | | List | | | +-------+ | | / | \ | +------------------+ / | \ / | \ +----------+ +---------+ +----------+ | Member 1 | | ... | | Member n | +----------+ +---------+ +----------+ Figure 1 - Key Distribution Architecture 3 Protocol Interactions A few basic interactions occur between the KMA, GMA, Members, and the optional GL Owner (used if the list is not managed by an automated process) to support the management of the symmetric keys used by the group (henceforth referred to as the group key). Management includes the steps required to setup the group key, add new members, delete members, and distribute a new group key (i.e., rekey). The following sections describe the procedures for each of the management functions. [ST - Need to add what's mandatory to implement here - I think sending and receiving gkDistribution messages; storing the distributed key; and using the previously distributed key to decrypt future messages.] 3.1 Group Key Administration Figure 2 depicts the scenarios for group key setup administration. Each of the interactions depicted is discussed in paragraphs 3.1.1, 3.1.2, 3.1.3, and 3.1.4. +----------+ +----------+ | GL Owner | <---+ +----> | Member 1 | <--+ +----------+ | | +----------+ | | | | +-----+ +-----+ <----+ | +----------+ | | KMA | <----------> | GMA | <---------------+----> | ... | <--+ +-----+ +-----+ | +----------+ | | | | | | +----------+ | | +----> | Member n | <--+ | +----------+ | +----------------------------------------------------------------+ Figure 2 - Group Key Setup 3.1.1 Request/Response Group Key Administration There are a number of administrative functions that must be performed to manage a GL: creating the GL, deleting the GL, adding members to the GL, deleting members of the GL, and requesting a group rekey. The group key administration request (gkaRequest) and group key administration responses (gkaResponse) content-types, defined in paragraphs 3.1.1.1 and 3.1.1.2, are defined to support these administrative functions. The gkaRequest and gkaResponse MAY be used between the GL Owner and the GMA and between the GL Owner or GMA and the KMA to manage the GL. If the message is from the GMA to the KMA, it may be on behalf of the GL Owner or from the GL members. If the GL Owner supports the gkaRequest content-type, it MUST support the corresponding gkaResponse content-type. The GMA MAY support forwarding the gkaRequest content-type from the GL Owner to the KMA and the gkaResponse content-type from the KMA to the GL Owner. If the KMA supports forwarding the gkaRequest it MUST support forwarding the gkaResponse. The GMA MAY support generating the gkaRequest content-type on behalf of prospective GL member or existing GL members. The KMA MAY support receiving a gkaRequest content-type and generating a gkaResponse content-type. If the KMA supports receiving the gkaRequest content-type it must support generating the gkaResponse content-type. 3.1.1.1 Request For Group Key Administration The gkaRequest content-type is defined to support conveying group key administration requests from the GL Owner to the GMA or from the GMA to the KMA. The gkaRequest content-type MUST be protected at a minimum by id-signedData [CMS]. It MAY also be further enveloped by id- envelopedData [CMS]. Other layers MAY also be used. The following object identifier identifies the gkaRequest content-type: id-ct-gkaRequest OBJECT IDENTIFIER ::= { TBD } The gkaRequest content type MUST have ASN.1 type GKARequest: GKARequest ::= SEQUENCE { gkaRequestVersion GKARequestVersion, gkAAction GKAAction, transactionId TransactionId OPTIONAL} GKAResquestVersion ::= INTEGER { v0(0) } GKAAction ::= CHOICE { createGL [0] GLInformation, deleteGL [1] GLInformation, addGLMembers [2] GLInformation, deleteGLMembers [3] GLInformation, rekeyGL [4] GLInformation } GLInformation ::= SEQUENCE { glName GeneralName, glIdentifier [0] OCTET STRING OPTIONAL, glMembers [1] SEQUENCE OF GLMember OPTIONAL, glOwner [2] GLOwner OPTIONAL, effectiveDate [3] EffectiveDate OPTIONAL, distributionDate [4] GeneralizedTime OPTIONAL } GLMember ::= SEQUENCE { OPTIONAL,name GeneralName, deliveryMethod [0] SEQUENCE OF DeliveryMethod OPTIONAL } certificates [1] CertificateSet OPTIONAL, crls [2] CertificateRevocationListsOPTIONAL } DeliveryMethod ::= CHOICE { rfc822Name [0] IA5String, x400Address [1] ORAddress, directoryName [2] Name, uniformResourceIdentifier [3] IA5String, iPAddress [4] OCTET STRING } CertificateSet ::= SET OF CertificateChoices CertificateChoices ::= CHOICE { certificate Certificate, -- See X.509 extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete attrCert [1] IMPLICIT AttributeCertificate } -- See X.509 and X9.57 CertificateRevocationLists ::= SET OF CertificateList GLOwner ::= SEQUENCE { name GeneralName, administered BOOLEAN DEFAULT FALSE OPTIONAL } EffectiveDate ::= SEQUENCE { notBefore [0] GeneralizedTime, notAfter [1] GeneralizedTime OPTIONAL } TransactionId ::= OCTET STRING The fields in GKSResponse have the following meaning: Note: The support requirement for the fields is determined by the action being performed; therefore, the support requirements are indicated in paragraphs 3.1.1.3 through 3.1.1.7, where the specific actions are defined. - version is the syntax version number. The version number MUST be 0. - gkaAction indicates the action that the GL Owner requests the GMA perform, thatthe GL Owner requests the KMA perform, or the GMA requests the KMA perform. The GL Owner MAY request that either the KMA or GMA create a GL (createGL), delete a GL (deleteGL), add a member to a specific GL (addGLMembers), delete a member of a specific GL (deleteGLMember), or rekey a GL (rekeyGL). When the GL Owner requests the actions of the GMA the action MUST be forwarded to the KMA. The GMA MAY request, on behalf of the GL members, that a member be added or deleted, assuming the GL policy allows this function. All of the actions have the same syntax (GLInformation). Different combinations of the GLInformation are used to provide information necessary for the KMA or GMA to perform its requested action. The field combinations are discussed in 3.1.1.3 through 3.1.1.7, but fields in GLInformation have the following meaning: - glName is the name of the GL. - glIdentifier is the GL identifier. The GL identifier identifies the specific GL on the GMA (the GMA may support multiple GLs). It is derived from the group key and is returned by the KMA. - gkMembers is a collection of the member(s) that should be either added or deleted from the GL. The member's name is a GeneralName. deliveryMethod identifies the method by which and address or location to which the KMA should distribute the group key. Only one choice for each of the type is allowed (i.e., only one rfc822Name may appear for a given member). certificates and crls are the member's certificate, associated certificates, and associated certificate revocation lists (CRLs). - glOwner is the owner of the GL. It identifies the entity that controls the GL. It also indicates whether the GL is managed or unmanaged. - effectiveDate indicates the dates that the GL Owner wants the KMA to set the gkNotBefore and gkNotAfter to (see paragraph 3.1.2). The notBefore date indicates the date the GL Owner wants the key to become effective and the notAfter indicates the date the GL Owner wants the key to become invalid. - distributionDate indicates the date that the GL Owner wants the key distributed. - transactionID supports the recipient of a response message to correlate this with a previously issued request. For example, in the case of a GMA, which supports multiple GLs, there may be many requests "outstanding" at a given moment. 3.1.1.2 Response To Group Key Administration Upon receipt of the gkaRequest content-type the KMA MUST use the gkaResponse content-type to indicate the success or failure of the request. The gkaResponse is not sent until after the KMA has determined whether the member is able to receive the key. The KMA may not be able to send the member a group key because either the deliveryMethod is unsupported or the member's certificate is invalid. The id-gkaRequest content-tye MUST be processed according to [CMS]. The KMA MUST validate the member's certificate and associated certificates to the KMA trusted CA according to [PROFILE] prior to sending a gkaResponse message indicating success. The gkaResponse message MUST be protected at a minimum by id-signedData [CMS]. Other layers MAY also be used. The following object identifier identifies the gkaRequest content type: id-ct-gkaResponse OBJECT IDENTIFIER ::= { TBD } The gkaResponse content type MUST have ASN.1 type GKAResponse: GKAResponse ::= SEQUENCE { gkaResponseVersion GKAResponseVersion, success BOOLEAN DEFAULT TRUE, glIdentifier OCTET STRING OPTIONAL, errorCode ErrorCode OPTIONAL, transactionId TransactionId OPTIONAL, supportDeliveryMethods DeliveryMethod OPTIONAL} ErrorCode ::= INTEGER { unspecified (0), -- Unspecified indicates that the KMA is unable to -- distribute a group key to the member, but the KMA is -- unwilling to indicate why. managedGL (1) -- Indicates that members can only be added or deleted by the GL -- Owner. It is sent back to the requestor if the entity requesting -- an addition is not the GL Owner. effectiveDateTooLong (2) -- Returned if the KMA does not support generating keys that are -- valid for the entire requested effective dates. unsupportedDeliveryMethod (3), -- Unsupported delivery method indicates that the KMA does -- not support any of the requested delivery methods. invalidCert (4), -- Certificate for member was not verifiable (i.e., signature -- did not validate, certificate present on a CRL, etc.) } GKAResponseVersion ::= INTEGER { v0(0) } The fields in GKAResponse have the following meaning: - version is the syntax version number. It MUST be 0. - success indicates whether the KMA is able to send a group key to the member. If the KMA is unable to distribute the group key to the member, it MUST indicate an errorCode. - glIdentifier indicate the GL identifier, derived from the group key. - errorCode indicates the reason why the KMA was unable to distribute a group key to the member. Reasons include unspecified, managedGL, effectiveDateTooLong, unsupportedDeliveryMethod, and invalidCert. - transactionID supports the recipient of a response message to correlate this with a previously issued request. For example, in the case of a GMA, which supports multiple GLs, there may be many requests "outstanding" at a given moment. - supportedDeliveryMethod MAY be included the indicate the delivery methods the KMA supports. 3.1.1.3 Create Group Prior to generating a group key, a GL MUST be setup. The GL Owner is responsible for creating the GL (1 in Figure 3). The GL Owner MAY use a proprietary mechanism (e.g., listserv or majordomo) or the group key administration mechanism defined in the paragraph below to perform this function. +----------+ 2,4{3} | GL Owner | <-----+ +----------+ | 1 | +-----+ 2{1} 3 +-----+ <-----+ | KMA | <-------> | GMA | +-----+ +-----+ Figure 3 - Create Group List If the GL Owner decides to use the gkaRequest content-type to setup the GL on the GMA, the gkaRequest content-type MUST be submitted to the GMA (1 in Figure 2) with the gkaAction.createGL CHOICE. The format for the createGL CHOICE is as follows: - glName MUST be included to indicate the name of the GL. The value must be unique for a given distribution method. - glIdentifier MUST be omitted as the value is derived from the group key, which is not yet created. - glMembers MAY be included to indicate the member(s) to be added. If members are included the name of the member MUST be include in GLMember.name. The delivery method MAY be included. If the GMA does not support the requested delivery method an error MUST be returned. The members certificates and crls MAY also be included. - glOwner.name MUST be included to indicate the Owner of the GL. The GL Owner is the only entity allowed to delete the GL (see paragraph 3.1.1.4). If the list is to be managed (i.e., only allow the GL Owner to add or delete GL members) glOwner.administered MUST be set to TRUE; otherwise, the list is considered to be unmanaged. The GMA MUST only allow additions (see paragraph 3.1.1.5) to the GL if one of the glOwner names matches one of the names associated with one of the certificates used to sign the id-signedData. - effectiveDate MAY be included to indicate the dates the GL Owner wishes the key to become effective. If this field is omitted the GMA assumes the gkNotBefore date (see paragraph 3.1.2) is the GMA's current date. - distributionDate MAY be included to indicate the date the GL Owner wishes the key to be distributed. If the distributitionDate is omitted the GMA assumes the group key should be distributed immediately. The GMA then forwards the gkaRequest content-type to the KMA (2{1} in Figure 3). An additional id-signedData or some other combination of id- signedData and id-envelopedData MAY protect the forwarded content-type. Upon receipt of the gkaRequest content-type, the KMA verifies the gkaRequest content-type and returns a gkaResponse (3 in Figure 3). If the GL can be created as requested, the KMA MUST return a gkaResponse to the GMA indicating success and the glIdentifier of the newly created list. If the GL can not be created as requested the KMA returns a gkaResponse to the GMA indicating failure along with an errorCode. If there are members included in the gkaRequest the KMA MUST use the mechanism described in paragraph 3.2 to distribute the group key. The GMA then forwards the gkaResponse content-type to the GL Owner (4{3} in Figure 3). An additional id-signedData or some other combination of id-signedData and id-envelopedData MAY protect the forwarded conent- type. 3.1.1.4 Delete Group To delete a GL (1 in Figure 4), the GL Owner MAY use a proprietary mechanim (e.g., listserv or majordomo) or the group key administration mechanism defined in the paragraph below to perform this function. Only the GL Owner can request that a GL be deleted. +----------+ 2,4{3} | GL Owner | <-----+ +----------+ | 1 | +-----+ 2{1} 3 +-----+ <-----+ | KMA | <-------> | GMA | +-----+ +-----+ Figure 4 - Delete Group List If the GL Owner decides to use the gkaRequest content-type to delete the GL, the gkaRequest content-type MUST be submitted to the GMA (1 in Figure 2) with the gkaAction.deleteGL CHOICE. The format for the deleteGL CHOICE is as follows: - glName MUST be included to indicate the name of the GL to be deleted. - glIdentifier MUST be included to indicate the identifier of the GL to be deleted. - glMembers MUST be omitted. - glOwner MUST be included to indicate the name of the GL Owner. administered MUST be omitted. The name in this field MUST match one of the names in one of the certificates used in content-type used to create the group. - effectiveDate MUST be omitted. - distributionDate MUST be omitted. The GMA MUST not accept further requests from users (in the case of unadministered GLs) to be added or deleted from the GL. The GMA MUST forward the gkaRequest to the KMA. Upon receipt of the gkaRequest content-type, the KMA verifies the gkaRequest content-type and returns a gkaResponse (3 in Figure 3) indicating success and the glIdentifier of the deleted GL. errorCode and supportedDeliveryMethods MUST be omitted. The GMA then forwards the gkaResponse content-type to the GL Owner (4{3} in Figure 3). An additional id-signedData or some other combination of id-signedData and id-envelopedData MAY protect the forwarded conent- type. 3.1.1.5 Add Group Members GL setup indicates whether the GL is to be managed or unmanaged. In the managed case, the GL Owner is the only entity allowed to request member additions to the GL. In the unmanaged case, anyone can request to be added to the GL. Figure 4 depicts the protocol interactions for the two options. +----------+ 7{6} 2,9{8b} +----------+ 8a | GL Owner | <-+ +-------> | Member 1 | <--+ +----------+ | | +----------+ | 1a | | | +-----+ 4{1a},5 6,8b +-----+ <--+ | 2,9{8b} +----------+ 8a | | KMA | <----------> | GMA | 1b,3 +-------> | ... | <--+ +-----+ +-----+ <-------------+ +----------+ | | | | | | 2,9{8b} +----------+ 8a | | +-------> | Member n | <--+ | +----------+ | +-----------------------------------------------------------------+ Figure 4 - Member Addition A decision that needs to be made on a group by group basis is whether to rekey the group every time a new member is added. Typically, unmanaged GLs should not be rekeyed when a new member is added, as the overhead associated with rekeying the group becomes prohibitive as the group becomes large. However, managed GLs may be rekeyed depending on group policy. An option to rekeying the managed GLs when a member is added is to generate a new GL with a different group key. 3.1.1.5.1 Managed GLs The GL Owner MAY use a proprietary mechanism (e.g., listserv or majordomo) or the group key administration mechanism defined below to add new members to the GL. If the GL Owner decides to use the gkaRequest content-type MUST be submitted to the GMA (1a in Figure 4) with the gkaAction.addGLMembers CHOICE. The format for the addGLMembers CHOICE is as follows: - glName MUST be included to indicate the name of the GL. - glIdentifier MUST be included to indicate the GK that should be distributed to the new member. - glMembers MUST be included to indicate the member(s) to be added. The member(s) name(s) is included in GLMember.name. The delivery method MAY be included. The members certificates and crls MAY also be included. - glOwner.name MUST be included to indicate the Owner of the GL. It MUST match the name one of the certificates used to sign this gkaRequest creating the GL. - effectiveDate MUST be omitted. The value has no meaning as the group key has been previously setup. - distributionDate MAY be included to indicate the date the GL Owner wishes the key to be distributed to the new member(s). If the distributitionDate is omitted the KMA assumes the group key should be distributed immediately. Upon receipt of the gkaRequest, the GMA MAY process the glMembers and add the member(s) for the GL stored on the GMA. The GMA then forwards the gkaRequest content-type to the KMA (4{1a} in Figure 4). An additional id-signedData or some other combination of id-signedData and id-envelopedData MAY protect the forwarded content-type. Upon receipt of the gkaRequest content-type, the KMA verifies the gkaRequest content-type and returns a gkaResponse (6 in Figure 4). If the member can be added, the KMA MUST return a gkaResponse to the GMA indicating success and the glIdentifier of the GL the member was added to. If the member can not be added the KMA MUST return a gkaResponse to the GMA indicating failure along with an errorCode indicating either unsupportedDeliveryMethod or invalidCert. The supportDeliveryMethods MAY also be included to assist the GL Owner in determining whether some other delivery method could be used to distribute the key to the new member. The KMA also distributes the group key via the mechanism described in paragraph 3.2. The KMA also distributes the group key via the mechanism described in paragraph 3.1.3. The group key is either distributed through the GMA (8b and 9{8b} in Figure 4) or directly to the members (8a in Figure 4). The GMA then forwards the gkaResponse content-type to the GL Owner (7{6} in Figure 4). An additional id-signedData or some other combination of id-signedData and id-envelopedData MAY protect the forwarded conent- type. 3.1.1.5.2 Unmanaged GLs For automated scenarios, members send a message (1b in Figure 4), which MAY be unprotected (i.e., unsigned and unencrypted) or protected via id- signedData, id-envelopedData, or tripled wrapped (i.e., signed and/or encrypted) [CMS]. If the message is protected with id-envelopedData the GMA MUST be one of the recipients. A confirmation message (2 in Figure 4) MAY be sent back to the member requesting confirmation of the initial request to inhibit spamming (i.e., to avoid someone other than the member requested the member be added to the list). The response to the confirmation message (3 in Figure 4) indicates whether the member really requested addition to the GL. The format for these messages indicated by 1b, 2, and 3 in Figure 4 are beyond the scope of this document. The GMA MAY support generating a gkaRequest content-type to request members be added. If the GMA supports generating the gkaRequest content- type, it MUST be submitted to the KMA (5 in Figure 4) with the gkaAction.addGLMembers CHOICE. The format for the addGLMembers CHOICE is as follows - glName MUST be included to indicate the name of the GL. - glIdentifier MUST be included to indicate the GK that should be distributed to the new member. - glMembers MUST be included to indicate the member(s) to be added. The member(s) name(s) is included in GLMember.name. The delivery method MAY be included. The member's certificates and crls MAY also be included. - glOwner.name MUST be omitted. - effectiveDate MUST be omitted. - distributionDate MUST be omitted. Upon receipt of the gkaRequest content-type, the KMA verifies the gkaRequest content-type and returns a gkaResponse (6 in Figure 4). If the member can be added, the KMA MUST return a gkaResponse to the GMA indicating success and the glIdentifier of the GL the member was added to. If the member can not be added the KMA MUST return a gkaResponse to the GMA indicating failure along with an errorCode indicating unspecified, managedGL, unsupportedDeliveryMethod, or invalidCert. The supportDeliveryMethods MAY also be included to assist the GMA in determining whether some other delivery method could be used to distribute the key to the new member. The KMA also distributes the group key via the mechanism described in paragraph 3.2. The group key is either distributed through the GMA (8b and 9{8b} in Figure 4) or directly to the members (8a in Figure 4). 3.1.1.6 Delete Group Members GL setup indicates whether the GL is to be managed or unmanaged. In the managed case, the GL Owner is the only entity allowed to request member deletions to the GL. In the unmanaged case, anyone can request to be removed from the GL. Figure 5 depicts the protocol interactions for the two options. +----------+ 7{6} | GL Owner | <-+ +----------+ | 1a | +-----+ 4{1a},5 6,8b +-----+ <--+ +----------+ | KMA | <----------> | GMA | 1b,3 2 | Member X | +-----+ | | <----------------> +----------+ | | | 9{8b},8a | +-----+ ------+----------> +----------+ | | | Member 1 | | | +----------+ +-------------------------------+ | 9{8b},8a +----------+ +----------> | Member n | +----------+ Figure 5 - Member Deletion If the member is not removed from the GL, they will continue to be able to receive and decrypt data protected with the group key and will continue to receive group rekeys. Steps should be taken to ensure a new group key is used (see paragraph 3.1.3). For unmanaged lists, there is no point to a group rekey because there is no guarantee that the member requesting to be removed hasn't already added themselves back on the list under a different name. For managed GLs, the GL Owner must take steps to ensure the member being deleted is not on the list twice. After ensuring this, the managed GL MUST be rekeyed to maintain the secrecy of the group. If the GL Owner is sure the member has been deleted the group rekey mechanism MAY be used to distribute the new key (see paragraph 3.1.1.7). 3.1.1.6.1 Managed GLs The GL Owner MAY use a proprietary mechanism (e.g., listserv or majordomo) or the group key administration mechanism defined below to delete members from the GL. If the GL Owner decides to use the gkaRequest content-type MUST be submitted to the GMA (1a in Figure 4) with the gkaAction.addGLMembers CHOICE. The format for the addGLMembers CHOICE is as follows: - glName MUST be included to indicate the name of the GL. - glIdentifier MUST be included to indicate the GK that should be distributed to the new member. - glMembers MUST be included to indicate the member(s) to be deleted. The member(s) name(s) is included in GLMember.name. The delivery method MUST be omitted. The members certificates and crls MUST also be omitted. - glOwner.name MUST be included to indicate the Owner of the GL. It MUST match the name one of the certificates used to sign this gkaRequest. - effectiveDate MUST be omitted. The value has no meaning as the group key has been previously setup. - distributionDate MUST be omitted. Upon receipt of the gkaRequest, the GMA MAY process the glMembers and remove the member for the GL stored on the GMA. The GMA then forwards the gkaRequest content-type to the KMA (4{1a} in Figure 5). An additional id-signedData or some other combination of id-signedData and id-envelopedData MAY protect the forwarded content-type. Upon receipt of the gkaRequest content-type, the KMA verifies the gkaRequest content-type and returns a gkaResponse (6 in Figure 4). The KMA MUST return a gkaResponse to the GMA indicating success and the glIdentifier of the GL the member was deleted from. The GMA then forwards the gkaResponse back to the GL Owner (7{6} in Figure 5). An additional id-signedData or some other combination of id- signedData and id-envelopedData MAY protect the forwarded conent-type. The KMA MUST also use the group key distribution mechanism defined in paragraph 3.1.3 to provide the remaining members with a new group key. 3.1.1.6.2 Unmanaged GLs For automated scenarios, members send a message (1b in Figure 4), which MAY be unprotected (i.e., unsigned and unencrypted) or protected via id- signedData, id-envelopedData, or tripled wrapped (i.e., signed and/or encrypted) [CMS]. If the message is protected with id-envelopedData the GMA MUST be one of the recipients. A confirmation message (2 in Figure 4) MAY be sent back to the member requesting confirmation of the initial request to inhibit spamming (i.e., to avoid someone other than the member requested the member be added to the list). The response to the confirmation message (3 in Figure 4) indicates whether the member really requested addition to the GL. The format for these messages indicated by 1b, 2, and 3 in Figure 4 are beyond the scope of this document. The GMA MAY support generating a gkaRequest content-type to request members be deleted. If the GMA supports generating the gkaRequest content-type, it MUST be submitted to the KMA (5 in Figure 5) with the gkaAction.addGLMembers CHOICE. The format for the addGLMembers CHOICE is as follows - glName MUST be included to indicate the name of the GL. - glIdentifier MUST be included to indicate the GL the member should be removed from. - glMembers MUST be included to indicate the member(s) to be deleted. The member(s) name(s) is included in GLMember.name. The deliveryMethod MUST be omitted. The member's certificates and crls MUST also be omitted. - glOwner.name MUST be omitted. - effectiveDate MUST be omitted. - distributionDate MUST be omitted. Upon receipt of the gkaRequest content-type, the KMA verifies the gkaRequest content-type and returns a gkaResponse (6 in Figure 5). KMA MUST return a gkaResponse to the GMA indicating success and the glIdentifier of the GL the member was deleted from. GL Policy will determine whether the GL is to be rekeyed. 3.1.1.7 Rekey Group Situations arise where the GL needs a new key (i.e., group rekey). An out of bands means, automatic rekeys by the KMA, or the mechanisms defined below MAY be used to initiate a group rekey. Only the GL Owner or KMA are allowed to initiate a group rekey. +----------+ 4{3} 6{5b} +----------+ 5a | GL Owner | <---+ +-------> | Member 1 | <--+ +----------+ | | +----------+ | 1 | | | +-----+ 2{1} 3,5b +-----+ <----+ | 6{5b} +----------+ 5a | | KMA | <--------> | GMA | ----------------+-------> | ... | <--+ +-----+ +-----+ | +----------+ | | | | | | 6{5b} +----------+ 5a | | +-------> | Member n | <--+ | +----------+ | +-----------------------------------------------------------------+ Figure 6 - Group Rekey The GL Owner MAY generate a gkaRequest content-type and submitted it to the GMA (1 in Figure 6) with the gkaAction.rekeyGL CHOICE. The format for the rekeyGL CHOICE is as follows: - glName MUST be included to indicate the name of the GL. - glIdentifier MUST be included to indicate the GK that should be rekeyed. - glMembers MUST be omitted. - glOwner.name MUST be included to indicate the Owner of the GL. It MUST match the name one of the certificates used to sign this gkaRequest and match one of the names in the certificates used to sign the gkaRequest that created the GL. - effectiveDate MAY be included to indicate the dates the GL Owner wishes the new group key to become effective. If this field is omitted the GMA assumes the gkNotBefore date (see paragraph 3.1.2) is the GMA's current date. - distributionDate MAY be included to indicate the date the GL Owner wishes the key to be distributed. If the distributitionDate is omitted the GMA assumes the group key should be distributed immediately. This date MAY overlap with the existing effectiveDate to ensure prepositioning the new group key before the old group key becomes invalid. The GMA then forwards the gkaRequest content-type to the KMA (2{1} in Figure 3). An additional id-signedData or some other combination of id- signedData and id-envelopedData MAY protect the forwarded content-type. Upon receipt of the gkaRequest content-type, the KMA verifies the gkaRequest content-type and returns a gkaResponse (3 in Figure 3). If the GL can be rekeyed as requested, the KMA MUST return a gkaResponse to the GMA indicating success and the glIdentifier of the new group key. If the group key can not be rekeyed as requested the KMA returns a gkaResponse to the GMA indicating failure along with an errorCode. The GMA then forwards the gkaResponse content-type to the GL Owner (4{3} in Figure 3). An additional id-signedData or some other combination of id-signedData and id-envelopedData MAY protect the forwarded conent- type. The KMA also generates the group rekey MUST distribute the new group through the mechanism described in paragraph 3.3. 3.2 Group Key Distribution The KMA MUST support the initial distribution of the group key. It MAY perform this distribution via an out of bands means, a repository, a mail message, or some other means. The gkDistribution content-type is defined to support electronic means of distributing the group key. If the gkDistribution method is used, it MUST be protected in id- envelopedData [CMS]. The gkDistribution content-type MUST be protected on a per-recipient basis using the ktri RecipientInfo CHOICE. The kari RecipientInfo choice MAY be used to protect the message for members. A further id-signedData MAY also be applied. The KMA MAY send the gkDistribution content-type either: - Directly to each of the members (5a in Figure 6). Note: The following option requires that the KMA be allowed to submit to the GL. - Through the GMA (6b an 6{5b} in Figure 6). If this option is used, the KMA MAY apply an additional id-envelopedData and other layers (6 in Figure 2) to protect the enveloped gkDistribution content-type for the GMA. The GMA then distributes the inner most id-envelopedData to the list based. The GMA MAY also apply a signature to the distributed id- envelopedData. The following object identifier identifies the gksDistribution content type: id-ct-gkDistribution OBJECT IDENTIFIER ::= { TBD } The gkDistribution content type MUST have ASN.1 type GKDistribution: GKDistribution :: = SEQUENCE { version GKDistributionVersion, glIdentifier OCTET STRING, gk OCTET STRING, gkNotBefore GeneralizedTime, gkNotAfter GeneralizedTime } [ST - I think we need to put in some kind of information about the algorithm the key must be used for.] GKDistributionVersion ::= INTEGER { v0(0) } The fields in GKSDistribution have the following meaning: - version is the syntax version number. It MUST be 0. - glIdentifier is the GL identifier. The GL identifier identifies the specific GL on the GMA (the GMA may support multiple GLs). Members use the glIdentifier to choose the key to needed to decrypt an envelopedData with the RecipientInfo.kekri.kekid.keyIdentifer. Two common methods for generating key identifiers from the group key are: (1) The keyIdentifier is composed of the 160-bit SHA-1 hash of the value of the BIT STRING gk (excluding the tag, length, and number of unused bits). (2) The keyIdentifier is composed of a four bit type field with the value 0100 followed by the least significant 60 bits of the SHA-1 hash of the value of the BIT STRING gk. - gk is the group key. - gkNotBefore indicates the date at which the key is considered valid. - gkNotAfter indicates the date at which the key is considered invalid. Members must support processing the id-envelopedData according to [CMS]. 3.3 Group Rekey Distribution To support group rekey messages, three mechanisms are defined: - Use the mechanism described in paragraph 3.1.3 (1a(5a in Figure 5)6) to redistribute the key (i.e., generate a per-recipient token using the ktri or kari RecipientInfoin the id-envelopedData encapsulating the gkDistribution content-type). This may entail significant processing compared with the other options below. Note: The following two options require that the KMA be allowed to submit the GMA. - Generate id-encryptedData with the ktri orRecipientInfo choice kari RecipientInfo choicewith the associated GMA(s) as the recipient(s) (1b(5b in Figure 5)6) encapsulating a id-signedData (signed by the KMA) which in turn encapsualtes an id-envelopedData with the kekri RecipientInfo choice (includes the gkDistribution content-type). The GMA then strips off the two outer layers andthen sends the inner most id- envelopedData to the GL members. The GMA identifies the GL to which the gkDistribution content-type should be submitted to bytheKEKIdentifier.keyIdentifier. The GMA(s) MAY apply a new encapsulating id-signedData. id-signedData. The KMA MAY use the kari RecipientInfo choice to encapsulate the id-signedData (signed by the KMA) which in turn encapsulates an id-envelopedData with the kekru RecipientInfo choice (includes the gkDistribution content-type). - Generate an id-envelopedData (includes the gkDistribution content- type) with the kekri RecipientInfo choice for the GL and submit it to the GMA. The id-envelopedData MAY have other layers (e.g., an id- signedData) applied to it. The GMA identifies the GL to which the gkDistributionthen distributes this content-type should be submitted to by the KEKIdentifier.keyIdentifier.id-envelopedData to the GL. The GMA MAY apply additional layers (e.g., an id-signedData) to the id- envelopedData. In all cases, the KMA MUST assign a new glIdentifier, use a new group key in gk, and a new gkNotBefore and gkNotAfter dates. The old gkNotAfter and new gkNotBefore MUST overlap by some configurable time, T. T allows for the time required to distribute the new group key to each of the GL members. If T is less than 0, then GL members may be unable to use the group key to encrypt messages. [The above case is only for entirely new keys to be distributed. Need to add something in here about how to indicate that a new key, which is derived from the old key, should be used.] 4 Key Wrapping In the mechanisms described in paragraphs 3.2 and 3.3, the group key being distributed, in an id-envelopedData, MUST be protected by a key of equal or greater length (i.e., if a RC2 128-bit key is being distributed a key of 128-bits or greater must be used to protect the key). 5 Algorithms Triple-DES is mandatory other are optional. 6. Using the Group Key [Put in here how this can be used with SMIME MLAs.] 7. Schema Requirements [I think we need to specify some MAYs for support of object classes, etc. to support location of the GL and GL Owner in a repository. There are really two choices for the GL mhsDistributionList from RFC 1274 and addresslist from an Internet-Draft in the LDAPEXT WG. The only reason I can think of not using the one from RFC 1274 is that a MUST CONTAIN is mhsORAddress and we're should support SMTP. addressList (in the ID) doesn't have mhsORAddress as a must contain. The Owner in the both object classes though has the syntax directoryName. We might have to roll attribute for the Owner because I think it should probably have the GeneralName syntax instead of just directoryName.] [We can also define attributes that can be used to store the group key encrypted for an individual group member and for the encrypted object. Does anyone think this is useful/needed?] 8. Acknowledgements Thanks to Russ Housley for providing much of the background and review required to write this draft. 9. References [CMS] R. Housley, "Cryptographic Message Syntax," RFC 2630, June 1999. [ESS] P. Hoffman, "Enhanced Security Services for S/MIME," RFC 2534, June 1999. [PROFILE] Housley, R., Ford, W., Polk, W., and Solo, D., "Internet X.509 Public Key Infrastructure Certificate and CRL Profile," RFC 2459, January 1999. 10. Security Considerations TBSL [ Need to talk about the consequences of a compromised group KEK. ] 11. Patents I don't hold any (on this or any other topic) does anyone know of any? 12. Editor's Address Sean Turner IECA, Inc. 9010 Edgepark Road Vienna, VA 22182 Phone: (703) 628-3180 E-Mail: turners@ieca.com Annex A - ASN.1 Module TBSL