L. Martin S/MIME Working Group Voltage Security Internet Draft Mark Schertler Intended status: Standards Track Tumbleweed Communications Expires: December 2008 June 2008 Using the Boneh-Franklin and Boneh-Boyen Identity-based Encryption Algorithms with the Cryptographic Message Syntax (CMS) Status of this Document By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 six months and may be updated, replaced, or obsoleted 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 Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract This document describes the conventions for using the Boneh- Franklin (BF) and Boneh-Boyen (BB1) identity-based encryption algorithms in the Cryptographic Message Syntax (CMS) to encrypt content-encryption keys. Object identifiers and the convention for encoding a recipient's identity are also defined. Martin, Schertler Expires December 2008 [Page 1] Internet-Draft Using IBE with CMS June 2008 Table of Contents 1. Introduction............................................2 1.1. Terminology........................................3 1.2. IBE overview.......................................3 2. Using identity-based encryption.........................4 3. Key encryption algorithm identifiers....................8 4. Processing by the sender................................8 5. Processing by the receiver..............................9 6. ASN.1 module............................................9 7. Security considerations................................11 7.1. Attacks that are outside the scope of this document...............................................11 7.2. Attacks that are within the scope of this document...............................................12 7.3. Attacks to which the protocols defined in this document are susceptible...............................12 8. IANA considerations....................................13 9. References.............................................14 9.1. Normative references..............................14 9.2. Informative references............................14 Authors' Addresses........................................15 Intellectual property statement...........................15 Disclaimer of validity....................................16 Copyright statement.......................................16 Acknowledgment............................................16 1. Introduction This document defines the way to use the Boneh-Franklin [IBCS] and Boneh-Boyen [IBCS] identity-based encryption (IBE) public-key algorithms in the Cryptographic Message Syntax (CMS) [CMS]. IBE is a public key technology for encrypting content-encryption keys (CEKs) that can be implemented within the framework of the CMS: the recipient's identity is incorporated into the EnvelopedData CMS content type using the OtherRecipientInfo CHOICE in the RecipientInfo field as defined in section 6.2.5 of [CMS]. This document does not describe the implementation of the BF and BB1 algorithms, which are described in detail in [IBCS]. IBE algorithms are a type of public-key cryptographic algorithm in which the public key is calculated directly from a user's identity instead of being generated randomly. This requires a different set of steps for encryption and decryption than would be used with other public-key Martin, Schertler Expires December 2008 [Page 2] Internet-Draft Using IBE with CMS June 2008 algorithms, and these steps are defined in Sections 4 and 5 of this document respectively. This document also defines the object identifiers and syntax of the object that is used to define the identity of a message recipient. CMS values and identity objects are defined using ASN.1 [ASN1]. 1.1. Terminology 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 RFC 2119 [KEYWORDS]. 1.2. IBE overview In addition to the client components that are described in this document, the following additional components are required for a complete IBE messaging system. o A Private-key Generator (PKG). The PKG contains the cryptographic material, known as a master secret, for generating an individual's IBE private key. A PKG accepts an IBE user's private key request and, after successfully authenticating them in some way, returns their IBE private key. o A Public Parameter Server (PPS). IBE System Parameters include publicly sharable cryptographic material, known as IBE public parameters, and policy information for the PKG. A PPS provides a well-known location for distribution of IBE public parameters and policy information for the IBE PKG. The interaction of senders and receivers of IBE-encrypted messages are described in [IBE]. All communications between users of an IBE system and the PPS or PKG MUST be protected using TLS [TLS] as described in [IBE]. This provides confidentiality and integrity of all information that is delivered to users as well as authentication of the PPS and PKG. Martin, Schertler Expires December 2008 [Page 3] Internet-Draft Using IBE with CMS June 2008 2. Using identity-based encryption To use IBE, the ori field in RecipientInfo MUST be used. The fields are set as follows: oriType is set to ibeORIType; oriValue is set to ibeORIValue. These fields have the following meanings: ibeORIType defines the object identifier (OID) that indicates that the subsequent ibeORIValue is the information necessary to decrypt the message using IBE. This field MUST be set to the following: ibeORIType OBJECT IDENTIFIER ::= { joint-iso-itu(2) country(16) us(840) organization(1) identicrypt(114334) ibcs(1) cms(4) ori-oid(1) } ibeORIValue defines the identity that was used in the IBE algorithm to encrypt the CEK. This is an IBERecipientInfo type, which is defined as follows: IBERecipientInfo ::= SEQUENCE { cmsVersion INTEGER { v3(3) }, keyFetchMethod OBJECT IDENTIFIER, recipientIdentity IBEIdentityInfo, serverInfo SEQUENCE SIZE (1..MAX) OF OIDValuePairs OPTIONAL, encryptedKey EncryptedKey } The fields of IBERecipientInfo MUST be set as follows. The cmsVersion MUST be set to 3. The keyFetchMethod is the OID that defines the method of retrieving the private key that the recipient MUST use. How to retrieve an IBE private key using the steps defined in [IBE] is defined by the keyFetchMethod OID. The method for retrieving private keys that is specified in [IBE] is defined by cmsPPSOID, which is defined to be the following: Martin, Schertler Expires December 2008 [Page 4] Internet-Draft Using IBE with CMS June 2008 cmsPPSOID OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) identicrypt(114334) pps-schemas(3) ic-schemas(1) pps-uri(1) } The recipientIdentity is the data that was used to calculate the IBE public key that was used to encrypt the content- encryption key. This recipientIdentity is used to calculate IBE public and private keys as described in [IBCS]. This MUST be an IBEIdentityInfo type, which is defined as follows: IBEIdentityInfo ::= SEQUENCE { district IA5String, serial INTEGER, identitySchema OBJECT IDENTIFIER, identityData OCTET STRING } The fields of IBEIdentityInfo have the following meanings. The district and serial are unique identifiers that are used to construct the URI for the location of the necessary IBE public parameters. The construction and use of this URI is defined in [IBE]. Internationalized Resource Identifiers (IRIs) MUST be handled according to the procedures specified in Section 7.4 of [PKIX]. The identitySchema defines the format that is used to encode the information that defines the identity of the recipient. This MUST be set to cmsIdentityOID to indicate that identityData contains an EmailIdentitySchema type. The value of cmsIdentityOID is the following: cmsIdentityOID OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) identicrypt(114334) keyschemas(2) icschemas(1) rfc822Name(1) } The identityData field contains the identify information for the recipient, the contents of which is an ASN.1 structure which MUST be DER encoded [DER] before placing it in the OCTET STRING. Martin, Schertler Expires December 2008 [Page 5] Internet-Draft Using IBE with CMS June 2008 If identitySchema is set to the cmsIdentityOID OBJECT IDENTIFIER, the identityData MUST be an EmailIdentitySchema type, which is defined as follows: EmailIdentitySchema ::= SEQUENCE { rfc822Name IA5String, time GeneralizedTime } The rfc822Name field is the e-mail address of the recipient in the format defined in Section 4.2.1.6 of [PKIX] for the rfc822Name subjectAltName variant. Rules for encoding Internet mail addresses that include internationalized domain names are specified in Section 7.5 of [PKIX]. The value of the time field is the UTC time after which the sender wants to let the recipient decrypt the message, so it may be called the "not-before" time. This is usually set to the time when the message is encrypted, but MAY be set to a future time. The value of "time" MUST be expressed in Greenwich Mean Time(Zulu), MUST include seconds (i.e. times are always YYYYMMDDHHMMSSZ), even where the number of seconds is equal to zero and MUST be expressed to the nearest second. The sender of an IBE-encrypted message may want to express this time rounded to a time interval to create a key lifetime. A key lifetime reduces the number of IBE private keys that a recipient needs to retrieve, but still forces the IBE user to periodically re-authenticate. Based on the time interval chosen a recipient would only have to retrieve a new IBE key once during the interval. To do this, follow the following steps. Let "time-interval" be the number of seconds in this larger time interval. 1. Find the GeneralizedTime for the not-before value. 2. Convert this GeneralizedTime into the number of seconds since January 1, 1970. Call this "total-time." 3. Calculate reduced-time = (floor (total-time / time-interval)) * time-interval. 4. Convert reduced-time to a GeneralizedTime to get the not-before "time" value. An example of this algorithm for computing a one week time interval is as follows. Martin, Schertler Expires December 2008 [Page 6] Internet-Draft Using IBE with CMS June 2008 1. Suppose that the GeneralizedTime is 20020401000000Z. 2. Then the total-time is 1017612000. 3. A time-interval of 1 week is 604800 seconds. So the reduced-time = (floor(1017612000/604800)) * 604800 = 1017273600. 4. This gives the GeneralizedTime form of the reduced-time of 20020328000000Z. When issuing IBE private keys, a PKG SHOULD NOT issue them too far into the future. This restriction is to prevent an adversary who obtains an IBE user's authentication credentials from requesting private keys far into the future and therefore negating the periodic IBE user re- authentication that key lifetime provides. For example if a one week period is chosen for the key lifetime, then IBE private keys should not be issued more than 1 week in advance. Otherwise once an adversary gains access to the PKG via the stolen IBE user credentials they can request all future keys and negate the IBE user authentication restraints in place. The serverInfo is an optional sequence of OID-value pairs that are defined to be the following: OIDValuePairs ::= SEQUENCE { fieldID OBJECT IDENTIFIER, fieldData OCTET STRING } These can be used to convey any other information that might be used by a PKG. Examples of such information could include the user interface that the recipient will experience. Differences in the user interface could include localization information or commercial branding information. OIDValuePairs ::= SEQUENCE { fieldID OBJECT IDENTIFIER, fieldData OCTET STRING } The encryptedKey is the result of encrypting the CEK with an IBE algorithm using recipientIdentity as the IBE public key. Martin, Schertler Expires December 2008 [Page 7] Internet-Draft Using IBE with CMS June 2008 3. Key encryption algorithm identifiers The BF and BB1 algorithms as defined in [IBCS] have the following object identifiers. These object identifiers are also defined in the ASN.1 module in [IBCS]. bf OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) identicrypt(114334) ibcs(1) ibcs1(1) ibe-algorithms(2) bf(1) } This is the object identifier that MUST be inserted in the keyEncryptionAlgorithm field in the CMS when the BF algorithm is used to encrypt the CEK. bb1 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) identicrypt(114334) ibcs(1) ibcs1(1) ibe-algorithms(2) bb1(2) } This is the object identifier that MUST be inserted in the keyEncryptionAlgorithm field in the CMS when the BB1 algorithm is used to encrypt the CEK. 4. Processing by the sender The sender of a message that uses IBE to encrypt content- encryption keys performs the following steps: 1. Selects a set of IBE public parameters to use in the subsequent steps in accordance with his local security policy. He then determines the URI where the public parameters can be obtained using the process described in [IBE]. This information MUST be encoded in the IBEIdentityInfo as described in Section 2. 2. Sets the fields of an OtherRecipientInfo object to their appropriate values as described in Section 2. 3. Calculates an IBE public key as defined in [IBCS] using this IBEIdentityInfo as the identity information. 4. This IBE public key is then used to encrypt the content-encryption key (CEK), using the algorithms that are defined in [IBCS]. Martin, Schertler Expires December 2008 [Page 8] Internet-Draft Using IBE with CMS June 2008 5. Sets encryptedKey to the IBE-encrypted CEK. 6. Within the CMS, keyEncryptionAlgorithm MUST then be set to the appropriate OID for the IBE algorithm that was used (see Section 3). 5. Processing by the receiver Upon receiving a message that has a CEK encrypted with IBE, the recipient performs the following steps to decrypt the CEK: 1. Determines that the CEK is IBE-encrypted by noting that the oriType of the OtherRecipientInfo type is set to ibeORIType. 2. Determines that the recipientIdentity was used as the identity in IBE encryption of the CEK. 3. Determines the location of the IBE public parameters and the IBE Private Key Generator as described in [IBE]. 4. Obtains the IBE public parameters from the location determined in Step 3 using the process defined in [IBE]. 5. Obtains the IBE private key needed to decrypt the encrypted CEK using the process defined in [IBE]. 6. Decrypts the CEK using the IBE private key obtained in Step 4 using the algorithms described in [IBCS]. 6. ASN.1 module The following ASN.1 module summarizes the ASN.1 definitions discussed in this document. Martin, Schertler Expires December 2008 [Page 9] Internet-Draft Using IBE with CMS June 2008 IBECMS-module { joint-iso-itu-t(2) country(16) us(840) organization(1) identicrypt(114334) ibcs(1) cms(4) module(5) version(1) } DEFINITIONS IMPLICIT TAGS ::= BEGIN IBEOtherRecipientInfo ::= SEQUENCE { oriType OBJECT IDENTIFIER, oriValue IBERecipientInfo } ibeORIType OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) identicrypt(114334) ibcs(1) cms(4) ori-oid(1) } IBERecipientInfo ::= SEQUENCE { cmsVersion INTEGER { v3(3) }, keyFetchMethod OBJECT IDENTIFIER, recipientIdentity IBEIdentityInfo, serverInfo SEQUENCE SIZE (1..MAX) OF OIDValuePairs OPTIONAL, encryptedKey EncryptedKey } IBEIdentityInfo ::= SEQUENCE { district IA5String, serial INTEGER, identitySchema OBJECT IDENTIFIER, identityData OCTET STRING } OIDValuePairs ::= SEQUENCE { fieldID OBJECT IDENTIFIER, fieldData OCTET STRING } EncryptedKey ::= OCTET STRING EmailIdentitySchema ::= SEQUENCE { rfc822Name IA5String, time GeneralizedTime } Martin, Schertler Expires December 2008 [Page 10] Internet-Draft Using IBE with CMS June 2008 cmsIdentityOID OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) identicrypt(114334) keyschemas(2) icschemas(1) RFC2821email(1) } cmsPPSOID OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) identicrypt(114334) pps-schemas(3) ic-schemas(1) pps-uri(1) } END 7. Security considerations This document is based on [CMS] and [IBCS], and the relevant security considerations of those documents apply. 7.1. Attacks that are outside the scope of this document Attacks on the cryptographic algorithms that are used to implement IBE are outside the scope of this document. Such attacks are detailed in [IBCS], which defines parameters that give 80-bit, 112-bit, 128-bit and 256-bit encryption strength. We assume that capable administrators of an IBE system will select parameters that provide a sufficient resistance to cryptanalytic attacks by adversaries. Attacks that give an adversary the ability to access or change the information on a PPS or PKG, especially the cryptographic material (referred to in this document as the master secret), will defeat the security of an IBE system. In particular, if the cryptographic material is compromised the adversary will have the ability to recreate any user's private key and therefore decrypt all messages protected with the corresponding public key. To address this concern, it is highly RECOMMENDED that best practices for physical and operational security for PPS and PKG servers be followed and that these servers be configured (sometimes known as hardened) in accordance with best current practices [NIST]. An IBE system SHOULD be operated in an environment where illicit access to the PKG or the ability to modify the information distributed by the PPS is infeasible for attackers to obtain. Martin, Schertler Expires December 2008 [Page 11] Internet-Draft Using IBE with CMS June 2008 Attacks that require administrative or IBE user equivalent access to machines used by either the client or the server components defined in this document are also outside the scope of this document. We also assume that all administrators of a system implementing the protocols that are defined in this document are trustworthy and will not abuse their authority to bypass the security provided by an IBE system. This is of particular importance with an IBE system, for an administrator of a PKG could potentially abuse his authority and configure the PKG to grant him any IBE private key that the PKG is capable of calculating. To minimize the possibility of administrators doing this, a system implementing IBE SHOULD implement n-out-of-m control for critical administrative functions and SHOULD maintain auditable logs of all security-critical events that occur in an operating IBE system. Similarly, we assume that users of an IBE system will behave responsibly, not sharing their authentication credentials with others. Thus attacks that require such assumptions are outside the scope of this document. 7.2. Attacks that are within the scope of this document Attacks within the scope of this document are those that allow an adversary to: o passively monitor information transmitted between users of an IBE system and the PPS and PKG o masquerade as a PPS or PKG o perform a DOS attack on a PPS or PKG o easily guess an IBE user's authentication credential 7.3. Attacks to which the protocols defined in this document are susceptible All communications between users of an IBE system and the PPS or PKG are protected using TLS [TLS]. The IBE system defined in this document provides no additional security for the communications between IBE users and the PPS or PKG. Therefore the described IBE system is completely dependent Martin, Schertler Expires December 2008 [Page 12] Internet-Draft Using IBE with CMS June 2008 on the TLS security mechanisms for authentication of the PKG or PPS server and for confidentiality and integrity of the communications. Should there be a compromise of the TLS security mechanisms, the integrity of all communications between an IBE user and the PPS or PKG will be suspect. The protocols defined in this document do not explicitly defend against an attacker masquerading as a legitimate IBE PPS or PKG. The protocols rely on the server authentication mechanism of TLS [TLS]. In addition to the TLS server authentication mechanism IBE client software can provide protection against this possibility by providing user interface capabilities that allows users to visually determine that a connection to PPS and PKG servers is legitimate. This additional capability can help ensure that users cannot easily be tricked into providing valid authorization credentials to an attacker. The protocols defined in this document are also vulnerable to attacks against an IBE PPS or PKG. Denial of service attacks against either component can result in users unable to encrypt or decrypt using IBE, and users of an IBE system SHOULD take the appropriate countermeasures [DOS, BGPDOS] that their use of IBE requires. The IBE user authentication method used by an IBE PKG SHOULD be of sufficient strength to prevent attackers from easily guessing the IBE user's authentication credentials through trial and error. 8. IANA considerations No further action by the IANA is necessary for this document. Martin, Schertler Expires December 2008 [Page 13] Internet-Draft Using IBE with CMS June 2008 9. References 9.1. Normative references [ASN1] ITU-T Recommendation X.680: Information Technology - Abstract Syntax Notation One (ASN.1): Specification of Basic Notation," July 2002. [CMS] R. Housley, "Cryptographic Message Syntax," RFC 3852, July 2004. [DER] ITU-T Recommendation X.690: OSI Networking and System Aspects: Abstract Syntax Notation One (ASN.1), July 2002. [DOS] P. Ferguson and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing," RFC 2827, BCP 38, May 2000. [IBCS] X. Boyen and L. Martin, "Identity-based Cryptography Standard (IBCS) #1: Supersingular Curve Implementations of the BF and BB1 Cryptosystems," RFC 5091, December 2007. [IBE] G. Appenzeller, L. Martin and M. Schertler, "Identity- based Encryption Architecture," draft-ietf-smime- ibearch-06.txt. [KEYWORDS] S. Brander, "Key Words for Use in RFCs to Indicate Requirement Levels," BCP 14, RFC 2119, March 1997. [PKIX] D. Cooper, et al., "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile," RFC 5280, May 2008. [TLS] T. Dierks and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1," RFC 4346, April 2006. 9.2. Informative references [BGPDOS] D. Turk, "Configuring BGP to Block Denial-of- Service Attacks," RFC 3882, September 2004. Martin, Schertler Expires December 2008 [Page 14] Internet-Draft Using IBE with CMS June 2008 [NIST] M. Souppaya, J. Wack and K. Kent, "Security Configuration Checklist Program for IT Products - Guidance for Checklist Users and Developers," NIST Special Publication SP 800-70, May 2005. Authors' Addresses Luther Martin Voltage Security 1070 Arastradero Rd Suite 100 Palo Alto CA 94304 USA Phone: +1 650 543 1280 Email: martin@voltage.com Mark Schertler Tumbleweed Communications 700 Saginaw Dr Redwood City CA 94063 USA Phone: +1 650 216 2039 Email: mark.schertler@tumbleweed.com Intellectual property statement 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. Martin, Schertler Expires December 2008 [Page 15] Internet-Draft Using IBE with CMS June 2008 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. Disclaimer of validity 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. 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Martin, Schertler Expires December 2008 [Page 16]