6.  Algorithms

   This section lists the algorithms that MUST be implemented.
   Additional algorithms that SHOULD be implemented are also included.
   Further algorithms MAY also be implemented.

6.1.  KEK Generation Algorithm

   Implementations MUST randomly generate content-encryption keys,
   message-authentication keys, initialization vectors (IVs), and
   padding.  Also, the generation of public/private key pairs relies on
   a random numbers.  The use of inadequate pseudo-random number
   generators (PRNGs) to generate cryptographic keys can result in
   little or no security.  An attacker may find it much easier to
   reproduce the PRNG environment that produced the keys, searching the
   resulting small set of possibilities, rather than brute force
   searching the whole key space.  The generation of quality random
   numbers is difficult.  RFC 4086 [RANDOM] offers important guidance in
   this area, and Appendix 3 of FIPS Pub 186 [FIPS] provides one quality
   PRNG technique.

6.2.  Shared KEK Wrap Algorithm

   In the mechanisms described in Section 5, the shared KEK being
   distributed in glkWrapped MUST be protected by a key of equal or
   greater length (e.g., if an AES 128-bit key is being distributed, a
   key of 128 bits or greater must be used to protect the key).

   The algorithm object identifiers included in glkWrapped are as
   specified in [CMSALG] and [CMSAES].

6.3.  Shared KEK Algorithm

   The shared KEK distributed and indicated in glkAlgorithm MUST support
   the symmetric key-encryption algorithms as specified in [CMSALG] and
   [CMSAES].

7.  Message Transport

   SMTP [SMTP] MUST be supported.  Other transport mechanisms MAY also
   be supported.

8.  Security Considerations

   As GLOs control setting up and tearing down the GL and rekeying the
   GL, and can control member additions and deletions, GLOs play an
   important role in the management of the GL, and only "trusted" GLOs
   should be used.

   If a member is deleted or removed from a closed or a managed GL, the
   GL needs to be rekeyed.  If the GL is not rekeyed after a member is
   removed or deleted, the member still possesses the group key and will
   be able to continue to decrypt any messages that can be obtained.

   Members who store KEKs MUST associate the name of the GLA that
   distributed the key so that the members can make sure subsequent
   rekeys are originated from the same entity.

   When generating keys, care should be taken to ensure that the key
   size is not too small and duration too long because attackers will
   have more time to attack the key.  Key size should be selected to
   adequately protect sensitive business communications.

   GLOs and GLAs need to make sure that the generationCounter and
   duration are not too large.  For example, if the GLO indicates that
   the generationCounter is 14 and the duration is one year, then 14
   keys are generated each with a validity period of a year.  An
   attacker will have at least 13 years to attack the final key.

   Assume that two or more parties have a shared KEK, and the shared KEK
   is used to encrypt a second KEK for confidential distribution to
   those parties.  The second KEK might be used to encrypt a third KEK,
   the third KEK might be used to encrypt a fourth KEK, and so on.  If
   any of the KEKs in such a chain is compromised, all of the subsequent
   KEKs in the chain MUST also be considered compromised.

   An attacker can attack the group's shared KEK by attacking one
   member's copy of the shared KEK or attacking multiple members' copies
   of the shared KEK.  For the attacker, it may be easier to either
   attack the group member with the weakest security protecting its copy
   of the shared KEK or attack multiple group members.

   An aggregation of the information gathered during the attack(s) may
   lead to the compromise of the group's shared KEK.  Mechanisms to
   protect the shared KEK should be commensurate with value of the data
   being protected.

   The nonce and signingTime attributes are used to protect against
   replay attacks.  However, these provisions are only helpful if
   entities maintain state information about the messages they have sent
   or received for comparison.  If sufficient information is not
   maintained on each exchange, nonces and signingTime are not helpful.
   Local policy determines the amount and duration of state information
   that is maintained.  Additionally, without a unified time source,
   there is the possibility of clocks drifting.  Local policy determines
   the acceptable difference between the local time and signingTime,
   which must compensate for unsynchronized clocks.  Implementations
   MUST handle messages with siginingTime attributes that indicate they
   were created in the future.

