idnits 2.17.1 draft-ietf-smime-ibearch-01.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 on line 953. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 930. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 937. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 943. ** The document seems to lack an RFC 3978 Section 5.4 (updated by RFC 4748) Copyright Line. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 6. Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) (A line matching the expected section header was found, but with an unexpected indentation: ' 7. IANA Considerations' ) ** There are 301 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: A client MUST verify that the IBE system parameters that it obtains are currently within the validity period and SHOULD not use these parameters if they are not. -- 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 (October 2006) is 6365 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: 'SSL' is mentioned on line 816, but not defined == Unused Reference: 'SSL3' is defined on line 885, but no explicit reference was found in the text == Unused Reference: 'URI' is defined on line 891, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2617 (ref. 'AUTH') (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) ** Obsolete normative reference: RFC 3369 (ref. 'CMS') (Obsoleted by RFC 3852) -- Possible downref: Non-RFC (?) normative reference: ref. 'DER' ** Obsolete normative reference: RFC 2616 (ref. 'HTTP') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- No information found for draft-ietf-martin-ibcs - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'IBCS' == Outdated reference: A later version (-10) exists of draft-ietf-smime-bfibecms-01 ** Downref: Normative reference to an Informational draft: draft-ietf-smime-bfibecms (ref. 'IBECMS') -- Possible downref: Non-RFC (?) normative reference: ref. 'NIST' -- Possible downref: Non-RFC (?) normative reference: ref. 'P1363' ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Downref: Normative reference to an Informational RFC: RFC 3882 -- Possible downref: Non-RFC (?) normative reference: ref. 'SSL3' ** Obsolete normative reference: RFC 4346 (ref. 'TLS') (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 2396 (ref. 'URI') (Obsoleted by RFC 3986) Summary: 14 errors (**), 0 flaws (~~), 8 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 G. Appenzeller 3 L. Martin 4 S/MIME Working Group M. Schertler 5 Internet Draft Voltage Security 6 Expires: April 2007 October 2006 8 Identity-based Encryption Architecture 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 26 any 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 security architecture required to implement 38 identity-based encryption, a public-key encryption technology that uses 39 a user`s identity as a public key. 41 Table of Contents 43 1. Introduction...................................................3 44 1.1. Terminology...............................................3 45 2. Identity-based Encryption......................................3 46 2.1. Overview..................................................3 47 2.2. Sending a Message that is Encrypted Using IBE.............4 48 2.2.1. Sender Obtains IBE Public Parameters.................4 49 2.2.2. Sender IBE-encrypts Message..........................5 50 2.3. Receiving and Viewing an IBE-encrypted Message............5 51 2.3.1. Recipient Obtains IBE Public Parameters from PPS.....5 52 2.3.2. Recipient Obtains IBE Private Key from PKG...........6 53 2.3.3. Recipient Decrypts IBE-encrypted Message.............6 54 3. Public Parameter Lookup........................................7 55 3.1. Request Method............................................8 56 3.2. Parameter and Policy Format...............................8 57 4. Private Key Request Protocol..................................10 58 4.1. Overview.................................................10 59 4.2. Private Key Request......................................11 60 4.3. Request Structure........................................11 61 4.4. Authentication...........................................12 62 4.5. Server Response Format...................................13 63 4.6. Response Containing a Private Key........................13 64 4.7. Responses Containing a Redirect..........................14 65 4.8. Responses Indicating an Error............................15 66 5. ASN.1 Module..................................................16 67 6. Security Considerations.......................................18 68 6.1. Attacks that are outside the scope of this document......18 69 6.2. Attacks that are within the scope of this document.......19 70 6.3. Attacks that the protocols defined in this document are 71 susceptible to................................................19 72 6.4. Attacks that the protocols defined in this document protect 73 against.......................................................19 74 7. IANA Considerations...........................................20 75 8. References....................................................20 76 8.1. Normative References.....................................20 77 Authors` Addresses...............................................22 78 Intellectual Property Statement..................................22 79 Disclaimer of Validity...........................................23 80 Copyright Statement..............................................23 81 Acknowledgment...................................................23 82 1. Introduction 84 This document describes the security architecture required to 85 implement identity-based encryption, a public-key encryption 86 technology that uses a user`s identity as a public key. 88 1.1. Terminology 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in [KEY]. 94 2. Identity-based Encryption 96 2.1. Overview 98 Identity-based encryption (IBE) is a public-key technology that 99 allows keys to be calculated from an identity. This contrasts with 100 other public-key systems [P1363], in which keys are generated 101 randomly. IBE systems have public parameters that define their 102 operation, and a user of an IBE system needs to obtain these public 103 parameters before he can do any IBE operations. A user of an IBE 104 system is capable of calculating the public key of a recipient after 105 he obtains the public parameters for the IBE system and the recipient 106 of an IBE-encrypted message can decrypt an IBE-encrypted message if 107 he has both the IBE public parameters and the necessary private key. 109 With an IBE public key, a user can encrypt messages to a recipient 110 using the conventions of the Cryptographic Message Syntax [CMS]. 111 Within the framework of the CMS, a recipient also needs one 112 additional element of information to decrypt a message: the URI of 113 where he can obtain the private key that he needs to decrypt the IBE- 114 encrypted message. 116 To decrypt an IBE-encrypted message, the recipient needs to obtain 117 IBE public parameters as well as the private key that corresponds to 118 the public key that the sender used. A recipient of an IBE-encrypted 119 message obtains the IBE public parameters the same way that the 120 sender did. The IBE private key is obtained after authenticating to a 121 private key generator (PKG), a trusted third party that calculates 122 private keys for users. 124 This document describes the overall architecture that can be used to 125 implement IBE, and how the components of this architecture work 126 together to provide a functioning IBE system. The components required 127 for a complete IBE system include the following: 129 o A Public Parameter Server (PPS). A PPS provides IBE public 130 parameters and policy information for an IBE Private-key 131 Generator. Its URI is uniquely identified by the form of an 132 identity that it supports. 134 o A Private-key Generator (PKG) where users can get IBE 135 private keys after authenticating their identity in some 136 way. 138 Diagrams of these components and their interactions are shown in the 139 following sections. Note that IBE algorithms are used only for 140 encryption, so that any digital signatures that are required will 141 need to be provided by an additional mechanism. 143 2.2. Sending a Message that is Encrypted Using IBE 145 2.2.1. Sender Obtains IBE Public Parameters 147 The first step is for the sender of a message to obtain the IBE 148 public parameters that he needs for calculating the IBE public key of 149 the recipient. He obtains this information from a PPS that is hosted 150 at a well-known URI. The IBE public parameters contain all of the 151 information that the sender needs to create an IBE-encrypted message 152 except for the identity of the recipient. Section 3 of this document 153 describes the URI where a PPS is located, the format of IBE public 154 parameters, and how to obtain them. The URI from which users obtain 155 IBE public parameters MUST be authenticated in some way; PPS servers 156 MUST support TLS 1.1 [TLS] and MAY support SSL 3.0 [SSL] to satisfy 157 this requirement. Section 3 also describes the way in which identity 158 formats are defined and a minimum interoperable format that all PPSs 159 and PKGs MUST support. This step is shown below in Figure 1. 161 The sender of an IBE-encrypted message selects the PPS and 162 corresponding PKG based on his local security policy. Different PPSs 163 may provide public parameters that specify different IBE algorithms 164 or different key strengths, for example, or require the use of PKGs 165 that require different levels of authentication before granting IBE 166 private keys. 168 IBE Public Parameter Request 169 -----------------------------> 170 Sender Public Parameter Server 171 <----------------------------- 172 IBE Public Parameters 174 Figure 1 Requesting IBE Public Parameters 176 2.2.2. Sender IBE-encrypts Message 178 To IBE-encrypt a message, the sender chooses a content encryption key 179 (CEK) and uses it to encrypt his message and then encrypts the CEK 180 with the recipient`s IBE public key as described in [CMS]. This 181 operation is shown below in Figure 2. [IBCS] describes the algorithms 182 needed to implement two forms of IBE and [IBECMS] describes how to 183 use the Cryptographic Message Syntax (CMS) to encapsulate the 184 encrypted message along with the IBE information that the recipient 185 needs to decrypt the message. 187 CEK ----> Sender ----> IBE-encrypted CEK 189 ^ 190 | 191 | 193 Recipient`s Identity 194 and IBE Public Parameters 196 Figure 2 Using an IBE Public-key Algorithm to Encrypt 198 2.3. Receiving and Viewing an IBE-encrypted Message 200 The recipient of an IBE-encrypted message parses the message as 201 described in [IBECMS]. This gives him the URI where he can obtain the 202 IBE public parameters required to perform IBE calculations as well as 203 the identity that was used to encrypt the message. The PPS also gives 204 the URI of the PKG where the recipient of an IBE-encrypted message 205 can obtain the IBE private keys. After successfully authenticating to 206 this PKG the recipient receives the IBE private key over an HTTPS 207 connection. 209 The PKG may allow users other than the intended recipient to receive 210 some IBE private keys. Giving a mail filtering appliance permission 211 to obtain IBE private keys on behalf of users, for example, can allow 212 the appliance to decrypt and scan encrypted messages for viruses or 213 other malicious features. 215 2.3.1. Recipient Obtains IBE Public Parameters from PPS 217 Before he can perform any IBE calculations related to the message 218 that he has received, the recipient of an IBE-encrypted message needs 219 to obtain the IBE public parameters that were used in the encryption 220 operation. This operation is shown below in Figure 3. The comments in 221 Section 2.2.1 also apply to this operation. 223 IBE Public Parameter Request 224 -----------------------------> 225 Recipient Public Parameter Server 226 <----------------------------- 227 IBE Public Parameters 229 Figure 3 Requesting IBE Public Parameters 231 2.3.2. Recipient Obtains IBE Private Key from PKG 233 To obtain an IBE private key, the recipient of an IBE-encrypted 234 message provides an identity that was used to calculate an IBE public 235 key to a PKG and requests the private key that corresponds to the IBE 236 public key. After providing the identity for which a private key is 237 being requested, a user MUST authenticate to the PKG. Section 4 of 238 this document defines the protocol for communicating with a PKG as 239 well as a minimum interoperable way to authenticate to a PKG that all 240 IBE implementations MUST support. Because the security of IBE private 241 keys is vital to the overall security of an IBE system, IBE private 242 keys MUST be transported to recipients over a secure protocol. PKGs 243 MUST support TLS 1.1 [TLS] and MAY support SSL 3.0 [SSL] for 244 transport of IBE private keys. This operation is shown below in 245 Figure 4. 247 IBE Private Key Request 248 ----------------------------> 249 Recipient PKG 250 <---------------------------- 251 IBE Private Key 253 Figure 4 Obtaining an IBE Private Key 255 2.3.3. Recipient Decrypts IBE-encrypted Message 257 After obtaining the necessary IBE private key, the recipient uses 258 that IBE private key and the corresponding IBE public parameters to 259 decrypt the CEK. This operation is shown below in Figure 5. He then 260 uses the CEK to decrypt the encrypted message content as specified in 261 [IBECMS]. 263 IBE-encrypted CEK ----> Recipient ----> CEK 265 ^ 266 | 267 | 269 IBE Private Key 270 and IBE Public Parameters 272 Figure 5 Using an IBE Public-key Algorithm to Decrypt 274 3. Public Parameter Lookup 276 For an identity-based encryption (IBE) system to operate, the sender, 277 receiver and the private key generator (PKG) must agree on a number 278 of parameters, specifically: 280 1. The Public Parameters of the PKG. The public parameters are part 281 of the encryption (and in some cases decryption) operation of 282 the IBE system. Generation of public parameters and the master 283 secret, as well as the mathematical structure of the public 284 parameters for the BF and BB1 algorithms are described in 285 [IBCS]. 287 2. The URI of the PKG. Knowledge of this URI allows recipients to 288 request a private key as described in Section 4 of this 289 document. 291 3. The schema to format the identity strings. When issuing a 292 private key, the PKG often wants to limit who can obtain private 293 keys. For example for an identity string that contains 294 "bob@example.com", only the owner of the identity string should 295 be able to request the private key. To ensure that the PKG can 296 interpret the identity string for which a private key is 297 requested, the encryption engine and the PKG have to use the 298 same schema for identity strings. Identity schemas are described 299 in [IBECMS] 301 This section specifies how a component of an IBE system can retrieve 302 these parameters. A sending or receiving client MUST allow 303 configuration of these parameters manually, e.g. through editing a 304 configuration file. However for simplified configuration a client MAY 305 also implement the PP URI request method described in this document 306 to fetch the system parameters based on a configured URI. This is 307 especially useful for federating between IBE systems. By specifying a 308 single URI a client can be configured to fetch all the relevant 309 parameters for a remote PKG. These public parameters can then be used 310 to encrypt messages to recipients who authenticate to and retrieve 311 private keys from that PKG. 313 The following section outlines the URI request method to retrieve a 314 parameter block and describes the structure of the parameter block 315 itself. 317 3.1. Request Method 319 The configuration URI SHOULD be an HTTPS URI [HTTP] of the format: 321 http_URI = "https:" "//" host [ ":" port ] [ abs_path ] 323 An example URI for ibe system parameters is 325 https://ibe-0000.example.com/example.com.pem 327 To retrieve the IBE system parameters, the client SHOULD use the HTTP 328 GET method as defined in [HTTP]. The request MUST happen over a 329 secure protocol. The requesting client MUST support TLS 1.1 [TLS] and 330 MAY support SSL 3.0 [SSL]. When requesting the URI the client MUST 331 only accept the system parameter block if the server identity was 332 verified successfully by TLS 1.1 or SSL 3.0. 334 A successful GET request returns in its body the Base64 encoding of 335 the DER-encoded [DER] ASN.1 structure that is described in the next 336 section. 338 3.2. Parameter and Policy Format 340 The IBE System parameters are a set of 342 IBESysParams ::= SEQUENCE { 343 version INTEGER { v2(2) }, 344 districtName UTF8String, 345 districtSerial INTEGER, 346 validity Validity, 347 ibePublicParameters IBEPublicParameters, 348 ibeIdentitySchema OBJECT IDENTIFIER, 349 ibeParamExtensions IBEParamExtensions 350 } 352 The version specifies the version of the parameter format. For the 353 format described in this document it MUST be set to 2. The district 354 name is a UTF8String that MUST be a valid domain name as defined by 355 [DOM]. The districtSerial is a serial number that represents a unique 356 set of IBE public parameters. If new parameters are published for a 357 district, it MUST be increased to a number greater than the 358 previously-used serial number. 360 The validity for IBE public parameters are defined as follows: 362 ValidityPeriod ::= SEQUENCE { 363 notBefore GeneralizedTime, 364 notAfter GeneralizedTime 365 } 367 A client MUST verify that the IBE system parameters that it obtains 368 are currently within the validity period and SHOULD not use these 369 parameters if they are not. 371 It is possible to create identities for use in IBE that have a time 372 component, as described in [IBECMS]. If such an identity is used, the 373 time component of the identity MUST fall between the notBefore time 374 and the notAfter times of the IBE system parameters. 376 IBEPublicParameters is a set of public parameters that correspond to 377 IBE algorithms that the PKG associated with this district 378 understands. 380 IBEPublicParameters ::= SEQUENCE OF IBEPublicParameter 382 IBEPublicParameter ::= SEQUENCE { 383 ibeAlgorithm OBJECT IDENTIFIER, 384 publicParameterData OCTET STRING 385 } 387 The ibeAlgorithm OID specifies an IBE algorithm. The 388 publicParameterData is a DER encoded ASN.1 structure that contains 389 the actual cryptographic parameters. Its specific structure depends 390 on the algorithm. The OIDs for two IBE algorithms, the Boneh-Franklin 391 and Boneh-Boyen algorithms and their publicParameterData structures 392 are defined in [IBCS]. 394 The IBESysParams of a district MUST contain at least one algorithm 395 and MAY contain several algorithms. It MUST NOT contain two or more 396 IBEPublicParameter entries with the same algorithm. A client that 397 wants to use IBESysParams can chose any of the algorithms specified 398 in the publicParameterData structure. A client MUST implement at 399 least the Boneh-Franklin algorithm and MAY implement the Boneh-Boyens 400 and other algorithms. If a client does not support any of the 401 supported algorithms it MUST generate an error message and fail. 403 ibeIdentitySchema is an OID that defines the type of identities that 404 are used with this district. The OIDs and the required and optional 405 fields for each OID are described in [IBECMS]. 407 IBEParamExtensions is a set of extensions that can be used to define 408 additional parameters that particular implementations may require. 410 IBEParamExtensions ::= SEQUENCE OF IBEParamExtension 412 IBEParamExtension ::= SEQUENCE { 413 ibeParamExtensionOID OBJECT IDENTIFIER, 414 ibeParamExtensionValue OCTET STRING 415 } 417 The contents of the octet string are defined by the specific 418 extension type. The System Parameters of a district MAY have any 419 number of extensions, including zero. 421 The IBEParamExtension pkgURI defines the URI of the Private Key 422 Generator of the district. If the PKG is publicly accessible, this 423 extension SHOULD be present to allow the automatic retrieval of 424 private keys for recipients of encrypted messages. For this extension 425 the OCTET STRING contains a UTF8String with the URI of the key 426 server. 428 ibeParamExt OBJECT IDENTIFIER ::= { 429 ibcs ibcs3(3) parameter-extensions(2) 430 } 432 pkgURI OBJECT IDENTIFIER ::= { ibeParamExt pkgURI(1) } 434 4. Private Key Request Protocol 436 4.1. Overview 438 In an identity-based encryption (IBE) system messages are encrypted 439 using a public key that is locally calculated from public parameters 440 and a user`s identity and decrypted using a private key that 441 corresponds to the user`s public key. These private keys are 442 generated by a private key generator (PKG) based on a global secret 443 called a master secret. 445 When requesting a private key, a client has to transmit two 446 parameters: 448 1. The identity for which it is requesting a key 449 2. Authentication credentials for the individual requesting the 450 key 452 These two are often not the same as a single user may have access to 453 multiple aliases. For example an email user may have access to the 454 keys that correspond to two different email addresses, e.g. 455 bob@example.com and bob.smith@example.com. 457 This section defines the protocol to request private keys, a minimum 458 user authentication method for interoperability, and how to pass 459 authentication credentials to the server. It assumes that a client 460 has already determined the URI of the PKG. This can be done from 461 hints included in the IBE message format [IBECMS] and the system 462 parameters of the IBE system. 464 4.2. Private Key Request 466 To request a private key, a client performs a HTTP POST method as 467 defined in [HTTP]. The request MUST happen over a secure protocol. 468 The requesting client MUST support TLS 1.1 [TLS] and MAY support SSL 469 3.0 [SSL]. When requesting the URI the client MUST verify the server 470 certificate [RFC2818], and MUST abort the key request if the server 471 certificate verification of the TLS or SSL connection fails. Doing so 472 is critical to protect the authentication credentials and the private 473 key against man-in-the-middle attacks when it is transmitted from the 474 key server to the client. 476 4.3. Request Structure 478 The POST method contains in its body the following XML structure: 480 481 482 483 484 485 486 487 algorithmOID 488 489 490 ibeIdentityInfo 491 492 493 494 496 A SHOULD include a element that 497 identifies the client type and client version. 499 A key request MUST contain a valid ibeIdentityInfo that the private 500 key is requested for. This identity is the base64 encoding of the DER 501 encoding of the ASN.1 structure IBEIdentityInfo as defined in 502 [IBECMS]. 504 A key request MUST contain a element that contains a 505 XER encoded ASN.1 OBJECT IDENTIFIER that identifies the algorithm for 506 which a key is requested. OIDs for the BB1 and BF algorithms are 507 listed in [IBCS]. 509 A client MAY include optional additional XML elements in the 510 part of the key request. 512 4.4. Authentication 514 When a client requests a key from a PKG, the PKG SHOULD authenticate 515 the client before issuing the key. Authentication may either be done 516 through the key request structure or as part of the secure transport 517 protocol. 519 A client or server implementing the request protocol MUST support 520 HTTP Basic Auth as described in [AUTH]. A client and server SHOULD 521 also support HTTP Digest Auth as defined in [AUTH]. 523 For authentication methods that are not done by the transport 524 protocol, a client MAY include additional authentication information 525 in xml elements in the body part of the key request. If a client does 526 not know how to authenticate to a server, the client MAY send a key 527 request without authentication information. If the key server 528 requires the client to authenticate externally, it MAY reply with a 529 201 response code as defined below to redirect the client to the 530 correct authentication mechanism. 532 4.5. Server Response Format 534 The key server replies to the HTTP request with an HTTP response. If 535 the response contains a client error or server error status code, the 536 client MUST abort the key request and fail. 538 If the PKG replies with a HTTP response that has a status code 539 indicating success, the body of the reply MUST contain the following 540 XML structure: 542 543 544 545 bodyTags 546 547 549 The responseCode describes the type of response from the key server. 550 The list of currently defined response codes is: 552 100 KEY_FOLLOWS 553 101 RESERVED 554 201 FOLLOW_ENROLL_URI 555 300 SYSTEM_ERROR 556 301 INVALID_REQUEST 557 303 CLIENT_OBSOLETE 558 304 AUTHORIZATION DENIED 560 4.6. Response Containing a Private Key 562 If the key request was successful, the key server responds with KEY 563 FOLLOWS, and the must contain a tag with 564 a valid private key. An example of this is shown below. 566 567 568 569 570 privateKey 571 572 573 575 The privateKey is the Base64 [B64] encoding of the DER encoding of 576 the following ASN.1 structure: 578 IBEPrivateKeyReply ::= SEQUENCE { 579 pkgIdentity IBEIdentityInfo, 580 pgkAlgorithm OBJECT IDENTIFIER 581 pkgKeyData OCTET STRING 582 pkgOptions SEQUENCE OF Extensions 583 } 585 The pkgIdentity is an IBEIdentityInfo structure as defined in 586 [IBECMS]. It MUST be identical to the IBEIdentityInfo structure that 587 was sent in the key request. 589 The pkgAlgorithm is an OID that identifies the algorithm of the 590 returned private key. The OIDs for the BB and BF algorithms are 591 defined in [IBCS]. 593 The pkgKeyData is an ASN.1 structure that contains the actual private 594 key. Private-key formats for the BB and BF algorithms are defined in 595 [IBCS]. 597 A server MAY pass back additional information to a client in the 598 pkgOptions structure. The contents of the structure are defined in 599 the ASN.1 module below. 601 4.7. Responses Containing a Redirect 603 A Key Server MAY support authenticating user to external 604 authentication mechanism. If this is the case, the server replies to 605 the client with response code 201 and the body MUST contain a 606 element that specifies the URI of the authentication 607 mechanism. An example is shown below. 609 610 611 612 613 614 616 The client can now contact the authentication mechanism to obtain 617 authentication credentials. Once the client has obtained the 618 credential, it sends a new key request to the PKG with the correct 619 authentication credentials contained in the request. 621 4.8. Responses Indicating an Error 623 If the server replies with a 3xx error code, the client MUST abort 624 the request and discard any data that is part of the response. 626 The meaning of the response codes for errors is as follows: 628 300 - This indicates an internal server error of the PKG. 630 301 - The request to the server is invalid or the server is not able 631 to fulfill this type of request. 633 303 - The server is not able to serve key requests for this type of 634 client. A client with a newer version of the protocol is required. 636 304 - The key request was processed correctly, but the authentication 637 credentials provided by the user were invalid, could not be verified, 638 or do not allow access to keys for this identity. 640 5. ASN.1 Module 642 IBE1-module { joint-iso-itu(2) country(16) us(840) organization(1) 643 identicrypt(114334) ibcs(1) cms(4) module(5) version(1) 644 } 646 DEFINITIONS IMPLICIT TAGS ::= BEGIN 648 IBEOtherRecipientInfo ::= SEQUENCE { 649 oriType OBJECT IDENTIFIER, 650 oriValue IBERecipientInfo 651 } 653 ibeORIType OBJECT IDENTIFIER ::= { joint-iso-itu(2) country(16) 654 us(840) organization(1) identicrypt(114334) ibcs(1) 655 cms(4) ori-oid(1) 656 } 658 IBERecipientInfo ::= SEQUENCE { 659 cmsVersion INTEGER { v0(0) }, 660 keyFetchMethod OBJECT IDENTIFIER, 661 recipientIdentity IBEIdentityInfo, 662 serverInfo SEQUENCE OF OIDValuePairs OPTIONAL, 663 encryptedKey EncryptedKey 664 } 666 IBEIdentityInfo ::= SEQUENCE { 667 District UTF8STRING, 668 Serial INTEGER, 669 identitySchema OBJECT IDENTIFIER, 670 identityData OCTET STRING 671 } 673 OIDValuePairs ::= SEQUENCE { 674 fieldID OBJECT IDENTIFIER, 675 fieldData OCTET STRING 676 } 678 EmailIdentitySchema ::= SEQUENCE { 679 rfc822Email UTF8STRING, 680 time GeneralizedTime 681 } 683 cmsIdentityOID OBJECT IDENTIFIER ::= { joint-iso-itu(2) country(16) 684 us(840) organization(1) identicrypt(114334) keyschemas(2) 685 icschemas(1) rfc822email(1) 686 } 687 cmsPPSOID OBJECT IDENTIFIER ::= { joint-iso-itu(2) country(16) 688 us(840) organization(1) identicrypt(114334) pps-schemas(3) 689 ic-schemas(1) pps-uri(1) 690 } 692 ibcs OBJECT IDENTIFIER ::= { 693 joint-iso-itu(2) country(16) us(840) organization(1) 694 identicrypt(114334) ibcs(1) 695 } 697 -- The IBE System parameters consist of a set of public parameters 698 -- for the encryption algorithms supported by the district, 699 -- the identity schema, the URI of the PKG and further optional 700 -- parameters 702 IBESysParams ::= SEQUENCE { 703 Version INTEGER { v2(2) }, 704 districtName UTF8String, 705 districtSerial INTEGER, 706 validity Validity, 707 ibePublicParameters IBEPublicParameters, 708 ibeIdentitySchema OBJECT IDENTIFIER, 709 ibeParamExtensions IBEParamExtensions 710 } 712 -- Validity designates the time interval for which these parameters 713 -- are valid. 715 Validity ::= SEQUENCE { 716 notBefore GeneralizedTime, 717 notAfter GeneralizedTime 718 } 720 -- Public Parameters for the IBE Algorithm 721 -- ibeAlgorithm is the algorithm OID from IBCS, e.g. "bb" or "bf" 722 -- publicParameterData is a DER encoded ASN.1 public parameter 723 -- block, e.g. BFPublicParamaters, BBPublicParamaters 725 IBEPublicParameters ::= SEQUENCE OF IBEPublicParameter 727 IBEPublicParameter ::= SEQUENCE { 728 ibeAlgorithm OBJECT IDENTIFIER, 729 publicParameterData OCTET STRING 730 } 732 IBEParamExtensions ::= SEQUENCE OF IBEParamExtension 733 IBEParamExtension ::= SEQUENCE { 734 ibeParamExtensionOID OBJECT IDENTIFIER, 735 ibeParamExtensionValue OCTET STRING 736 } 738 ibeParamExt OBJECT IDENTIFIER ::= { 739 ibcs ibcs3(3) parameter-extensions(2) 740 } 742 -- Defined Extensions: 743 -- pkgURI: URI of the PKG, value is a UTF8String 745 pkgURI OBJECT IDENTIFIER ::= { ibeParamExt pkgURI(1) } 747 -- Private Key Format 749 IBEPrivateKeyReply ::= SEQUENCE { 750 pkgIdentity IBEIdentityInfo, 751 pgkKeyType OBJECT IDENTIFIER, 752 pkgKeyData OCTET STRING, 753 pkgOptions IBEParamExtensions 754 } 756 END 758 6. Security Considerations 760 6.1. Attacks that are outside the scope of this document 762 Attacks on the cryptographic algorithms that are used to implement 763 IBE are outside the scope of this document. Such attacks are detailed 764 in [IBCS], which defines parameters that will give the equivalent of 765 80-bit security, 112-bit security and 128-bit security. We assume 766 that competent administrators of an IBE system will select parameters 767 that provide a sufficient resistance to cryptanalytic attacks by 768 adversaries. 770 Attacks that require access to machines used by either the client or 771 the server components defined in this document are also outside the 772 scope of this document. Attacks that give an attacker the ability to 773 access or change the information on a PPS or PKG, especially the 774 cryptographic material, will defeat the security of an IBE system. To 775 address this concern, the PPS and PKG servers SHOULD be configured in 776 accordance with best current practices [NIST]. An IBE system should 777 be operated in an environment where such illicit access is infeasible 778 for attackers to obtain. 780 We also assume that all administrators of a system implementing the 781 protocols that are defined in this document are trustworthy and will 782 not abuse their authority to bypass the security provided by an IBE 783 system. Similarly, we assume that users of an IBE system will behave 784 responsibly, not sharing their authentication credentials with 785 others. Thus attacks that require such assumptions are outside the 786 scope of this document. 788 6.2. Attacks that are within the scope of this document 790 Attacks that passively monitor information transmitted between users 791 of an IBE system and the PPS and PKG are within the scope of this 792 document, as are attacks that let an adversary masquerade as a PPS or 793 PKG are also within the scope of this document. 795 6.3. Attacks that the protocols defined in this document are 796 susceptible to 798 The protocols defined in this document do not explicitly defend 799 against an attacker masquerading as a legitimate IBE PPS or PKG. To 800 provide protection against this possibility, client software that 801 implements the protocols defined in this document SHOULD have a user 802 interface that allows users to view the details of connections to PPS 803 and PKG servers so that users cannot easily be tricked into providing 804 valid authorization credentials to an attacker. 806 The protocols defined in this document are also vulnerable to attacks 807 against an IBE PPS or PKG. Denial of service attacks against either 808 component can result in users unable to encrypt or decrypt using IBE, 809 and users of an IBE system SHOULD take the appropriate 810 countermeasures [RFC2827, RFC3882] that their use of IBE requires. 812 6.4. Attacks that the protocols defined in this document protect 813 against 815 All communications between users of an IBE system and the PPS or PKG 816 are encrypted using TLS 1.1 [TLS] or SSL 3.0 [SSL], which should 817 provide an adequate level of protection for such communications. 819 The authentication method used by an IBE PKG should also be 820 sufficiently strong to prevent attackers from easily guessing them 821 through trial and error. 823 7. IANA Considerations 825 The XML defined in this document will be registered with the IANA per 826 the instructions in RFC 3688, The IETF XML Registry, once the format 827 has been agreed upon. 829 8. References 831 8.1. Normative References 833 [AUTH] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 834 Leach, P., Luotonen, A., Sink, E. and L. Stewart, "HTTP 835 Authentication: Basic and Digest Access Authentication", RFC 836 2617, June 1999. 838 [B64] N. Freed, N. Borenstein, Multipurpose Internet Mail 839 Extensions(MIME) Part One: Format of Internet Message Bodies," 840 RFC 2045, November 1996. 842 [CMS] R. Housley, "Cryptographic Message Syntax," RFC 3369, August 843 2002. 845 [DER] ITU-T Recommendation X.680: Information Technology - Abstract 846 Syntax Notation One, 1997. 848 [DOM] P. Mockapetris, "Domain Names - Implementation and 849 Specification," RFC 1035, November 1987. 851 [HTTP] Fielding, R., Gettys, J., Mogul, J., Frysyk, H., Masinter, L., 852 Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- 853 HTTP/1.1", RFC 2616, June 1999. 855 [IBCS] X. Boyen, L. Martin, "Identity-Based Cryptography Standard 856 (IBCS) #1: Supersingular Curve Implementations of the BF and 857 BB1 Cryptosystems," draft-ietf-martin-ibcs-00.txt, September 858 2006. 860 [IBECMS] L. Martin, M. Schertler, "Using the Boneh-Franklin identity- 861 based encryption algorithm with the Cryptographic Message 862 Syntax (CMS)," draft-ietf-smime-bfibecms-01.txt, September 863 2006. 865 [KEY] S. Brander, "Key Words for Use in RFCs to Indicate Requirement 866 Levels," BCP 14, RFC 2119, March 1997. 868 [NIST] M. Souppaya, J. Wack, K. Kent, "Security Configuration 869 Checklist Program for IT Products - Guidance for Checklist 870 Users and Developers," NIST Special Publication SP 800-70, May 871 2005. 873 [P1363] IEEE P1363, "Standards Specifications for Public-Key 874 Cryptography," 2001. 876 [RFC2818] E. Rescorla, "HTTP over TLS," RFC 2818, May 2000. 878 [RFC2827] P. Ferguson, D. Senie, "Network Ingress Filtering: 879 Defeating Denial of Service Attacks which employ IP Source 880 Address Spoofing," RFC 2827, BCP 38, May 2000. 882 [RFC3882] D. Turk, "Configuring BGP to Block Denial-of-Service 883 Attacks," RFC 3882, September 2004. 885 [SSL3] A. Frier, P. Karlton, P. Kocher, "The SSL 3.0 Protocol," 886 Netscape Communications Corp., Nov 18, 1996. 888 [TLS] T. Dierks, E. Rescorla, "The Transport Layer Security (TLS) 889 Protocol Version 1.1," RFC 4346, April 2006. 891 [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 892 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 893 1998. 895 Authors` Addresses 897 Guido Appenzeller 898 Voltage Security 899 1070 Arastradero Rd Suite 100 900 Palo Alto CA 94304 902 Phone: +1 650 543 1280 903 Email: guido@voltage.com 905 Luther Martin 906 Voltage Security 907 1070 Arastradero Rd Suite 100 908 Palo Alto CA 94304 910 Phone: +1 650 543 1280 911 Email: martin@voltage.com 913 Mark Schertler 914 Voltage Security 915 1070 Arastradero Rd Suite 100 916 Palo Alto CA 94304 918 Phone: +1 650 543 1280 919 Email: mark@voltage.com 921 Intellectual Property Statement 923 The IETF takes no position regarding the validity or scope of any 924 Intellectual Property Rights or other rights that might be claimed to 925 pertain to the implementation or use of the technology described in 926 this document or the extent to which any license under such rights 927 might or might not be available; nor does it represent that it has 928 made any independent effort to identify any such rights. Information 929 on the procedures with respect to rights in RFC documents can be 930 found in BCP 78 and BCP 79. 932 Copies of IPR disclosures made to the IETF Secretariat and any 933 assurances of licenses to be made available, or the result of an 934 attempt made to obtain a general license or permission for the use of 935 such proprietary rights by implementers or users of this 936 specification can be obtained from the IETF on-line IPR repository at 937 http://www.ietf.org/ipr. 939 The IETF invites any interested party to bring to its attention any 940 copyrights, patents or patent applications, or other proprietary 941 rights that may cover technology that may be required to implement 942 this standard. Please address the information to the IETF at ietf- 943 ipr@ietf.org. 945 Disclaimer of Validity 947 This document and the information contained herein are provided on an 948 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 949 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 950 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 951 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 952 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 953 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 955 Copyright Statement 957 Copyright (C) the Internet Society (2006). 959 This document is subject to the rights, licenses and restrictions 960 contained in BCP 78, and except as set forth therein, the authors 961 retain all their rights. 963 Acknowledgment 965 Funding for the RFC Editor function is currently provided by the 966 Internet Society.