Tech-invite  3GPPspecsRELsGlossariesSIPRFCs
8887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100

in Index   Prev   Next

RFC 5275

CMS Symmetric Key Management and Distribution

Pages: 89
Proposed Standard
Errata
Part 5 of 5 – Pages 79 to 89
First   Prev   None

Top   ToC   RFC5275 - Page 79   prevText

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].
Top   ToC   RFC5275 - Page 80

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.
Top   ToC   RFC5275 - Page 81
   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.
Top   ToC   RFC5275 - Page 82
   [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.
Top   ToC   RFC5275 - Page 83

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) };
Top   ToC   RFC5275 - Page 84
   -- 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 }
Top   ToC   RFC5275 - Page 85
   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 }
Top   ToC   RFC5275 - Page 86
   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) }
Top   ToC   RFC5275 - Page 87
   -- 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) }
Top   ToC   RFC5275 - Page 88
   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
Top   ToC   RFC5275 - Page 89
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.