9. Acknowledgements

   Thanks to Russ Housley and Jim Schaad for providing much of the
   background and review required to write this document.

10.  References

10.1.  Normative References

   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, March 1997.

   [CMS]        Housley, R., "Cryptographic Message Syntax (CMS)", RFC
                3852, July 2004.

   [CMC]        Schaad, J. and M. Myers, "Certificate Management over
                CMS (CMC)", RFC 5272, June 2008.

   [PROFILE]    Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
                Housley, R., and W. Polk, "Internet X.509 Public Key
                Infrastructure Certificate and Certificate Revocation
                List (CRL) Profile", RFC 5280, May 2008.

   [ACPROF]     Farrell, S. and R. Housley, "An Internet Attribute
                Certificate Profile for Authorization", RFC 3281, April
                2002.

   [MSG]        Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail
                Extensions (S/MIME) Version 3.1 Message Specification",
                RFC 3851, July 2004.

   [ESS]        Hoffman, P., Ed., "Enhanced Security Services for
                S/MIME", RFC 2634, June 1999.

   [CMSALG]     Housley, R., "Cryptographic Message Syntax (CMS)
                Algorithms", RFC 3370, August 2002.

   [CMSAES]     Schaad, J., "Use of the Advanced Encryption Standard
                (AES) Encryption Algorithm in Cryptographic Message
                Syntax (CMS)", RFC 3565, July 2003.

   [SMTP]       Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC
                2821, April 2001.

10.2.  Informative References

   [X400TRANS]  Hoffman, P. and C. Bonatti, "Transporting
                Secure/Multipurpose Internet Mail Extensions (S/MIME)
                Objects in X.400", RFC 3855, July 2004.

   [RANDOM]     Eastlake, D., 3rd, Schiller, J., and S. Crocker,
                "Randomness Requirements for Security", BCP 106, RFC
                4086, June 2005.

   [FIPS]       National Institute of Standards and Technology, FIPS Pub
                186-2: Digital Signature Standard, January 2000.

