SMIME Working Group S. Turner
INTERNET DRAFT IECA
Expires in on 20 June, 2000 December 20, 1999
S/MIME Symmetric Key Distribution
<draft-ietf-smime-symkeydist-00.txt>
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 <http://www.imc.org/ietf-smime/>.
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
Datatracker
Report a datatracker bug
draft-ietf-smime-symkeydist-00
Internet-Draft
| Document | Document type |
This is an older version of an Internet-Draft that was ultimately published as RFC 5275.
Expired & archived
|
|
|---|---|---|---|
| Select version | |||
| Compare versions | |||
| Author | |||
| RFC stream |
|
||
| Other formats | |||
| Additional resources | Mailing list discussion |