idnits 2.17.1 draft-ietf-smime-ibearch-06.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 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1154. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1128. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1136. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1142. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == 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 date on which it utilizes the IBE system parameters falls between the notBefore time and the notAfter time of the IBE system parameters and SHOULD not use the parameters if they do 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 (November 2007) is 6000 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'ASN1' ** Obsolete normative reference: RFC 2617 (ref. 'AUTH') (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) ** Obsolete normative reference: RFC 3852 (ref. 'CMS') (Obsoleted by RFC 5652) -- 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) ** Obsolete normative reference: RFC 2818 (ref. 'HTTPTLS') (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 2822 (ref. 'TEXTMSG') (Obsoleted by RFC 5322) ** Obsolete normative reference: RFC 4346 (ref. 'TLS') (Obsoleted by RFC 5246) ** Downref: Normative reference to an Informational RFC: RFC 3236 (ref. 'XHTML') == Outdated reference: A later version (-07) exists of draft-martin-ibcs-06 == Outdated reference: A later version (-10) exists of draft-ietf-smime-bfibecms-06 Summary: 8 errors (**), 0 flaws (~~), 5 warnings (==), 9 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 Voltage Security 5 Internet Draft M. Schertler 6 Expires: May 2008 Tumbleweed Communications 7 November 2007 9 Identity-based Encryption Architecture 11 13 Status of this Document 15 By submitting this Internet-Draft, each author represents 16 that any applicable patent or other IPR claims of which 17 he or she is aware have been or will be disclosed, and 18 any of which he or she becomes aware will be disclosed, 19 in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet 22 Engineering Task Force (IETF), its areas, and its working 23 groups. Note that other groups may also distribute 24 working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum 27 of six months and may be updated, replaced, or obsoleted 28 by other documents at any time. It is inappropriate to 29 use Internet-Drafts as reference material or to cite them 30 other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be 36 accessed at 37 http://www.ietf.org/shadow.html 39 Abstract 41 This document describes the security architecture required 42 to implement identity-based encryption, a public-key 43 encryption technology that uses a user's identity as a 44 public key. 46 Table of Contents 48 1. Introduction.........................................3 49 1.1. Terminology.....................................3 50 2. Identity-based Encryption............................3 51 2.1. Overview........................................3 52 2.2. Sending a Message that is IBE-encrypted.........4 53 2.2.1. Sender Obtains Public Parameters...........5 54 2.2.2. Construct and Send IBE-encrypted Message...6 55 2.3. Receiving and Viewing an IBE-encrypted Message..6 56 2.3.1. Recipient Obtains Public Parameters........7 57 2.3.2. Recipient Obtains IBE Private Key..........8 58 2.3.3. Recipient Decrypts IBE-encrypted Message...8 59 3. Public Parameter Lookup..............................9 60 3.1. Request Method.................................10 61 3.2. Parameter and Policy Format....................10 62 4. Private Key Request Protocol........................13 63 4.1. Overview.......................................13 64 4.2. Private Key Request............................14 65 4.3. Request Structure..............................14 66 4.4. Authentication.................................15 67 4.5. Server Response Format.........................16 68 4.6. Response Containing a Private Key..............16 69 4.7. Responses Containing a Redirect................18 70 4.8. Responses Indicating an Error..................18 71 5. ASN.1 Module........................................19 72 6. Security Considerations.............................21 73 6.1. Attacks that are outside the scope of this 74 document............................................21 75 6.2. Attacks that are within the scope of this 76 document............................................22 77 6.2.1. Attacks to which the protocols defined in 78 this document are susceptible....................22 79 7. IANA Considerations.................................23 80 8. References..........................................24 81 8.1. Normative References...........................24 82 8.2. Informative References.........................25 83 Authors' Addresses.....................................26 84 Intellectual Property Statement........................26 85 Disclaimer of Validity.................................27 86 Copyright Statement....................................27 87 Acknowledgment.........................................27 89 1. Introduction 91 This document describes the security architecture 92 required to implement identity-based encryption, a 93 public-key encryption technology that uses a user's 94 identity as a public key. Objects used in this 95 implementation are defined using ASN.1 [ASN1]. 97 1.1. Terminology 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 100 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", 101 "MAY", and "OPTIONAL" in this document are to be 102 interpreted as described in [KEY]. 104 2. Identity-based Encryption 106 2.1. Overview 108 Identity-based encryption (IBE) is a public-key 109 encryption technology that allows a public key to be 110 calculated from an identity and the corresponding private 111 key to be calculated from the public key. A public key 112 can be calculated by anyone who has the necessary 113 mathematical parameters that are needed for the 114 calculation; a cryptographic secret is needed to 115 calculate a private key, and the calculation can only be 116 performed by a trusted server which has this secret. 118 Calculation of both the public and private keys in an 119 IBE-based system can occur as needed, resulting in just- 120 in-time key material. This contrasts with other public- 121 key systems [P1363], in which keys are generated randomly 122 and distributed prior to secure communication commencing. 123 The ability to calculate a recipient's public key, in 124 particular, eliminates the need for the sender and 125 receiver in an IBE-based messaging system to interact 126 with each other, either directly or through a proxy such 127 as a directory server, before sending secure messages. 129 This document describes an IBE-based messaging system and 130 how the components of the system work together. The 131 components required for a complete IBE messaging system 132 are the following: 134 o A Private-key Generator (PKG). The PKG contains 135 the cryptographic material, known as a master 136 secret, which is used for generating an 137 individual's IBE private key. A PKG accepts an 138 IBE user's private key request, and after 139 successfully authenticating them in some way 140 returns, their IBE private key. 142 o A Public Parameter Server (PPS). IBE System 143 Parameters include publicly-sharable 144 cryptographic material, known as IBE public 145 parameters, and policy information for an 146 associated PKG. A PPS provides a well-known 147 location for secure distribution of IBE public 148 parameters and policy information for the IBE 149 PKG. 151 A logical architecture would be to have a PKG/PPS per a 152 name space, such as a DNS zone. The organization that 153 controls the DNS zone would also control the PKG/PPS and 154 thus the determination of which PKG/PSS to use when 155 creating public and private keys for the organization's 156 members. In this case the PPS URI can be uniquely created 157 by the form of the identity that it supports. This 158 architecture would make it clear which set of public 159 parameters to use and where to retrieve them for a given 160 identity (for example, an RFC 2822 address [TEXTMSG]). 162 IBE encrypted messages can use standard message formats, 163 such as the Cryptographic Message Syntax [CMS]. How to 164 use IBE with CMS is defined in [IBECMS]. 166 Note that IBE algorithms are used only for encryption, so 167 if digital signatures are required they will need to be 168 provided by an additional mechanism. 170 2.2. Sending a Message that is IBE-encrypted 172 In order to send an encrypted message, an IBE user must 173 perform the following steps: 175 1. Obtain the recipient's public parameters 177 A user of an IBE system is capable of calculating 178 the public key of a recipient after he obtains the 179 public parameters for their IBE system. Once the 180 public parameters are obtained, IBE-encrypted 181 messages can be sent. 183 2. Construct and Send IBE-encrypted Message 185 In addition to the IBE public parameters, all that 186 is needed to construct an IBE-encrypted message is 187 the recipient's identity, which can be used to 188 generate their public key. When this identity is 189 the same as the identity that a message would be 190 addressed to, then no more information is needed 191 from a user to send them a secure message then is 192 needed to send them an unsecured message. This is 193 one of the major benefits of an IBE-based secure 194 messaging system. Examples of identities can be an 195 individual, group, or role identifiers. 197 2.2.1. Sender Obtains Public Parameters 199 The sender of a message obtains the IBE public parameters 200 that he needs for calculating the IBE public key of the 201 recipient from a PPS that is hosted at a well-known URI. 202 The IBE public parameters contain all of the information 203 that the sender needs to create an IBE-encrypted message 204 except for the identity of the recipient. Section 3 of 205 this document describes the URI [URI] where a PPS is 206 located, the format of IBE public parameters, and how to 207 obtain them. The URI from which users obtain IBE public 208 parameters MUST be authenticated in some way; PPS servers 209 MUST support TLS 1.1 [TLS] to satisfy this requirement. 210 Section 3 also describes the way in which identity 211 formats are defined and a minimum interoperable format 212 that all PPSs and PKGs MUST support. This step is shown 213 below in Figure 1. 215 IBE Public Parameter Request 216 -----------------------------> 217 Sender PPS 218 <----------------------------- 219 IBE Public Parameters 221 Figure 1 Requesting IBE Public Parameters 223 The sender of an IBE-encrypted message selects the PPS 224 and corresponding PKG based on his local security policy. 225 Different PPSs may provide public parameters that specify 226 different IBE algorithms or different key strengths, for 227 example, or require the use of PKGs that require 228 different levels of authentication before granting IBE 229 private keys. 231 2.2.2. Construct and Send IBE-encrypted Message 233 To IBE-encrypt a message, the sender chooses a content- 234 encryption key (CEK) and uses it to encrypt his message 235 and then encrypts the CEK with the recipient's IBE public 236 key as described in [CMS]. This operation is shown below 237 in Figure 2. [IBCS] describes the algorithms needed to 238 implement two forms of IBE and [IBECMS] describes how to 239 use the Cryptographic Message Syntax (CMS) to encapsulate 240 the encrypted message along with the IBE information that 241 the recipient needs to decrypt the message. 243 CEK ----> Sender ----> IBE-encrypted CEK 245 ^ 246 | 247 | 249 Recipient's Identity 250 and IBE Public Parameters 252 Figure 2 Using an IBE Public-key Algorithm to Encrypt 254 2.3. Receiving and Viewing an IBE-encrypted Message 256 In order to read an encrypted message, a recipient of an 257 IBE-encrypted message parses the message as described in 258 [IBECMS]. This gives him the URI he needs to obtain the 259 IBE public parameters that are required to perform IBE 260 calculations as well as a component of the identity that 261 was used to encrypt the message. Next the recipient must 262 carry out the following steps: 264 1. Obtain the recipient's public parameters 266 An IBE system's public parameters allow it to 267 uniquely create public and private keys. The 268 recipient of an IBE-encrypted message can decrypt 269 an IBE-encrypted message if he has both the IBE 270 public parameters and the necessary IBE private 271 key. The PPS can also provide the URI of the PKG 272 where the recipient of an IBE-encrypted message can 273 obtain the IBE private keys. 275 2. Obtain the IBE private key from the PKG 277 To decrypt an IBE-encrypted message, in addition to 278 the IBE public parameters the recipient needs to 279 obtain the private key that corresponds to the 280 public key that the sender used. The IBE private 281 key is obtained after successfully authenticating 282 to a private key generator (PKG), a trusted third 283 party that calculates private keys for users. The 284 recipient then receives the IBE private key over a 285 secure connection. 287 3. Decrypt IBE-encrypted message 289 The IBE private key decrypts the CEK (see section 290 2.2.2). The CEK is then used to decrypt encrypted 291 message. 293 The PKG may allow users other than the intended recipient 294 to receive some IBE private keys. Giving a mail filtering 295 appliance permission to obtain IBE private keys on behalf 296 of users, for example, can allow the appliance to decrypt 297 and scan encrypted messages for viruses or other 298 malicious features. 300 2.3.1. Recipient Obtains Public Parameters 302 Before he can perform any IBE calculations related to the 303 message that he has received, the recipient of an IBE- 304 encrypted message needs to obtain the IBE public 305 parameters that were used in the encryption operation. 306 This operation is shown below in Figure 3. Because the 307 use of the correct public parameters is vital to the 308 overall security of an IBE system, IBE public parameters 309 MUST be transported to recipients over a secure protocol. 310 PPSs MUST support TLS 1.1 [TLS] or its successors, using 311 the latest version supported by both parties, for 312 transport of IBE public parameters. In addition, users 313 MUST verify that the subject name in the server 314 certificate matches the URI of the PPS. The comments in 315 Section 2.2.1 also apply to this operation. 317 IBE Public Parameter Request 318 -----------------------------> 319 Recipient PPS 320 <----------------------------- 321 IBE Public Parameters 323 Figure 3 Requesting IBE Public Parameters 325 2.3.2. Recipient Obtains IBE Private Key 327 To obtain an IBE private key, the recipient of an IBE- 328 encrypted message provides the IBE public key used to 329 encrypt the message and their authentication credentials 330 to a PKG and requests the private key that corresponds to 331 the IBE public key. Section 4 of this document defines 332 the protocol for communicating with a PKG as well as a 333 minimum interoperable way to authenticate to a PKG that 334 all IBE implementations MUST support. Because the 335 security of IBE private keys is vital to the overall 336 security of an IBE system, IBE private keys MUST be 337 transported to recipients over a secure protocol. PKGs 338 MUST support TLS 1.1 [TLS] or its successors, using the 339 latest version supported by both parties, for transport 340 of IBE private keys. This operation is shown below in 341 Figure 4. 343 IBE Private Key Request 344 ----------------------------> 345 Recipient PKG 346 <---------------------------- 347 IBE Private Key 349 Figure 4 Obtaining an IBE Private Key 351 2.3.3. Recipient Decrypts IBE-encrypted Message 353 After obtaining the necessary IBE private key, the 354 recipient uses that IBE private key and the corresponding 355 IBE public parameters to decrypt the CEK. This operation 356 is shown below in Figure 5. He then uses the CEK to 357 decrypt the encrypted message content as specified in 358 [IBECMS]. 360 IBE-encrypted CEK ----> Recipient ----> CEK 362 ^ 363 | 364 | 366 IBE Private Key 367 and IBE Public Parameters 369 Figure 5 Using an IBE Public-key Algorithm to Decrypt 371 3. Public Parameter Lookup 373 For an identity-based encryption (IBE) system to operate, 374 the sender, receiver and the private key generator (PKG) 375 must agree on a number of parameters, specifically: 377 1. The Public Parameters of the PKG. The public 378 parameters are part of the encryption (and in some 379 cases decryption) operation of the IBE system. 380 Generation of public parameters and the master 381 secret, as well as the mathematical structure of the 382 public parameters for the BF and BB1 algorithms are 383 described in [IBCS]. 385 2. The URI of the PKG. Knowledge of this URI allows 386 recipients to request a private key as described in 387 Section 4 of this document. 389 3. The schema to format the identity strings. When 390 issuing a private key, the PKG often wants to limit 391 who can obtain private keys. For example for an 392 identity string that contains "bob@example.com," 393 only the owner of the identity string should be able 394 to request the private key. To ensure that the PKG 395 can interpret the identity string for which a 396 private key is requested, the encryption engine and 397 the PKG have to use the same schema for identity 398 strings. Identity schemas are described in [IBECMS] 400 This section specifies how a component of an IBE system 401 can retrieve these parameters. A sending or receiving 402 client MUST allow configuration of these parameters 403 manually, e.g. through editing a configuration file. 404 However for simplified configuration a client MAY also 405 implement the PP URI request method described in this 406 document to fetch the system parameters based on a 407 configured URI. This is especially useful for federating 408 between IBE systems. By specifying a single URI a client 409 can be configured to fetch all the relevant parameters 410 for a remote PKG. These public parameters can then be 411 used to encrypt messages to recipients who authenticate 412 to and retrieve private keys from that PKG. 414 The following section outlines the URI request method to 415 retrieve a parameter block and describes the structure of 416 the parameter block itself. 418 3.1. Request Method 420 The configuration URI SHOULD be an HTTPS URI [HTTP] of 421 the format: 423 http_URI = "https:" "//" host [ ":" port ] [ abs_path ] 425 An example URI for ibe system parameters is 427 https://ibe-0000.example.com/example.com.pp 429 To retrieve the IBE system parameters, the client SHOULD 430 use the HTTP GET method as defined in [HTTP]. The request 431 MUST happen over a secure protocol. The requesting client 432 MUST support TLS 1.1 [TLS] or its successors and SHOULD 433 use the latest version supported by both parties. When 434 requesting the URI the client MUST only accept the system 435 parameter block if the server identity was verified 436 successfully by TLS 1.1 [TLS] or its successors. 438 A successful GET request returns in its body the Base64 439 encoding of the DER-encoded [DER] IBESysParams structure 440 that is described in the next section. This structure 441 MUST be served as an application/octet-stream MIME type 442 [MIME]. 444 3.2. Parameter and Policy Format 446 The IBE System parameters are a structure of the form 447 IBESysParams ::= SEQUENCE { 448 version INTEGER { v2(2) }, 449 districtName IA5String, 450 districtSerial INTEGER, 451 validity ValidityPeriod, 452 ibePublicParameters IBEPublicParameters, 453 ibeIdentitySchema OBJECT IDENTIFIER, 454 ibeParamExtensions IBEParamExtensions OPTIONAL 455 } 457 The version specifies the version of the IBESysParams 458 format. For the format described in this document it MUST 459 be set to 2. The district name is an IA5String that MUST 460 be a valid domain name as defined by [DOM]. The 461 districtSerial is a serial number that represents a 462 unique set of IBE public parameters. If new parameters 463 are published for a district, it MUST be increased to a 464 number greater than the previously-used serial number. 466 The validity period or lifetime of a specific instance of 467 the IBESysParams is defined as follows: 469 ValidityPeriod ::= SEQUENCE { 470 notBefore GeneralizedTime, 471 notAfter GeneralizedTime 472 } 474 A client MUST verify that the date on which it utilizes 475 the IBE system parameters falls between the notBefore 476 time and the notAfter time of the IBE system parameters 477 and SHOULD not use the parameters if they do not. 479 IBE system parameters MUST be regenerated and republished 480 whenever the ibePublicParameters, ibeIdentitySchema, or 481 ibeParamExtensions change for a district. A client SHOULD 482 refetch the IBE system parameters at an application- 483 configurable interval to ensure that it has the most 484 current version on the IBE system parameters. 486 It is possible to create identities for use in IBE that 487 have a time component, as described in [IBECMS]. If such 488 an identity is used, the time component of the identity 489 MUST fall between the notBefore time and the notAfter 490 times of the IBE system parameters. 492 IBEPublicParameters is a structure containing public 493 parameters that correspond to IBE algorithms that the PKG 494 associated with this district understands. 496 IBEPublicParameters ::= SEQUENCE (1..MAX) OF 497 IBEPublicParameter 499 IBEPublicParameter ::= SEQUENCE { 500 ibeAlgorithm OBJECT IDENTIFIER, 501 publicParameterData OCTET STRING 502 } 504 The ibeAlgorithm OID specifies an IBE algorithm. The 505 publicParameterData is a DER-encoded [DER] structure that 506 contains the actual cryptographic parameters. Its 507 specific structure depends on the algorithm. The OIDs for 508 two IBE algorithms, the Boneh-Franklin and Boneh-Boyen 509 algorithms and their publicParameterData structures are 510 defined in [IBCS]. 512 The IBESysParams of a district MUST contain at least one 513 algorithm and MAY contain several algorithms. It MUST NOT 514 contain two or more IBEPublicParameter entries with the 515 same algorithm. A client that wants to use IBESysParams 516 can chose any of the algorithms specified in the 517 publicParameterData structure. A client MUST implement at 518 least the Boneh-Franklin algorithm and MAY implement the 519 Boneh-Boyen and other algorithms. If a client does not 520 support any of the supported algorithms it MUST generate 521 an error message and fail. 523 ibeIdentitySchema is an OID that defines the type of 524 identities that are used with this district. The OIDs and 525 the required and optional fields for each OID are 526 described in [IBECMS]. 528 IBEParamExtensions is a set of extensions that can be 529 used to define additional parameters that particular 530 implementations may require. 532 IBEParamExtensions ::= SEQUENCE OF IBEParamExtension 534 IBEParamExtension ::= SEQUENCE { 535 ibeParamExtensionOID OBJECT IDENTIFIER, 536 ibeParamExtensionValue OCTET STRING 537 } 539 The contents of the octet string are defined by the 540 specific extension type. The System Parameters of a 541 district MAY have any number of extensions, including 542 zero. 544 The IBEParamExtension pkgURI defines the URI of the 545 Private Key Generator of the district. If the PKG is 546 publicly accessible, this extension SHOULD be present to 547 allow the automatic retrieval of private keys for 548 recipients of encrypted messages. For this extension the 549 OCTET STRING is an IA5String containing the URI of the 550 key server. 552 ibeParamExt OBJECT IDENTIFIER ::= { 553 ibcs ibcs3(3) parameter-extensions(2) 554 } 556 pkgURI OBJECT IDENTIFIER ::= { ibeParamExt pkgURI(1) } 558 4. Private Key Request Protocol 560 4.1. Overview 562 In an identity-based encryption (IBE) system messages are 563 encrypted using a public key that is locally calculated 564 from public parameters and a user`s identity and 565 decrypted using a private key that corresponds to the 566 user`s public key. These private keys are generated by a 567 private key generator (PKG) based on a global secret 568 called a master secret. 570 When requesting a private key, a client has to transmit 571 two parameters: 573 1. The identity for which it is requesting a key 575 2. Authentication credentials for the individual 576 requesting the key 578 These two are often not the same as a single user may 579 have access to multiple aliases. For example an email 580 user may have access to the keys that correspond to two 581 different email addresses, e.g. bob@example.com and 582 bob.smith@example.com. 584 This section defines the protocol to request private 585 keys, a minimum user authentication method for 586 interoperability, and how to pass authentication 587 credentials to the server. It assumes that a client has 588 already determined the URI of the PKG. This can be done 589 from hints included in the IBE message format [IBECMS] 590 and the system parameters of the IBE system. 592 4.2. Private Key Request 594 To request a private key, a client performs a HTTP POST 595 method as defined in [HTTP]. The request MUST happen over 596 a secure protocol. The requesting client MUST support TLS 597 1.1 [TLS] or its successors, using the latest version 598 supported by both the client and the PKG. When requesting 599 the URI the client MUST verify the server certificate 600 [HTTPTLS], and MUST abort the key request if the server 601 certificate verification of the TLS connection fails. 602 Doing so is critical to protect the authentication 603 credentials and the private key against man-in-the-middle 604 attacks when it is transmitted from the key server to the 605 client. 607 4.3. Request Structure 609 The POST method contains in its body the following XML 610 structure that MUST be encoded as an 611 application/xhtml+xml MIME type [XHTML]: 613 614 615 616 617 618 619 620 algorithmOID 621 622 623 ibeIdentityInfo 624 625 626 627 629 A SHOULD include a element, 630 an ASCII string that identifies the client type and 631 client version. 633 A key request MUST contain a valid ibeIdentityInfo that 634 the private key is requested for. This identity is the 635 base64 encoding of the DER encoding [DER] of the 636 structure IBEIdentityInfo, an example of which is defined 637 in [IBECMS]. 639 A key request MUST contain a element 640 that contains a DER-encoded [DER] OBJECT IDENTIFIER that 641 identifies the algorithm for which a key is requested. 642 OIDs for the BB1 and BF algorithms are listed in [IBCS]. 644 A client MAY include optional additional XML elements in 645 the part of the key request. 647 4.4. Authentication 649 When a client requests a key from a PKG, the PKG SHOULD 650 authenticate the client before issuing the key. 651 Authentication may either be done through the key request 652 structure or as part of the secure transport protocol. 654 A client or server implementing the request protocol MUST 655 support HTTP Basic Auth as described in [AUTH]. A client 656 and server SHOULD also support HTTP Digest Auth as 657 defined in [AUTH]. 659 For authentication methods that are not done by the 660 transport protocol, a client MAY include additional 661 authentication information in xml elements in the body 662 part of the key request. If a client does not know how to 663 authenticate to a server, the client MAY send a key 664 request without authentication information. If the key 665 server requires the client to authenticate externally, it 666 MAY reply with a 201 response code as defined below to 667 redirect the client to the correct authentication 668 mechanism. 670 4.5. Server Response Format 672 The key server replies to the HTTP request with an HTTP 673 response. If the response contains a client error or 674 server error status code, the client MUST abort the key 675 request and fail. 677 If the PKG replies with a HTTP response that has a status 678 code indicating success, the body of the reply MUST 679 contain the following XML structure that MUST be encoded 680 as an application/xhtml+xml MIME type [XHTML]: 682 683 684 685 bodyTags 686 687 689 The responseCode describes the type of response from the 690 key server. The list of currently defined response codes 691 is: 693 100 KEY_FOLLOWS 694 101 RESERVED 695 201 FOLLOW_ENROLL_URI 696 300 SYSTEM_ERROR 697 301 INVALID_REQUEST 698 303 CLIENT_OBSOLETE 699 304 AUTHORIZATION DENIED 701 4.6. Response Containing a Private Key 703 If the key request was successful, the key server 704 responds with KEY FOLLOWS, and the must 705 contain a tag with a valid private key. 706 An example of this is shown below. 708 709 710 711 712 privateKey 713 714 715 717 The privateKey is the Base64 [B64] encoding of the DER 718 encoding [DER] of the following structure: 720 IBEPrivateKeyReply ::= SEQUENCE { 721 pkgIdentity IBEIdentityInfo, 722 pgkAlgorithm OBJECT IDENTIFIER, 723 pkgKeyData OCTET STRING, 724 pkgOptions SEQUENCE SIZE (1..MAX) OF PKGOption 725 } 727 PKGOption ::= SEQUENCE { 728 optionID OBJECT IDENTIFIER, 729 critical BOOLEAN DEFAULT FALSE, 730 optionValue OCTET STRING 731 } 733 The pkgIdentity is an IBEIdentityInfo structure as 734 defined in [IBECMS]. It MUST be identical to the 735 IBEIdentityInfo structure that was sent in the key 736 request. 738 The pkgAlgorithm is an OID that identifies the algorithm 739 of the returned private key. The OIDs for the BB and BF 740 algorithms are defined in [IBCS]. 742 The pkgKeyData is a structure that contains the actual 743 private key. Private-key formats for the BB and BF 744 algorithms are defined in [IBCS]. 746 A server MAY pass back additional information to a client 747 in the pkgOptions structure. 749 4.7. Responses Containing a Redirect 751 A Key Server MAY support authenticating user to external 752 authentication mechanism. If this is the case, the server 753 replies to the client with response code 201 and the body 754 MUST contain a element that specifies the 755 URI of the authentication mechanism. Such a response MUST 756 be encoded as an application/xhtml+xml MIME type [XHTML]. 757 An example of such a response is shown below. 759 760 761 762 764 765 767 The client can now contact the authentication mechanism 768 to obtain authentication credentials. Once the client has 769 obtained the credential, it sends a new key request to 770 the PKG with the correct authentication credentials 771 contained in the request. 773 4.8. Responses Indicating an Error 775 If the server replies with an error code from 300 through 776 399, the client MUST abort the request and discard any 777 data that is part of the response. 779 The meaning of the response codes for errors is as 780 follows: 782 300 - This indicates an internal server error of the PKG. 784 301 - The request to the server is invalid or the server 785 is not able to fulfill this type of request. 787 303 - The server is not able to serve key requests for 788 this type of client. A client with a newer version of the 789 protocol is required. 791 304 - The key request was processed correctly, but the 792 authentication credentials provided by the user were 793 invalid, could not be verified, or do not allow access to 794 keys for this identity. 796 5. ASN.1 Module 798 The following ASN.1 module summarizes the ASN.1 799 definitions discussed in this document. 801 IBEARCH-module { joint-iso-itu-t(2) country(16) us(840) 802 organization(1) identicrypt(114334) ibcs(1) ibearch(5) 803 module(5) version(1) 804 } 806 DEFINITIONS IMPLICIT TAGS ::= BEGIN 808 IBESysParams ::= SEQUENCE { 809 version INTEGER { v2(2) }, 810 districtName IA5String, 811 districtSerial INTEGER, 812 validity ValidityPeriod, 813 ibePublicParameters IBEPublicParameters, 814 ibeIdentitySchema OBJECT IDENTIFIER, 815 ibeParamExtensions IBEParamExtensions OPTIONAL 816 } 818 ValidityPeriod ::= SEQUENCE { 819 notBefore GeneralizedTime, 820 notAfter GeneralizedTime 821 } 823 IBEPublicParameters ::= SEQUENCE (1..MAX) OF 824 IBEPublicParameter 826 IBEPublicParameter ::= SEQUENCE { 827 ibeAlgorithm OBJECT IDENTIFIER, 828 publicParameterData OCTET STRING 829 } 831 IBEParamExtensions ::= SEQUENCE OF IBEParamExtension 833 IBEParamExtension ::= SEQUENCE { 834 ibeParamExtensionOID OBJECT IDENTIFIER, 835 ibeParamExtensionValue OCTET STRING 836 } 838 ibcs OBJECT IDENTIFIER ::= { 839 joint-iso-itu-t(2) country(16) us(840) 840 organization(1) identicrypt(114334) ibcs(1) 841 } 843 ibeParamExt OBJECT IDENTIFIER ::= { 844 ibcs ibcs3(3) parameter-extensions(2) 845 } 847 pkgURI OBJECT IDENTIFIER ::= { ibeParamExt pkgURI(1) } 848 IBEPrivateKeyReply ::= SEQUENCE { 849 pkgIdentity IBEIdentityInfo, 850 pgkAlgorithm OBJECT IDENTIFIER, 851 pkgKeyData OCTET STRING, 852 pkgOptionsSEQUENCE SIZE (1..MAX) OF PKGOption 853 } 855 PKGOption ::= SEQUENCE { 856 optionID OBJECT IDENTIFIER, 857 critical BOOLEAN DEFAULT FALSE, 858 optionValue OCTET STRING 859 } 861 END 863 6. Security Considerations 865 6.1. Attacks that are outside the scope of this document 867 Attacks on the cryptographic algorithms that are used to 868 implement IBE are outside the scope of this document. 869 Such attacks are detailed in [IBCS], which defines 870 parameters that give 80-bit, 112-bit and 128-bit 871 encryption strength. We assume that capable 872 administrators of an IBE system will select parameters 873 that provide a sufficient resistance to cryptanalytic 874 attacks by adversaries. 876 Attacks that give an adversary the ability to access or 877 change the information on a PPS or PKG, especially the 878 cryptographic material (referred to in this document as 879 the master secret), will defeat the security of an IBE 880 system. In particular, if the cryptographic material is 881 compromised the adversary will have the ability to 882 recreate any user's private key and therefore decrypt all 883 messages protected with the corresponding public key. To 884 address this concern, it is highly RECOMMENDED that best 885 practices for physical and operational security for PPS 886 and PKG servers be followed and that these servers be 887 configured (sometimes known as hardened) in accordance 888 with best current practices [NIST]. An IBE system SHOULD 889 be operated in an environment where illicit access is 890 infeasible for attackers to obtain. 892 Attacks that require administrative or IBE user 893 equivalent access to machines used by either the client 894 or the server components defined in this document are 895 also outside the scope of this document. 897 We also assume that all administrators of a system 898 implementing the protocols that are defined in this 899 document are trustworthy and will not abuse their 900 authority to bypass the security provided by an IBE 901 system. Similarly, we assume that users of an IBE system 902 will behave responsibly, not sharing their authentication 903 credentials with others. Thus attacks that require such 904 assumptions are outside the scope of this document. 906 6.2. Attacks that are within the scope of this document 908 Attacks within the scope of this document are those that 909 allow an adversary to: 911 o passively monitor information transmitted 912 between users of an IBE system and the PPS and 913 PKG 915 o masquerade as a PPS or PKG 917 o perform a DOS attack on a PPS or PKG 919 o easily guess an IBE users authentication 920 credential 922 6.2.1. Attacks to which the protocols defined in this 923 document are susceptible 925 All communications between users of an IBE system and the 926 PPS or PKG are protected using TLS 1.1 [TLS]. The IBE 927 system defined in this document provides no additional 928 security protections for the communications between IBE 929 users and the PPS or PKG. Therefore the described IBE 930 system is completely dependent on the TLS security 931 mechanisms for authentication of the PKG or PPS server 932 and for confidentiality and integrity of the 933 communications. Should there be a compromise of the TLS 934 security mechanisms, the integrity of all communications 935 between an IBE user and the PPS or PKG will be suspect. 937 The protocols defined in this document do not explicitly 938 defend against an attacker masquerading as a legitimate 939 IBE PPS or PKG. The protocols rely on the server 940 authentication mechanism of TLS [TLS]. In addition to the 941 TLS server authentication mechanism IBE client software 942 can provide protection against this possibility by 943 providing user interface capabilities that allows users 944 to visually determine that a connection to PPS and PKG 945 servers is legitimate. This additional capability can 946 help ensure that users cannot easily be tricked into 947 providing valid authorization credentials to an attacker. 949 The protocols defined in this document are also 950 vulnerable to attacks against an IBE PPS or PKG. Denial 951 of service attacks against either component can result in 952 users unable to encrypt or decrypt using IBE, and users 953 of an IBE system SHOULD take the appropriate 954 countermeasures [DOS, BGPDOS] that their use of IBE 955 requires. 957 The IBE user authentication method selected by an IBE PKG 958 SHOULD be of sufficient strength to prevent attackers 959 from easily guessing the IBE user's authentication 960 credentials through trial and error. 962 7. IANA Considerations 964 The XML defined in this document will be registered with 965 the IANA per the instructions in RFC 3688, The IETF XML 966 Registry. 968 URI: 970 urn:ietf:params:xml:ns:ibe 972 Registrant Contact: 974 Luther Martin 975 Voltage Security 976 1070 Arastradero Rd Suite 100 977 Palo Alto CA 94304 979 Phone: +1 650 543 1280 980 Email: martin@voltage.com 982 XML: 984 BEGIN 985 986 987 988 989 990 991 992 algorithmOID 993 994 995 ibeIdentityInfo 996 997 998 999 1001 1002 1003 1004 bodyTags 1005 1006 1007 END 1009 8. References 1011 8.1. Normative References 1013 [ASN1] ITU-T Recommendation X.680: Information Technology 1014 - Abstract Syntax Notation One, 1997. 1016 [AUTH] J. Franks, et al., "HTTP Authentication: Basic and 1017 Digest Access Authentication", RFC 2617, June 1999. 1019 [B64] N. Freed and N. Borenstein, Multipurpose Internet 1020 Mail Extensions(MIME) Part One: Format of Internet 1021 Message Bodies," RFC 2045, November 1996. 1023 [CMS] R. Housley, "Cryptographic Message Syntax," RFC 1024 3852, July 2004. 1026 [DER] CCITT, "Recommendation X.209: Specification of 1027 Basic Encoding Rules for Abstract Syntax Notation 1028 One (ASN.1)," 1998. 1030 [DOM] P. Mockapetris, "Domain Names - Implementation and 1031 Specification," RFC 1035, November 1987. 1033 [DOS] P. Ferguson and D. Senie, "Network Ingress 1034 Filtering: Defeating Denial of Service Attacks 1035 which employ IP Source Address Spoofing," RFC 2827, 1036 BCP 38, May 2000. 1038 [HTTP] R. Fielding, et al., "Hypertext Transfer Protocol 1039 -- HTTP/1.1", RFC 2616, June 1999. 1041 [HTTPTLS] E. Rescorla, "HTTP over TLS," RFC 2818, May 1042 2000. 1044 [KEY] S. Brander, "Key Words for Use in RFCs to Indicate 1045 Requirement Levels," BCP 14, RFC 2119, March 1997. 1047 [MIME] N. Freed and N. Borenstein, "Multipurpose Internet 1048 Mail Extensions (MIME) Part Two: Media Types," RFC 1049 2046, November 1996. 1051 [TEXTMSG] D. Crocker, "Standard for the format of ARPA 1052 internet text messages," RFC 2822, April 2001. 1054 [TLS] T. Dierks and E. Rescorla, "The Transport Layer 1055 Security (TLS) Protocol Version 1.1," RFC 4346, 1056 April 2006. 1058 [URI] T. Berners-Lee, R. Fielding, and L. Masinter, 1059 "Uniform Resource Identifiers (URI): Generic 1060 Syntax", RFC 3986, January 2005. 1062 [XHTML] M. Baker and P. Stark, "The 1063 'application/xhtml+xml' Media Type," RFC 3236, 1064 January 2002. 1066 8.2. Informative References 1068 [BGPDOS] D. Turk, "Configuring BGP to Block Denial-of- 1069 Service Attacks," RFC 3882, September 2004. 1071 [IBCS] X. Boyen and L. Martin, "Identity-Based 1072 Cryptography Standard (IBCS) #1: Supersingular 1073 Curve Implementations of the BF and BB1 1074 Cryptosystems," draft-martin-ibcs-06.txt, September 1075 2007. 1077 [IBECMS] L. Martin and M. Schertler, "Using the Boneh- 1078 Franklin identity-based encryption algorithm with 1079 the Cryptographic Message Syntax (CMS)," draft- 1080 ietf-smime-bfibecms-06.txt, September 2007. 1082 [NIST] M. Souppaya, J. Wack and K. Kent, "Security 1083 Configuration Checklist Program for IT Products - 1084 Guidance for Checklist Users and Developers," NIST 1085 Special Publication SP 800-70, May 2005. 1087 [P1363] IEEE P1363, "Standards Specifications for Public- 1088 Key Cryptography," 2001. 1090 Authors' Addresses 1092 Guido Appenzeller 1093 Voltage Security 1094 1070 Arastradero Rd Suite 100 1095 Palo Alto CA 94304 1097 Phone: +1 650 543 1280 1098 Email: guido@voltage.com 1100 Luther Martin 1101 Voltage Security 1102 1070 Arastradero Rd Suite 100 1103 Palo Alto CA 94304 1104 USA 1106 Phone: +1 650 543 1280 1107 Email: martin@voltage.com 1109 Mark Schertler 1110 Tumbleweed Communications 1111 700 Saginaw Dr 1112 Redwood City CA 94063 1113 USA 1115 Phone: +1 650 216 2039 1116 Email: mark.schertler@tumbleweed.com 1118 Intellectual Property Statement 1120 The IETF takes no position regarding the validity or 1121 scope of any Intellectual Property Rights or other rights 1122 that might be claimed to pertain to the implementation or 1123 use of the technology described in this document or the 1124 extent to which any license under such rights might or 1125 might not be available; nor does it represent that it has 1126 made any independent effort to identify any such rights. 1127 Information on the procedures with respect to rights in 1128 RFC documents can be found in BCP 78 and BCP 79. 1130 Copies of IPR disclosures made to the IETF Secretariat 1131 and any assurances of licenses to be made available, or 1132 the result of an attempt made to obtain a general license 1133 or permission for the use of such proprietary rights by 1134 implementers or users of this specification can be 1135 obtained from the IETF on-line IPR repository at 1136 http://www.ietf.org/ipr. 1138 The IETF invites any interested party to bring to its 1139 attention any copyrights, patents or patent applications, 1140 or other proprietary rights that may cover technology 1141 that may be required to implement this standard. Please 1142 address the information to the IETF at ietf-ipr@ietf.org. 1144 Disclaimer of Validity 1146 This document and the information contained herein are 1147 provided on an "AS IS" basis and THE CONTRIBUTOR, THE 1148 ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF 1149 ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE 1150 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 1151 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 1152 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 1153 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1154 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1156 Copyright Statement 1158 Copyright (C) The IETF Trust (2007). 1160 This document is subject to the rights, licenses and 1161 restrictions contained in BCP 78, and except as set forth 1162 therein, the authors retain all their rights. 1164 Acknowledgment 1166 Funding for the RFC Editor function is currently provided 1167 by the Internet Society.