Appendix A.  ASN.1 Module

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

   DEFINITIONS IMPLICIT TAGS ::=
   BEGIN

   -- EXPORTS All --
   -- The types and values defined in this module are exported for use
   -- in the other ASN.1 modules.  Other applications may use them for
   -- their own purposes.

   IMPORTS

   -- PKIX Part 1 - Implicit [PROFILE]
      GeneralName
        FROM PKIX1Implicit88 { iso(1) identified-organization(3) dod(6)
             internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
             id-pkix1-implicit(19) }

   -- PKIX Part 1 - Explicit [PROFILE]
      AlgorithmIdentifier, Certificate
        FROM PKIX1Explicit88 { iso(1) identified-organization(3) dod(6)
             internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
             id-pkix1-explicit(18) }

   -- Cryptographic Message Syntax [CMS]
      RecipientInfos, KEKIdentifier, CertificateSet
        FROM CryptographicMessageSyntax2004 {iso(1) member-body(2)
          us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0)
          cms-2004(24) }

   -- Advanced Encryption Standard (AES) with CMS [CMSAES]
      id-aes128-wrap
        FROM CMSAesRsaesOaep { iso(1) member-body(2) us(840)
          rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0)
          id-mod-cms-aes(19) }

   -- Attribute Certificate Profile [ACPROF]
      AttributeCertificate FROM
         PKIXAttributeCertificate { iso(1) identified-organization(3)
         dod(6) internet(1) security(5) mechanisms(5) pkix(7)
         id-mod(0) id-mod-attribute-cert(12) };

   -- This defines the GL symmetric key distribution object identifier
   -- arc.

   id-skd OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
     rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) skd(8) }

   -- This defines the GL Use KEK control attribute.

   id-skd-glUseKEK OBJECT IDENTIFIER ::= { id-skd 1 }

   GLUseKEK ::= SEQUENCE {
     glInfo                GLInfo,
     glOwnerInfo           SEQUENCE SIZE (1..MAX) OF GLOwnerInfo,
     glAdministration      GLAdministration DEFAULT 1,
     glKeyAttributes       GLKeyAttributes OPTIONAL }

   GLInfo ::= SEQUENCE {
     glName     GeneralName,
     glAddress  GeneralName }

   GLOwnerInfo ::= SEQUENCE {
     glOwnerName     GeneralName,
     glOwnerAddress  GeneralName,
     certificates    Certificates OPTIONAL }

   GLAdministration ::= INTEGER {
     unmanaged  (0),
     managed    (1),
     closed     (2) }

   GLKeyAttributes ::= SEQUENCE {
     rekeyControlledByGLO       [0] BOOLEAN DEFAULT FALSE,
     recipientsNotMutuallyAware [1] BOOLEAN DEFAULT TRUE,
     duration                   [2] INTEGER DEFAULT 0,
     generationCounter          [3] INTEGER DEFAULT 2,
     requestedAlgorithm         [4] AlgorithmIdentifier
                                 DEFAULT { id-aes128-wrap } }

   -- This defines the Delete GL control attribute.
   -- It has the simple type GeneralName.

   id-skd-glDelete OBJECT IDENTIFIER ::= { id-skd 2 }

   DeleteGL ::= GeneralName

   -- This defines the Add GL Member control attribute.

   id-skd-glAddMember OBJECT IDENTIFIER ::= { id-skd 3 }

   GLAddMember ::= SEQUENCE {
     glName    GeneralName,
     glMember  GLMember }

   GLMember ::= SEQUENCE {
     glMemberName     GeneralName,
     glMemberAddress  GeneralName OPTIONAL,
     certificates     Certificates OPTIONAL }

   Certificates ::= SEQUENCE {
      pKC                [0] Certificate OPTIONAL,
                                  -- See [PROFILE]
      aC                 [1] SEQUENCE SIZE (1.. MAX) OF
                             AttributeCertificate OPTIONAL,
                                  -- See [ACPROF]
      certPath           [2] CertificateSet OPTIONAL }
                                  -- From [CMS]

   -- This defines the Delete GL Member control attribute.

   id-skd-glDeleteMember OBJECT IDENTIFIER ::= { id-skd 4 }

   GLDeleteMember ::= SEQUENCE {
     glName            GeneralName,
     glMemberToDelete  GeneralName }

   -- This defines the Delete GL Member control attribute.

   id-skd-glRekey OBJECT IDENTIFIER ::= { id-skd 5 }

   GLRekey ::= SEQUENCE {
     glName              GeneralName,
     glAdministration    GLAdministration OPTIONAL,
     glNewKeyAttributes  GLNewKeyAttributes OPTIONAL,
     glRekeyAllGLKeys    BOOLEAN OPTIONAL }

   GLNewKeyAttributes ::= SEQUENCE {
     rekeyControlledByGLO       [0] BOOLEAN OPTIONAL,
     recipientsNotMutuallyAware [1] BOOLEAN OPTIONAL,
     duration                   [2] INTEGER OPTIONAL,
     generationCounter          [3] INTEGER OPTIONAL,
     requestedAlgorithm         [4] AlgorithmIdentifier OPTIONAL }

   -- This defines the Add and Delete GL Owner control attributes.

   id-skd-glAddOwner OBJECT IDENTIFIER ::= { id-skd 6 }
   id-skd-glRemoveOwner OBJECT IDENTIFIER ::= { id-skd 7 }

   GLOwnerAdministration ::= SEQUENCE {
     glName       GeneralName,
     glOwnerInfo  GLOwnerInfo }

   -- This defines the GL Key Compromise control attribute.
   -- It has the simple type GeneralName.

   id-skd-glKeyCompromise OBJECT IDENTIFIER ::= { id-skd 8 }

   GLKCompromise ::= GeneralName

   -- This defines the GL Key Refresh control attribute.

   id-skd-glkRefresh OBJECT IDENTIFIER ::= { id-skd 9 }

   GLKRefresh ::= SEQUENCE {
      glName  GeneralName,
      dates   SEQUENCE SIZE (1..MAX) OF Date }

   Date ::= SEQUENCE {
     start GeneralizedTime,
     end   GeneralizedTime OPTIONAL }

   -- This defines the GLA Query Request control attribute.

   id-skd-glaQueryRequest OBJECT IDENTIFIER ::= { id-skd 11 }

   GLAQueryRequest ::= SEQUENCE {
     glaRequestType   OBJECT IDENTIFIER,
     glaRequestValue  ANY DEFINED BY glaRequestType }


   -- This defines the GLA Query Response control attribute.

   id-skd-glaQueryResponse OBJECT IDENTIFIER ::= { id-skd 12 }

   GLAQueryResponse ::= SEQUENCE {
     glaResponseType   OBJECT IDENTIFIER,
     glaResponseValue  ANY DEFINED BY glaResponseType }

   -- This defines the GLA Request/Response (glaRR) arc for
   -- glaRequestType/glaResponseType.

   id-cmc-glaRR OBJECT IDENTIFIER ::= { iso(1)
     identified-organization(3) dod(6) internet(1) security(5)
     mechanisms(5) pkix(7) cmc(7) glaRR(99) }

   -- This defines the Algorithm Request.

   id-cmc-gla-skdAlgRequest OBJECT IDENTIFIER ::= { id-cmc-glaRR 1 }

   SKDAlgRequest ::= NULL

   -- This defines the Algorithm Response.

   id-cmc-gla-skdAlgResponse OBJECT IDENTIFIER ::= { id-cmc-glaRR 2 }

   -- Note that the response for algorithmSupported request is the
   -- smimeCapabilities attribute as defined in MsgSpec [MSG].
   -- This defines the control attribute to request an updated
   -- certificate to the GLA.

   id-skd-glProvideCert OBJECT IDENTIFIER ::= { id-skd 13 }

   GLManageCert ::= SEQUENCE {
     glName    GeneralName,
     glMember  GLMember }

   -- This defines the control attribute to return an updated
   -- certificate to the GLA.  It has the type GLManageCert.

   id-skd-glManageCert OBJECT IDENTIFIER ::= { id-skd 14 }

   -- This defines the control attribute to distribute the GL shared
   -- KEK.

   id-skd-glKey OBJECT IDENTIFIER ::= { id-skd 15 }

   GLKey ::= SEQUENCE {
     glName        GeneralName,
     glIdentifier  KEKIdentifier,  -- See [CMS]
     glkWrapped    RecipientInfos,      -- See [CMS]
     glkAlgorithm  AlgorithmIdentifier,
     glkNotBefore  GeneralizedTime,
     glkNotAfter   GeneralizedTime }

   -- This defines the CMC error types.

   id-cet-skdFailInfo  OBJECT IDENTIFIER ::= { iso(1)
     identified-organization(3) dod(6) internet(1) security(5)
     mechanisms(5) pkix(7) cet(15) skdFailInfo(1) }

   SKDFailInfo ::= INTEGER {
     unspecified           (0),
     closedGL              (1),
     unsupportedDuration   (2),
     noGLACertificate      (3),
     invalidCert           (4),
     unsupportedAlgorithm  (5),
     noGLONameMatch        (6),
     invalidGLName         (7),
     nameAlreadyInUse      (8),
     noSpam                (9),
   -- obsolete             (10),
     alreadyAMember        (11),
     notAMember            (12),
     alreadyAnOwner        (13),
     notAnOwner            (14) }

   END -- SMIMESymmetricKeyDistribution

Author's Address

   Sean Turner
   IECA, Inc.
   3057 Nutley Street, Suite 106
   Fairfax, VA 22031
   USA

   EMail: turners@ieca.com

Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.