idnits 2.17.1 draft-ietf-smime-bfibecms-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 543. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 520. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 527. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 533. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 168 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 2007) is 6246 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'BF' is mentioned on line 70, but not defined == Missing Reference: 'BB1' is mentioned on line 71, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'ASN1' ** Obsolete normative reference: RFC 3369 (ref. 'CMS') (Obsoleted by RFC 3852) -- No information found for draft-ieft-martin-ibcs - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'IBCS' -- No information found for draft-ietf-ibearch - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'IBE' -- Possible downref: Non-RFC (?) normative reference: ref. 'NIST' ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) ** Downref: Normative reference to an Informational RFC: RFC 3882 ** Obsolete normative reference: RFC 4346 (ref. 'TLS') (Obsoleted by RFC 5246) Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 L. Martin 3 S/MIME Working Group M. Schertler 4 Internet Draft Voltage Security 5 Expires: September 2007 March 2007 7 Using the Boneh-Franklin and Boneh-Boyen identity-based encryption 8 algorithms with the Cryptographic Message Syntax (CMS) 10 12 Status of this Document 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 Abstract 37 This document describes the conventions for using the Boneh-Franklin 38 (BF) and Boneh-Boyen (BB1) identity-based encryption algorithms in 39 the Cryptographic Message Syntax (CMS) to encrypt content encryption 40 keys. Object identifiers and the convention for encoding a 41 recipient's identity are also defined. 43 Table of Contents 45 1. Introduction...................................................2 46 1.1. Terminology...............................................3 47 2. Using identity-based encryption................................3 48 4. Convert reduced-time to a GeneralizedTime to get the not-before 49 "time" value......................................................5 50 3. Algorithm object identifiers...................................6 51 4. Processing by the sender.......................................6 52 5. Processing by the receiver.....................................7 53 6. ASN.1 Module...................................................8 54 7. Security Considerations........................................9 55 7.1. Attacks that are outside the scope of this document.......9 56 7.2. Attacks that are within the scope of this document.......10 57 7.3. Attacks to which the protocols defined in this document are 58 susceptible...................................................10 59 8. IANA Considerations...........................................11 60 9. References....................................................12 61 9.1. Normative References.....................................12 62 Authors' Addresses...............................................13 63 Intellectual Property Statement..................................13 64 Disclaimer of Validity...........................................13 65 Copyright Statement..............................................14 66 Acknowledgment...................................................14 68 1. Introduction 70 This document defines the steps needed to use the Boneh-Franklin [BF] 71 and Boneh-Boyen [BB1] identity-based encryption (IBE) public-key 72 algorithms in the Cryptographic Message Syntax (CMS) [CMS]. IBE is a 73 public key technology for encrypting content-encryption keys (CEKs) 74 that can be implemented within the framework of the CMS: the 75 recipient's identity is incorporated into the EnvelopedData CMS 76 content type using the OtherRecipientInfo CHOICE in the RecipientInfo 77 field as defined in section 6.2.5 of [CMS]. This document does not 78 describe the implementation of the BF and BB1 algorithms, which are 79 described in detail in [IBCS]. 81 IBE algorithms are a type of public-key cryptographic algorithm in 82 which the public key is calculated directly from a user's identity 83 instead of being generated randomly. This requires a different set of 84 steps for encryption and decryption than would be used with other 85 public-key algorithms, and these steps are defined in Sections 4 and 86 5 of this document respectively. 88 This document also defines the object identifiers and syntax of the 89 object that is used to define the identity of a message recipient. 91 CMS values and identity objects are defined using ANS.1 [ASN1]. 93 1.1. Terminology 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in RFC-2119 [KEYWORDS]. 99 2. Using identity-based encryption 101 To use IBE, the OtherRecipientInfo field MUST be set to an 102 IBEOtherRecipient type. 104 IBEOtherRecipientInfo ::= SEQUENCE { 105 ibeORIType OBJECT IDENTIFIER, 106 ibeORIValue IBERecipientInfo 107 } 109 The fields of IBEOtherRecipientInfo have the following meanings: 111 ibeORIType defines the object identifier (OID) that indicates that 112 the subsequent ibeORIValue is the information necessary to decrypt 113 the message using IBE. This field MUST be set to 115 ibeORIType OBJECT IDENTIFIER ::= { joint-iso-itu(2) country(16) 116 us(840) organization(1) identicrypt(114334) ibcs(1) 117 cms(4) ori-oid(1) } 119 ibeORIValue defines the identity that was used in the IBE algorithm 120 to encrypt the CEK. This is an IBERecipientInfo type. 122 IBERecipientInfo ::= SEQUENCE { 123 cmsVersion INTEGER { v3(3) }, 124 keyFetchMethod OBJECT IDENTIFIER, 125 recipientIdentity IBEIdentityInfo, 126 serverInfo SEQUENCE OF OIDValuePairs OPTIONAL, 127 encryptedKey EncryptedKey 128 } 130 The fields of IBERecipientInfo have the following meanings: 132 The cmsVersion MUST be set to 3. 134 The keyFetchMethod is the OID that defines the method of retrieving 135 the private key that the recipient MUST use. How to retrieve an IBE 136 private key using the steps defined in [IBE] is defined by the 137 keyFetchMethod OID. The method for retrieving private keys that is 138 specified in [IBE] is defined by cmsPPSOID. 140 cmsPPSOID OBJECT IDENTIFIER ::= { joint-iso-itu(2) country(16) 141 us(840) organization(1) identicrypt(114334) pps-schemas(3) 142 ic-schemas(1) pps-uri(1) 143 } 145 The recipientIdentity is the data that was used to calculate the 146 public key that was used to encrypt the CEK. This MUST be an 147 IBEIdentityInfo type. This recipientIdentity is used to calculate IBE 148 public and private keys as described in [IBCS]. 150 IBEIdentityInfo ::= SEQUENCE { 151 District UTF8STRING, 152 Serial INTEGER, 153 identitySchema OBJECT IDENTIFIER, 154 identityData OCTET STRING 155 } 157 The fields of IBEIdentityInfo have the following meanings. 159 The district and serial are unique identifiers that are used to 160 construct the URI for the location of where the IBE public parameters 161 are located. The construction and use of this URI is defined in 162 [IBE]. 164 The identitySchema defines the format that is used to encode the 165 information that defines the identity of the recipient. This MUST be 166 set to cmsIdentityOID. 168 cmsIdentityOID OBJECT IDENTIFIER ::= { joint-iso-itu(2) country(16) 169 us(840) organization(1) identicrypt(114334) keyschemas(2) 170 icschemas(1) rfc822email(1) 171 } 173 The identityData is the identity of the recipient. For use in S/MIME, 174 this MUST be an EmailIdentitySchema type which is DER encoded. Other 175 applications MAY use other formats for the identityData. 177 EmailIdentitySchema ::= SEQUENCE { 178 rfc822Email UTF8STRING, 179 time GeneralizedTime 180 } 182 The rfc822Email is the DER-encoded e-mail address of the recipient in 183 the format defined by [RFC822]. 185 The value of "time" is the DER-encoded UTC time after which the 186 sender wants to let the recipient decrypt the message, so it may be 187 called the "not-before" time. This is usually set to the time when 188 the message is encrypted, but MAY be set to a future time. UTC time 189 values are expressed to the nearest second. 191 The sender of an IBE-encrypted message may want to express this time 192 rounded to a time interval to create a key lifetime. A key lifetime 193 reduces the number of IBE private keys that a recipient needs to 194 retrieve, but still forces the IBE user to periodically re- 195 authenticate. Based on the time interval chosen a recipient would 196 only have to retrieve a new IBE key once during the interval. To do 197 this, follow the following steps. Let "time-interval" be the number 198 of seconds in this larger time interval. 200 1. Find the GeneralizedTime for the not-before value. 202 2. Convert this GeneralizedTime into the number of seconds since 204 January 1, 1970. Call this "total-time." 206 3. Calculate reduced-time = (floor (total-time / 208 time-interval)) * time-interval. 210 4. Convert reduced-time to a GeneralizedTime to get the not-before 211 "time" value. 213 An example of this algorithm for computing a one week time interval 214 is: 216 1. Say the GeneralizedTime is 20020401000000Z 218 2. The total-time is 1017612000 220 3. A time-interval of 1 week is 604800 seconds. So the reduced- 221 time = (floor(1017612000/604800))* 604800 = 1017273600 222 4. Giving the reduced-time GeneralizedTime for a 1 week time 223 interval of 20020328000000Z 225 When issuing IBE private keys, a PKG SHOULD NOT issue them too far 226 into the future. This restriction is to prevent an adversary who 227 obtains an IBE user's authentication credentials from requesting 228 private keys far into the future and therefore negating the periodic 229 IBE user re-authentication that key lifetime provides. For example if 230 a one week period is chosen for the key lifetime, then IBE private 231 keys should not be issued more than 1 week in advance. Otherwise once 232 an adversary gains access to the PKG via the stolen IBE user 233 credentials they can request all future keys and negate the IBE user 234 authentication restraints in place. 236 3. Algorithm object identifiers 238 The BF and BB1 algorithms as defined in [IBCS] have the following 239 object identifiers: 241 bf OBJECT IDENTIFIER ::= { joint-iso-itu(2) country(16) us(840) 242 organization(1) identicrypt(114334) ibcs(1) ibcs1(1) 243 ibe-algorithms(2) bf(1) } 245 This is the object identifier that MUST be inserted in the 246 keyEncryptionAlgorithm field in the CMS when the BF algorithm is used 247 to encrypt the CEK. 249 bb1 OBJECT IDENTIFIER ::= { joint-iso-itu(2) country(16) us(840) 250 organization(1) identicrypt(114334) ibcs(1) ibcs1(1) 251 ibe-algorithms(2) bb1(2) } 253 This is the object identifier that MUST be inserted in the 254 keyEncryptionAlgorithm field in the CMS when the BB1 algorithm is 255 used to encrypt the CEK. 257 4. Processing by the sender 259 The sender of a message that uses IBE to encrypt content encryption 260 keys performs the following steps: 262 1. Selects a set of IBE public parameters to use in the subsequent 263 steps in accordance with his local security policy. He then 264 determines the URI where the public parameters can be obtained using 265 the process described in [IBE]. This information MUST be encoded in 266 the IBEIdentityInfo as described in Section 2. 268 2. Sets the fields of an OtherRecipientInfo object to their 269 appropriate values as described in Section 2. 271 3. Calculates an IBE public key as defined in [IBCS] using this 272 IBEIdentityInfo as the identity information. 274 4. This IBE public key is then used to encrypt the content 275 encryption key (CEK), using the algorithms that are defined in 276 [IBCS]. 278 5. Sets encryptedKey to the IBE-encrypted CEK. 280 6. Within the CMS, keyEncryptionAlgorithm MUST then be set to the 281 appropriate OID for the IBE algorithm that was used (see Section 3). 283 5. Processing by the receiver 285 Upon receiving a message that has a CEK encrypted with IBE, the 286 recipient performs the following steps to decrypt the CEK: 288 1. Determines that the CEK is IBE-encrypted by noting that the 289 oriType of the OtherRecipientInfo type is set to ibeORIType. 291 2. Determines that the recipientIdentity was used as the identity 292 in IBE encryption of the CEK. 294 3. Determines the location of the IBE public parameters and the 295 IBE Private Key Generator as described in [IBE]. 297 4. Obtains the IBE public parameters from the location determined 298 in Step 3 using the process defined in [IBE]. 300 5. Obtains the IBE private key needed to decrypt the encrypted CEK 301 using the process defined in [IBE]. 303 6. Decrypts the CEK using the IBE private key obtained in Step 4 304 using the algorithms described in [IBCS]. 306 6. ASN.1 Module 308 IBECMS-module { joint-iso-itu(2) country(16) us(840) organization(1) 309 identicrypt(114334) ibcs(1) cms(4) module(5) version(1) 310 } 312 DEFINITIONS IMPLICIT TAGS ::= BEGIN 314 IBEOtherRecipientInfo ::= SEQUENCE { 315 oriType OBJECT IDENTIFIER, 316 oriValue IBERecipientInfo 317 } 319 ibeORIType OBJECT IDENTIFIER ::= { joint-iso-itu(2) country(16) 320 us(840) organization(1) identicrypt(114334) ibcs(1) 321 cms(4) ori-oid(1) 322 } 324 IBERecipientInfo ::= SEQUENCE { 325 cmsVersion INTEGER { v3(3) }, 326 keyFetchMethod OBJECT IDENTIFIER, 327 recipientIdentity IBEIdentityInfo, 328 serverInfo SEQUENCE OF OIDValuePairs OPTIONAL, 329 encryptedKey EncryptedKey 330 } 332 IBEIdentityInfo ::= SEQUENCE { 333 District UTF8STRING, 334 serial INTEGER, 335 identitySchema OBJECT IDENTIFIER, 336 identityData OCTET STRING 337 } 339 OIDValuePairs ::= SEQUENCE { 340 fieldID OBJECT IDENTIFIER, 341 fieldData OCTET STRING 342 } 344 EmailIdentitySchema ::= SEQUENCE { 345 rfc822Email UTF8STRING, 346 time GeneralizedTime 347 } 349 cmsIdentityOID OBJECT IDENTIFIER ::= { joint-iso-itu(2) country(16) 350 us(840) organization(1) identicrypt(114334) keyschemas(2) 351 icschemas(1) rfc822email(1) 352 } 353 cmsPPSOID OBJECT IDENTIFIER ::= { joint-iso-itu(2) country(16) 354 us(840) organization(1) identicrypt(114334) pps-schemas(3) 355 ic-schemas(1) pps-uri(1) 356 } 358 END 360 7. Security Considerations 362 This document is based on [CMS] and [IBCS], and the relevant security 363 considerations of those documents apply. 365 7.1. Attacks that are outside the scope of this document 367 Attacks on the cryptographic algorithms that are used to implement 368 IBE are outside the scope of this document. Such attacks are detailed 369 in [IBCS], which defines parameters that give 80-bit, 112-bit and 370 128-bit encryption strength. We assume that capable administrators of 371 an IBE system will select parameters that provide a sufficient 372 resistance to cryptanalytic attacks by adversaries. 374 Attacks that give an adversary the ability to access or change the 375 information on a PPS or PKG, especially the cryptographic material 376 (referred to in this document as the master secret), will defeat the 377 security of an IBE system. In particular, if the cryptographic 378 material is compromised the adversary will have the ability to 379 recreate any user's private key and therefore decrypt all messages 380 protected with the corresponding public key. To address this concern, 381 it is highly RECOMMENDED that best practices for physical and 382 operational security for PPS and PKG servers be followed and that 383 these servers be configured (sometimes known as hardened) in 384 accordance with best current practices [NIST]. An IBE system SHOULD 385 be operated in an environment where illicit access is infeasible for 386 attackers to obtain. 388 Attacks that require administrative or IBE user equivalent access to 389 machines used by either the client or the server components defined 390 in this document are also outside the scope of this document. 392 We also assume that all administrators of a system implementing the 393 protocols that are defined in this document are trustworthy and will 394 not abuse their authority to bypass the security provided by an IBE 395 system. Similarly, we assume that users of an IBE system will behave 396 responsibly, not sharing their authentication credentials with 397 others. Thus attacks that require such assumptions are outside the 398 scope of this document. 400 7.2. Attacks that are within the scope of this document 402 Attacks within the scope of this document are those that allow an 403 adversary to: 405 o passively monitor information transmitted between users of 406 an IBE system and the PPS and PKG 408 o masquerade as a PPS or PKG 410 o perform a DOS attack on a PPS or PKG 412 o easily guess an IBE users authentication credential 414 7.3. Attacks to which the protocols defined in this document are 415 susceptible 417 All communications between users of an IBE system and the PPS or PKG 418 are protected using TLS 1.1 [TLS]. The IBE system defined in this 419 document provides no additional security protections for the 420 communications between IBE users and the PPS or PKG. Therefore the 421 described IBE system is completely dependent on the TLS security 422 mechanisms for authentication of the PKG or PPS server and for 423 confidentiality and integrity of the communications. Should there be 424 a compromise of the TLS security mechanisms, the integrity of all 425 communications between an IBE user and the PPS or PKG will be 426 suspect. 428 The protocols defined in this document do not explicitly defend 429 against an attacker masquerading as a legitimate IBE PPS or PKG. The 430 protocols rely on the server authentication mechanism of TLS [TLS]. 431 In addition to the TLS server authentication mechanism IBE client 432 software can provide protection against this possibility by providing 433 user interface capabilities that allows users to visually determine 434 that a connection to PPS and PKG servers is legitimate. This 435 additional capability can help ensure that users cannot easily be 436 tricked into providing valid authorization credentials to an 437 attacker. 439 The protocols defined in this document are also vulnerable to attacks 440 against an IBE PPS or PKG. Denial of service attacks against either 441 component can result in users unable to encrypt or decrypt using IBE, 442 and users of an IBE system SHOULD take the appropriate 443 countermeasures [RFC2827, RFC3882] that their use of IBE requires. 445 The IBE user authentication method selected by an IBE PKG SHOULD be 446 of sufficient strength to prevent attackers from easily guessing the 447 IBE user's authentication credentials through trial and error. 449 8. IANA Considerations 451 All of the object identifiers used in this document were assigned by 452 the National Institute of Standards and Technology (NIST), so no 453 further action by the IANA is necessary for this document. 455 9. References 457 9.1. Normative References 459 [ASN1] CCITT, Recommendation X.209: Specification of Basic Encoding 460 Rules for Abstract Syntax Notation One (ASN.1). 1998. 462 [CMS] R. Housley, "Cryptographic Message Syntax," RFC 3369, August 463 2002. 465 [IBCS] X. Boyen, L. Martin, "Identity-based cryptography standard 466 (IBCS) #1: supersingular curve implementations of the BF 467 and BB1 cryptosystems," draft-ieft-martin-ibcs-00.txt. 469 [IBE] G. Appenzeller, L. Martin, M. Schertler, "Identity-based 470 Encryption Architecture," draft-ietf-ibearch-01.txt. 472 [KEYWORDS] S. Brander, "Key Words for Use in RFCs to Indicate 473 Requirement Levels," BCP 14, RFC 2119, March 1997. 475 [NIST] M. Souppaya, J. Wack, K. Kent, "Security Configuration 476 Checklist Program for IT Products - Guidance for Checklist 477 Users and Developers," NIST Special Publication SP 800-70, May 478 2005. 480 [RFC822] D. Crocker, "Standard for the format of ARPA internet text 481 messages," RFC 822, August 1982. 483 [RFC2827] P. Ferguson, D. Senie, "Network Ingress Filtering: 484 Defeating Denial of Service Attacks which employ IP Source 485 Address Spoofing," RFC 2827, BCP 38, May 2000. 487 [RFC3882] D. Turk, "Configuring BGP to Block Denial-of-Service 488 Attacks," RFC 3882, September 2004. 490 [TLS] T. Dierks, E. Rescorla, "The Transport Layer Security (TLS) 491 Protocol Version 1.1," RFC 4346, April 2006. 493 Authors' Addresses 495 Luther Martin 496 Voltage Security 497 1070 Arastradero Rd Suite 100 498 Palo Alto CA 94304 500 Phone: +1 650 543 1280 501 Email: martin@voltage.com 503 Mark Schertler 504 Voltage Security 505 1070 Arastradero Rd Suite 100 506 Palo Alto CA 94304 508 Phone: +1 650 543 1280 509 Email: mark@voltage.com 511 Intellectual Property Statement 513 The IETF takes no position regarding the validity or scope of any 514 Intellectual Property Rights or other rights that might be claimed to 515 pertain to the implementation or use of the technology described in 516 this document or the extent to which any license under such rights 517 might or might not be available; nor does it represent that it has 518 made any independent effort to identify any such rights. Information 519 on the procedures with respect to rights in RFC documents can be 520 found in BCP 78 and BCP 79. 522 Copies of IPR disclosures made to the IETF Secretariat and any 523 assurances of licenses to be made available, or the result of an 524 attempt made to obtain a general license or permission for the use of 525 such proprietary rights by implementers or users of this 526 specification can be obtained from the IETF on-line IPR repository at 527 http://www.ietf.org/ipr. 529 The IETF invites any interested party to bring to its attention any 530 copyrights, patents or patent applications, or other proprietary 531 rights that may cover technology that may be required to implement 532 this standard. Please address the information to the IETF at 533 ietf-ipr@ietf.org. 535 Disclaimer of Validity 537 This document and the information contained herein are provided on an 538 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 539 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 540 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 541 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 542 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 543 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 545 Copyright Statement 547 Copyright (C) The IETF Trust (2007). 549 This document is subject to the rights, licenses and restrictions 550 contained in BCP 78, and except as set forth therein, the authors 551 retain all their rights. 553 Acknowledgment 555 Funding for the RFC Editor function is currently provided by the 556 Internet Society.