diff options
Diffstat (limited to 'doc/rfc/rfc5409.txt')
| -rw-r--r-- | doc/rfc/rfc5409.txt | 731 |
1 files changed, 731 insertions, 0 deletions
diff --git a/doc/rfc/rfc5409.txt b/doc/rfc/rfc5409.txt new file mode 100644 index 0000000..335ebae --- /dev/null +++ b/doc/rfc/rfc5409.txt @@ -0,0 +1,731 @@ + + + + + + +Network Working Group L. Martin +Request for Comments: 5409 Voltage Security +Category: Informational M. Schertler + Axway + January 2009 + + + Using the Boneh-Franklin and Boneh-Boyen Identity-Based Encryption + Algorithms with the Cryptographic Message Syntax (CMS) + +Status of This Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (c) 2009 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents (http://trustee.ietf.org/ + license-info) in effect on the date of publication of this document. + Please review these documents carefully, as they describe your rights + and restrictions with respect to this document. + +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 Informational [Page 1] + +RFC 5409 Using IBE with CMS January 2009 + + +Table of Contents + + 1. Introduction ....................................................2 + 1.1. Terminology ................................................3 + 1.2. IBE Overview ...............................................3 + 2. Using Identity-Based Encryption .................................3 + 3. Key Encryption Algorithm Identifiers ............................6 + 4. Processing by the Sender ........................................7 + 5. Processing by the Receiver ......................................7 + 6. ASN.1 Module ....................................................8 + 7. Security Considerations .........................................9 + 7.1. Attacks outside the Scope of This Document .................9 + 7.2. Attacks within the Scope of This Document .................10 + 7.3. Attacks to Which the Protocols Defined in This Document + Are Susceptible............................................11 + 8. References .....................................................12 + 8.1. Normative References ......................................12 + 8.2. Informative References ....................................12 + +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 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]. + + + + + + + + +Martin & Schertler Informational [Page 2] + +RFC 5409 Using IBE with CMS January 2009 + + +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 interactions 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. + +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) version(1) + } + + + +Martin & Schertler Informational [Page 3] + +RFC 5409 Using IBE with CMS January 2009 + + + 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. This SHOULD be set to + uriPPSOID [IBE], which is defined to be the following: + + uriPPSOID OBJECT IDENTIFIER ::= { + joint-iso-itu-t(2) country(16) us(840) + organization(1) identicrypt(114334) + pps-schemas(3) ic-schemas(1) pps-uri(1) version(1) + } + + The recipientIdentity is the data that the sender used to calculate + the IBE public key that the sender 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 a DER- + encoded [DER] IBEIdentityInfo type [IBE], which is defined as + follows: + + IBEIdentityInfo ::= SEQUENCE { + district IA5String, + serial INTEGER, + identityType OBJECT IDENTIFIER, + identityData OCTET STRING + } + + The identityType 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 + EmailIdentityData type. The value of cmsIdentityOID is the + following: + + + + + +Martin & Schertler Informational [Page 4] + +RFC 5409 Using IBE with CMS January 2009 + + + cmsIdentityOID OBJECT IDENTIFIER ::= { + joint-iso-itu-t(2) country(16) us(840) + organization(1) identicrypt(114334) + keyschemas(2) icschemas(1) email(1) version(1) + } + + The identityData MUST be an EmailIdentityData type, which is defined + as follows: + + EmailIdentityData ::= SEQUENCE { + rfc822Name IA5String, + time GeneralizedTime + } + + The rfc822Name field is the email 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 steps below. 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 Informational [Page 5] + +RFC 5409 Using IBE with CMS January 2009 + + + 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 one 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. A client MUST ignore any part of serverInfo + that it is unable to process. + + The encryptedKey is the result of encrypting the CEK with an IBE + algorithm using recipientIdentity as the IBE public key. + +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) + } + + + +Martin & Schertler Informational [Page 6] + +RFC 5409 Using IBE with CMS January 2009 + + + 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]. + + 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: + + + + +Martin & Schertler Informational [Page 7] + +RFC 5409 Using IBE with CMS January 2009 + + + 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 + defined by this document. + + 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 + + IMPORTS IBEIdentityInfo, uriPPSOID FROM + + IBEARCH-module { joint-iso-itu-t(2) country(16) + us(840) organization(1) identicrypt(114334) ibcs(1) + ibearch(5) module(5) version(1) + }; + + IBEOtherRecipientInfo ::= SEQUENCE { + oriType OBJECT IDENTIFIER, + oriValue IBERecipientInfo + } + + + + + + +Martin & Schertler Informational [Page 8] + +RFC 5409 Using IBE with CMS January 2009 + + + ibeORIType OBJECT IDENTIFIER ::= { + joint-iso-itu-t(2) country(16) us(840) + organization(1) identicrypt(114334) + ibcs(1) cms(4) ori-oid(1) version(1) + } + + IBERecipientInfo ::= SEQUENCE { + cmsVersion INTEGER { v3(3) }, + keyFetchMethod OBJECT IDENTIFIER, + recipientIdentity IBEIdentityInfo, + serverInfo SEQUENCE SIZE (1..MAX) OF + OIDValuePairs OPTIONAL, + encryptedKey EncryptedKey + } + + + OIDValuePairs ::= SEQUENCE { + fieldID OBJECT IDENTIFIER, + fieldData OCTET STRING + } + + EncryptedKey ::= OCTET STRING + + EmailIdentityData ::= SEQUENCE { + rfc822Name IA5String, + time GeneralizedTime + } + + cmsIdentityOID OBJECT IDENTIFIER ::= { + joint-iso-itu-t(2) country(16) us(840) + organization(1) identicrypt(114334) + keyschemas(2) icschemas(1) email(1) version(1) + } + + END + +7. Security Considerations + + This document is based on [CMS], [IBCS], and [IBE], and the relevant + security considerations of those documents apply. + +7.1. Attacks 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, + + + + + +Martin & Schertler Informational [Page 9] + +RFC 5409 Using IBE with CMS January 2009 + + + 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. + + Attacks that require administrative access 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 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 + + + +Martin & Schertler Informational [Page 10] + +RFC 5409 Using IBE with CMS January 2009 + + + o masquerade as a PPS or PKG + + o perform a denial-of-service (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 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. + + + + + + + + + + + + +Martin & Schertler Informational [Page 11] + +RFC 5409 Using IBE with CMS January 2009 + + +8. References + +8.1. Normative References + + [ASN1] ITU-T Recommendation X.680: Information Technology - + "Abstract Syntax Notation One (ASN.1): Specification of + Basic Notation", July 2002. + + [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC + 3852, July 2004. + + [DER] ITU-T Recommendation X.690: OSI Networking and System + Aspects: Abstract Syntax Notation One (ASN.1), July 2002. + + [DOS] Ferguson, P. and D. Senie, "Network Ingress Filtering: + Defeating Denial of Service Attacks which employ IP Source + Address Spoofing", BCP 38, RFC 2827, May 2000. + + [IBCS] Boyen, X. and L. Martin, "Identity-Based Cryptography + Standard (IBCS) #1: Supersingular Curve Implementations of + the BF and BB1 Cryptosystems", RFC 5091, December 2007. + + [IBE] Appenzeller, G., Martin, L., and M. Schertler, "Identity- + Based Encryption Architecture and Supporting Data + Structures", RFC 5408, January 2009. + + [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [PKIX] 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. + + [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security + (TLS) Protocol Version 1.2", RFC 5246, August 2008. + +8.2. Informative References + + [BGPDOS] Turk, D., "Configuring BGP to Block Denial-of-Service + Attacks", RFC 3882, September 2004. + + [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. + + + + + +Martin & Schertler Informational [Page 12] + +RFC 5409 Using IBE with CMS January 2009 + + +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 + Axway + 1600 Seaport Blvd, Suite 400 + Redwood City, CA 94063 + USA + + Phone: +1 650 216 2039 + EMail: mschertler@us.axway.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Martin & Schertler Informational [Page 13] + |