idnits 2.17.1 draft-ietf-smime-ibearch-05.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 1075. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1049. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1057. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1063. 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 times 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 (September 2007) is 6068 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) ** 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) ** 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) == 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: 7 errors (**), 0 flaws (~~), 5 warnings (==), 7 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: March 2008 Tumbleweed Communications 7 September 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 to 44 generate their 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 Encrypted Using IBE...4 53 2.2.1. Sender Obtains Recipient's Public Parameters5 54 2.2.2. Construct and Send IBE-encrypts Message....6 55 2.3. Receiving and Viewing an IBE-encrypted Message..6 56 2.3.1. Recipient Obtains Public Parameters from PPS7 57 2.3.2. Recipient Obtains IBE Private Key from PKG.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............................13 65 4.3. Request Structure..............................14 66 4.4. Authentication.................................15 67 4.5. Server Response Format.........................15 68 4.6. Response Containing a Private Key..............16 69 4.7. Responses Containing a Redirect................17 70 4.8. Responses Indicating an Error..................17 71 5. Security Considerations.............................18 72 5.1. Attacks that are outside the scope of this 73 document............................................18 74 5.2. Attacks that are within the scope of this 75 document............................................19 76 5.2.1. Attacks to which the protocols defined in 77 this document are susceptible....................19 78 6. IANA Considerations.................................20 79 7. References..........................................21 80 7.1. Normative References...........................21 81 7.2. Informative References.........................22 82 Authors' Addresses.....................................24 83 Intellectual Property Statement........................24 84 Disclaimer of Validity.................................25 85 Copyright Statement....................................25 86 Acknowledgment.........................................25 88 1. Introduction 90 This document describes the security architecture 91 required to implement identity-based encryption, a 92 public-key encryption technology that uses a user's 93 identity as a public key. 95 1.1. Terminology 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 98 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", 99 "MAY", and "OPTIONAL" in this document are to be 100 interpreted as described in [KEY]. 102 2. Identity-based Encryption 104 2.1. Overview 106 Identity-based encryption (IBE) is a public-key 107 encryption technology that allows a public key to be 108 calculated from an identity and the corresponding private 109 key to be calculated from the public key. A public key 110 can be calculated by anyone who has the necessary 111 mathematical parameters that are needed for the 112 calculation; a cryptographic secret is needed to 113 calculate a private key, and the calculation can only be 114 performed by a trusted server which has this secret. 116 Calculation of both the public and private keys in an 117 IBE-based system can occur as needed, resulting in just- 118 in-time key material. This contrasts with other public- 119 key systems [P1363], in which keys are generated randomly 120 and distributed prior to secure communication commencing. 121 The ability to calculate a recipient's public key, in 122 particular, eliminates the need for the sender and 123 receiver in an IBE-based messaging system to interact 124 with each other, either directly or through a proxy such 125 as a directory server, before sending secure messages. 127 This document describes an IBE-based messaging system and 128 how the components of the system work together. The 129 components required for a complete IBE messaging system 130 are the following: 132 o A Private-key Generator (PKG). The PKG contains 133 the cryptographic material, known as a master 134 secret, for generating an individual's IBE 135 private key. A PKG accepts an IBE user's private 136 key request and after successfully 137 authenticating them in some way returns the IBE 138 private key. 140 o A Public Parameter Server (PPS). IBE System 141 Parameters include publicly sharable 142 cryptographic material, known as IBE public 143 parameters, and policy information for the PKG. 144 A PPS provides a well-known location for secure 145 distribution of IBE public parameters and policy 146 information for the IBE PKG. 148 A logical architecture would be to have a PKG/PPS per a 149 name space, such as a DNS zone. The organization that 150 controls the DNS zone would also control the PKG/PPS and 151 thus the determination of which PKG/PSS to use when 152 creating public and private keys for the organization's 153 members. In this case the PPS URI can be uniquely created 154 by the form of the identity that it supports. This 155 architecture would make it clear which set of public 156 parameters to use and where to retrieve them for a given 157 identity (i.e. an RFC 2822 address [TEXTMSG]). 159 IBE encrypted messages can use standard message formats, 160 such as the Cryptographic Message Syntax [CMS]. How to 161 use IBE with CMS is defined in [IBECMS]. Unless 162 explicitly noted otherwise, all ASN.1 [DER] structures in 163 this document are defined in the ASN.1 module of 164 [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 Encrypted Using IBE 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 The recipient's IBE public parameters allow the 178 creation of unique public and private keys. A user 179 of an IBE system is capable of calculating the 180 public key of a recipient after he obtains the 181 public parameters for their IBE system. Once the 182 public parameters are obtained, IBE-encrypted 183 messages can be sent. 185 2. Construct and Send IBE-encrypted Message 187 All that is needed, in addition to the IBE public 188 parameters, is the recipient's identity in order to 189 generate their public key for use in encrypting 190 messages to them. When this identity is the same as 191 the identity that a message would be addressed to, 192 then no more information is needed from a user to 193 send someone a secure message then is needed to 194 send them an unsecured message. This is one of the 195 major benefits of an IBE-based secure messaging 196 system. Examples of identities can be an 197 individual, group, or role identifiers. 199 2.2.1. Sender Obtains Recipient's Public Parameters 201 The sender of a message obtains the IBE public parameters 202 that he needs for calculating the IBE public key of the 203 recipient from a PPS that is hosted at a well-known URI. 204 The IBE public parameters contain all of the information 205 that the sender needs to create an IBE-encrypted message 206 except for the identity of the recipient. Section 3 of 207 this document describes the URI [URI] where a PPS is 208 located, the format of IBE public parameters, and how to 209 obtain them. The URI from which users obtain IBE public 210 parameters MUST be authenticated in some way; PPS servers 211 MUST support TLS 1.1 [TLS] to satisfy this requirement. 212 Section 3 also describes the way in which identity 213 formats are defined and a minimum interoperable format 214 that all PPSs and PKGs MUST support. This step is shown 215 below in Figure 1. 217 IBE Public Parameter Request 218 -----------------------------> 219 Sender PPS 220 <----------------------------- 221 IBE Public Parameters 223 Figure 1 Requesting IBE Public Parameters 225 The sender of an IBE-encrypted message selects the PPS 226 and corresponding PKG based on his local security policy. 227 Different PPSs may provide public parameters that specify 228 different IBE algorithms or different key strengths, for 229 example, or require the use of PKGs that require 230 different levels of authentication before granting IBE 231 private keys. 233 2.2.2. Construct and Send IBE-encrypts Message 235 To IBE-encrypt a message, the sender chooses a content- 236 encryption key key (CEK) and uses it to encrypt his 237 message and then encrypts the CEK with the recipient's 238 IBE public key as described in [CMS]. This operation is 239 shown below in Figure 2. [IBCS] describes the algorithms 240 needed to implement two forms of IBE and [IBECMS] 241 describes how to use the Cryptographic Message Syntax 242 (CMS) to encapsulate the encrypted message along with the 243 IBE information that the recipient needs to decrypt the 244 message. 246 CEK ----> Sender ----> IBE-encrypted CEK 248 ^ 249 | 250 | 252 Recipient's Identity 253 and IBE Public Parameters 255 Figure 2 Using an IBE Public-key Algorithm to Encrypt 257 2.3. Receiving and Viewing an IBE-encrypted Message 259 In order to read an encrypted message, a recipient of an 260 IBE-encrypted message parses the message as described in 261 [IBECMS]. This gives him the URI he needs to obtain the 262 IBE public parameters required to perform IBE 263 calculations as well as the identity that was used to 264 encrypt the message. Next the recipient must carry out 265 the following steps: 267 1. Obtain the recipient's public parameters 269 An IBE system's public parameters allow it to 270 uniquely create public and private keys. The 271 recipient of an IBE-encrypted message can decrypt 272 an IBE-encrypted message if he has both the IBE 273 public parameters and the necessary IBE private 274 key. The PPS can also provide the URI of the PKG 275 where the recipient of an IBE-encrypted message can 276 obtain the IBE private keys. 278 2. Obtain the IBE private key from the PKG 280 To decrypt an IBE-encrypted message, in addition to 281 the IBE public parameters the recipient needs to 282 obtain the private key that corresponds to the 283 public key that the sender used. The IBE private 284 key is obtained after successfully authenticating 285 to a private key generator (PKG), a trusted third 286 party that calculates private keys for users. The 287 recipient receives the IBE private key over an 288 HTTPS connection. 290 3. Decrypt IBE-encrypted message 292 The IBE private key decrypts the CEK (see section 293 2.2.2). The CEK is then used to decrypt encrypted 294 message. 296 The PKG may allow users other than the intended recipient 297 to receive some IBE private keys. Giving a mail filtering 298 appliance permission to obtain IBE private keys on behalf 299 of users, for example, can allow the appliance to decrypt 300 and scan encrypted messages for viruses or other 301 malicious features. 303 2.3.1. Recipient Obtains Public Parameters from PPS 305 Before he can perform any IBE calculations related to the 306 message that he has received, the recipient of an IBE- 307 encrypted message needs to obtain the IBE public 308 parameters that were used in the encryption operation. 309 This operation is shown below in Figure 3. The comments 310 in Section 2.2.1 also apply to this operation. 312 IBE Public Parameter Request 313 -----------------------------> 314 Recipient PPS 315 <----------------------------- 316 IBE Public Parameters 318 Figure 3 Requesting IBE Public Parameters 320 2.3.2. Recipient Obtains IBE Private Key from PKG 322 To obtain an IBE private key, the recipient of an IBE- 323 encrypted message provides the IBE public key used to 324 encrypt the message and their authentication credentials 325 to a PKG and requests the private key that corresponds to 326 the IBE public key. Section 4 of this document defines 327 the protocol for communicating with a PKG as well as a 328 minimum interoperable way to authenticate to a PKG that 329 all IBE implementations MUST support. Because the 330 security of IBE private keys is vital to the overall 331 security of an IBE system, IBE private keys MUST be 332 transported to recipients over a secure protocol. PKGs 333 MUST support TLS 1.1 [TLS] or its successors, using the 334 latest version supported by both parties, for transport 335 of IBE private keys. This operation is shown below in 336 Figure 4. 338 IBE Private Key Request 339 ----------------------------> 340 Recipient PKG 341 <---------------------------- 342 IBE Private Key 344 Figure 4 Obtaining an IBE Private Key 346 2.3.3. Recipient Decrypts IBE-encrypted Message 348 After obtaining the necessary IBE private key, the 349 recipient uses that IBE private key and the corresponding 350 IBE public parameters to decrypt the CEK. This operation 351 is shown below in Figure 5. He then uses the CEK to 352 decrypt the encrypted message content as specified in 353 [IBECMS]. 355 IBE-encrypted CEK ----> Recipient ----> CEK 357 ^ 358 | 359 | 361 IBE Private Key 362 and IBE Public Parameters 364 Figure 5 Using an IBE Public-key Algorithm to Decrypt 366 3. Public Parameter Lookup 368 For an identity-based encryption (IBE) system to operate, 369 the sender, receiver and the private key generator (PKG) 370 must agree on a number of parameters, specifically: 372 1. The Public Parameters of the PKG. The public 373 parameters are part of the encryption (and in some 374 cases decryption) operation of the IBE system. 375 Generation of public parameters and the master 376 secret, as well as the mathematical structure of the 377 public parameters for the BF and BB1 algorithms are 378 described in [IBCS]. 380 2. The URI of the PKG. Knowledge of this URI allows 381 recipients to request a private key as described in 382 Section 4 of this document. 384 3. The schema to format the identity strings. When 385 issuing a private key, the PKG often wants to limit 386 who can obtain private keys. For example for an 387 identity string that contains "bob@example.com", 388 only the owner of the identity string should be able 389 to request the private key. To ensure that the PKG 390 can interpret the identity string for which a 391 private key is requested, the encryption engine and 392 the PKG have to use the same schema for identity 393 strings. Identity schemas are described in [IBECMS] 395 This section specifies how a component of an IBE system 396 can retrieve these parameters. A sending or receiving 397 client MUST allow configuration of these parameters 398 manually, e.g. through editing a configuration file. 399 However for simplified configuration a client MAY also 400 implement the PP URI request method described in this 401 document to fetch the system parameters based on a 402 configured URI. This is especially useful for federating 403 between IBE systems. By specifying a single URI a client 404 can be configured to fetch all the relevant parameters 405 for a remote PKG. These public parameters can then be 406 used to encrypt messages to recipients who authenticate 407 to and retrieve private keys from that PKG. 409 The following section outlines the URI request method to 410 retrieve a parameter block and describes the structure of 411 the parameter block itself. 413 3.1. Request Method 415 The configuration URI SHOULD be an HTTPS URI [HTTP] of 416 the format: 418 http_URI = "https:" "//" host [ ":" port ] [ abs_path ] 420 An example URI for ibe system parameters is 422 https://ibe-0000.example.com/example.com.pp 424 To retrieve the IBE system parameters, the client SHOULD 425 use the HTTP GET method as defined in [HTTP]. The request 426 MUST happen over a secure protocol. The requesting client 427 MUST support TLS 1.1 [TLS] or its successors and SHOULD 428 use the latest version supported by both parties. When 429 requesting the URI the client MUST only accept the system 430 parameter block if the server identity was verified 431 successfully by TLS 1.1 [TLS] or its successors. 433 A successful GET request returns in its body the Base64 434 encoding of the DER-encoded [DER] IBESysParams structure 435 that is described in the next section. This structure 436 MUST be served as an application/octet-stream MIME type 437 [MIME]. 439 3.2. Parameter and Policy Format 441 The IBE System parameters are a set of 443 IBESysParams ::= SEQUENCE { 444 version INTEGER { v2(2) }, 445 districtName UTF8String, 446 districtSerial INTEGER, 447 validity ValidityPeriod, 448 ibePublicParameters IBEPublicParameters, 449 ibeIdentitySchema OBJECT IDENTIFIER, 450 ibeParamExtensions IBEParamExtensions OPTIONAL 451 } 453 The version specifies the version of the IBESysParams 454 format. For the format described in this document it MUST 455 be set to 2. The district name is an UTF8String that MUST 456 be a valid domain name as defined by [DOM]. The 457 districtSerial is a serial number that represents a 458 unique set of IBE public parameters. If new parameters 459 are published for a district, it MUST be increased to a 460 number greater than the previously-used serial number. 462 The validity period or lifetime of a specific instance of 463 the IBESysParams is defined as follows: 465 ValidityPeriod ::= SEQUENCE { 466 notBefore GeneralizedTime, 467 notAfter GeneralizedTime 468 } 470 A client MUST verify that the date on which it utilizes 471 the IBE system parameters falls between the notBefore 472 time and the notAfter times of the IBE system parameters 473 and SHOULD not use the parameters if they do not. 475 IBE system parameters MUST be regenerated and republished 476 whenever the ibePublicParameters, ibeIdentitySchema, or 477 ibeParamExtensions change for a district. A client SHOULD 478 refetch the IBE system parameters at an application 479 configurable interval to ensure that it has the most 480 current version on the IBE system parameters. 482 It is possible to create identities for use in IBE that 483 have a time component, as described in [IBECMS]. If such 484 an identity is used, the time component of the identity 485 MUST fall between the notBefore time and the notAfter 486 times of the IBE system parameters. 488 IBEPublicParameters is a set of public parameters that 489 correspond to IBE algorithms that the PKG associated with 490 this district understands. 492 IBEPublicParameters ::= SEQUENCE (1..MAX) OF 493 IBEPublicParameter 495 IBEPublicParameter ::= SEQUENCE { 496 ibeAlgorithm OBJECT IDENTIFIER, 497 publicParameterData OCTET STRING 498 } 500 The ibeAlgorithm OID specifies an IBE algorithm. The 501 publicParameterData is a DER-encoded [DER] ASN.1 502 structure that contains the actual cryptographic 503 parameters. Its specific structure depends on the 504 algorithm. The OIDs for two IBE algorithms, the Boneh- 505 Franklin and Boneh-Boyen algorithms and their 506 publicParameterData structures are defined in [IBCS]. 508 The IBESysParams of a district MUST contain at least one 509 algorithm and MAY contain several algorithms. It MUST NOT 510 contain two or more IBEPublicParameter entries with the 511 same algorithm. A client that wants to use IBESysParams 512 can chose any of the algorithms specified in the 513 publicParameterData structure. A client MUST implement at 514 least the Boneh-Franklin algorithm and MAY implement the 515 Boneh-Boyen and other algorithms. If a client does not 516 support any of the supported algorithms it MUST generate 517 an error message and fail. 519 ibeIdentitySchema is an OID that defines the type of 520 identities that are used with this district. The OIDs and 521 the required and optional fields for each OID are 522 described in [IBECMS]. 524 IBEParamExtensions is a set of extensions that can be 525 used to define additional parameters that particular 526 implementations may require. 528 IBEParamExtensions ::= SEQUENCE OF IBEParamExtension 530 IBEParamExtension ::= SEQUENCE { 531 ibeParamExtensionOID OBJECT IDENTIFIER, 532 ibeParamExtensionValue OCTET STRING 533 } 535 The contents of the octet string are defined by the 536 specific extension type. The System Parameters of a 537 district MAY have any number of extensions, including 538 zero. 540 The IBEParamExtension pkgURI defines the URI of the 541 Private Key Generator of the district. If the PKG is 542 publicly accessible, this extension SHOULD be present to 543 allow the automatic retrieval of private keys for 544 recipients of encrypted messages. For this extension the 545 OCTET STRING contains a UTF8String with the URI of the 546 key server. 548 ibeParamExt OBJECT IDENTIFIER ::= { 549 ibcs ibcs3(3) parameter-extensions(2) 550 } 552 pkgURI OBJECT IDENTIFIER ::= { ibeParamExt pkgURI(1) } 554 4. Private Key Request Protocol 556 4.1. Overview 558 In an identity-based encryption (IBE) system messages are 559 encrypted using a public key that is locally calculated 560 from public parameters and a user`s identity and 561 decrypted using a private key that corresponds to the 562 user`s public key. These private keys are generated by a 563 private key generator (PKG) based on a global secret 564 called a master secret. 566 When requesting a private key, a client has to transmit 567 two parameters: 569 1. The identity for which it is requesting a key 571 2. Authentication credentials for the individual 572 requesting the key 574 These two are often not the same as a single user may 575 have access to multiple aliases. For example an email 576 user may have access to the keys that correspond to two 577 different email addresses, e.g. bob@example.com and 578 bob.smith@example.com. 580 This section defines the protocol to request private 581 keys, a minimum user authentication method for 582 interoperability, and how to pass authentication 583 credentials to the server. It assumes that a client has 584 already determined the URI of the PKG. This can be done 585 from hints included in the IBE message format [IBECMS] 586 and the system parameters of the IBE system. 588 4.2. Private Key Request 590 To request a private key, a client performs a HTTP POST 591 method as defined in [HTTP]. The request MUST happen over 592 a secure protocol. The requesting client MUST support TLS 593 1.1 [TLS] or its successors, using the latest version 594 supported by both the client and the PKG. When requesting 595 the URI the client MUST verify the server certificate 596 [HTTPTLS], and MUST abort the key request if the server 597 certificate verification of the TLS connection fails. 598 Doing so is critical to protect the authentication 599 credentials and the private key against man-in-the-middle 600 attacks when it is transmitted from the key server to the 601 client. 603 4.3. Request Structure 605 The POST method contains in its body the following XML 606 structure that MUST be encoded as an 607 application/xhtml+xml MIME type [XHTML]: 609 610 611 612 613 614 615 616 algorithmOID 617 618 619 ibeIdentityInfo 620 621 622 623 625 A SHOULD include a element, 626 an ASCII string that identifies the client type and 627 client version. 629 A key request MUST contain a valid ibeIdentityInfo that 630 the private key is requested for. This identity is the 631 base64 encoding of the DER encoding [DER] of the ASN.1 632 structure IBEIdentityInfo as defined in [IBECMS]. 634 A key request MUST contain a element 635 that contains a XER [XER] encoded ASN.1 OBJECT IDENTIFIER 636 [DER] that identifies the algorithm for which a key is 637 requested. OIDs for the BB1 and BF algorithms are listed 638 in [IBCS]. 640 A client MAY include optional additional XML elements in 641 the part of the key request. 643 4.4. Authentication 645 When a client requests a key from a PKG, the PKG SHOULD 646 authenticate the client before issuing the key. 647 Authentication may either be done through the key request 648 structure or as part of the secure transport protocol. 650 A client or server implementing the request protocol MUST 651 support HTTP Basic Auth as described in [AUTH]. A client 652 and server SHOULD also support HTTP Digest Auth as 653 defined in [AUTH]. 655 For authentication methods that are not done by the 656 transport protocol, a client MAY include additional 657 authentication information in xml elements in the body 658 part of the key request. If a client does not know how to 659 authenticate to a server, the client MAY send a key 660 request without authentication information. If the key 661 server requires the client to authenticate externally, it 662 MAY reply with a 201 response code as defined below to 663 redirect the client to the correct authentication 664 mechanism. 666 4.5. Server Response Format 668 The key server replies to the HTTP request with an HTTP 669 response. If the response contains a client error or 670 server error status code, the client MUST abort the key 671 request and fail. 673 If the PKG replies with a HTTP response that has a status 674 code indicating success, the body of the reply MUST 675 contain the following XML structure that MUST be encoded 676 as an application/xhtml+xml MIME type [XHTML]: 678 679 680 681 bodyTags 682 683 684 The responseCode describes the type of response from the 685 key server. The list of currently defined response codes 686 is: 688 100 KEY_FOLLOWS 689 101 RESERVED 690 201 FOLLOW_ENROLL_URI 691 300 SYSTEM_ERROR 692 301 INVALID_REQUEST 693 303 CLIENT_OBSOLETE 694 304 AUTHORIZATION DENIED 696 4.6. Response Containing a Private Key 698 If the key request was successful, the key server 699 responds with KEY FOLLOWS, and the must 700 contain a tag with a valid private key. 701 An example of this is shown below. 703 704 705 706 707 privateKey 708 709 710 712 The privateKey is the Base64 [B64] encoding of the DER 713 encoding [DER] of the following ASN.1 structure: 715 IBEPrivateKeyReply ::= SEQUENCE { 716 pkgIdentity IBEIdentityInfo, 717 pgkAlgorithm OBJECT IDENTIFIER 718 pkgKeyData OCTET STRING 719 pkgOptions SEQUENCE OF Extensions 720 } 722 The pkgIdentity is an IBEIdentityInfo structure as 723 defined in [IBECMS]. It MUST be identical to the 724 IBEIdentityInfo structure that was sent in the key 725 request. 727 The pkgAlgorithm is an OID that identifies the algorithm 728 of the returned private key. The OIDs for the BB and BF 729 algorithms are defined in [IBCS]. 731 The pkgKeyData is an ASN.1 [DER] structure that contains 732 the actual private key. Private-key formats for the BB 733 and BF algorithms are defined in [IBCS]. 735 A server MAY pass back additional information to a client 736 in the pkgOptions structure. The contents of the 737 structure are defined in the ASN.1 module below. 739 4.7. Responses Containing a Redirect 741 A Key Server MAY support authenticating user to external 742 authentication mechanism. If this is the case, the server 743 replies to the client with response code 201 and the body 744 MUST contain a element that specifies the 745 URI of the authentication mechanism. Such a response MUST 746 be encoded as an application/xhtml+xml MIME type [XHTML]. 747 An example of such a response is shown below. 749 750 751 752 754 755 757 The client can now contact the authentication mechanism 758 to obtain authentication credentials. Once the client has 759 obtained the credential, it sends a new key request to 760 the PKG with the correct authentication credentials 761 contained in the request. 763 4.8. Responses Indicating an Error 765 If the server replies with a 3xx error code, the client 766 MUST abort the request and discard any data that is part 767 of the response. 769 The meaning of the response codes for errors is as 770 follows: 772 300 - This indicates an internal server error of the PKG. 774 301 - The request to the server is invalid or the server 775 is not able to fulfill this type of request. 777 303 - The server is not able to serve key requests for 778 this type of client. A client with a newer version of the 779 protocol is required. 781 304 - The key request was processed correctly, but the 782 authentication credentials provided by the user were 783 invalid, could not be verified, or do not allow access to 784 keys for this identity. 786 5. Security Considerations 788 5.1. Attacks that are outside the scope of this document 790 Attacks on the cryptographic algorithms that are used to 791 implement IBE are outside the scope of this document. 792 Such attacks are detailed in [IBCS], which defines 793 parameters that give 80-bit, 112-bit and 128-bit 794 encryption strength. We assume that capable 795 administrators of an IBE system will select parameters 796 that provide a sufficient resistance to cryptanalytic 797 attacks by adversaries. 799 Attacks that give an adversary the ability to access or 800 change the information on a PPS or PKG, especially the 801 cryptographic material (referred to in this document as 802 the master secret), will defeat the security of an IBE 803 system. In particular, if the cryptographic material is 804 compromised the adversary will have the ability to 805 recreate any user's private key and therefore decrypt all 806 messages protected with the corresponding public key. To 807 address this concern, it is highly RECOMMENDED that best 808 practices for physical and operational security for PPS 809 and PKG servers be followed and that these servers be 810 configured (sometimes known as hardened) in accordance 811 with best current practices [NIST]. An IBE system SHOULD 812 be operated in an environment where illicit access is 813 infeasible for attackers to obtain. 815 Attacks that require administrative or IBE user 816 equivalent access to machines used by either the client 817 or the server components defined in this document are 818 also outside the scope of this document. 820 We also assume that all administrators of a system 821 implementing the protocols that are defined in this 822 document are trustworthy and will not abuse their 823 authority to bypass the security provided by an IBE 824 system. Similarly, we assume that users of an IBE system 825 will behave responsibly, not sharing their authentication 826 credentials with others. Thus attacks that require such 827 assumptions are outside the scope of this document. 829 5.2. Attacks that are within the scope of this document 831 Attacks within the scope of this document are those that 832 allow an adversary to: 834 o passively monitor information transmitted 835 between users of an IBE system and the PPS and 836 PKG 838 o masquerade as a PPS or PKG 840 o perform a DOS attack on a PPS or PKG 842 o easily guess an IBE users authentication 843 credential 845 5.2.1. Attacks to which the protocols defined in this 846 document are susceptible 848 All communications between users of an IBE system and the 849 PPS or PKG are protected using TLS 1.1 [TLS]. The IBE 850 system defined in this document provides no additional 851 security protections for the communications between IBE 852 users and the PPS or PKG. Therefore the described IBE 853 system is completely dependent on the TLS security 854 mechanisms for authentication of the PKG or PPS server 855 and for confidentiality and integrity of the 856 communications. Should there be a compromise of the TLS 857 security mechanisms, the integrity of all communications 858 between an IBE user and the PPS or PKG will be suspect. 860 The protocols defined in this document do not explicitly 861 defend against an attacker masquerading as a legitimate 862 IBE PPS or PKG. The protocols rely on the server 863 authentication mechanism of TLS [TLS]. In addition to the 864 TLS server authentication mechanism IBE client software 865 can provide protection against this possibility by 866 providing user interface capabilities that allows users 867 to visually determine that a connection to PPS and PKG 868 servers is legitimate. This additional capability can 869 help ensure that users cannot easily be tricked into 870 providing valid authorization credentials to an attacker. 872 The protocols defined in this document are also 873 vulnerable to attacks against an IBE PPS or PKG. Denial 874 of service attacks against either component can result in 875 users unable to encrypt or decrypt using IBE, and users 876 of an IBE system SHOULD take the appropriate 877 countermeasures [DOS, BGPDOS] that their use of IBE 878 requires. 880 The IBE user authentication method selected by an IBE PKG 881 SHOULD be of sufficient strength to prevent attackers 882 from easily guessing the IBE user's authentication 883 credentials through trial and error. 885 6. IANA Considerations 887 The XML defined in this document will be registered with 888 the IANA per the instructions in RFC 3688, The IETF XML 889 Registry. 891 URI: 893 urn:ietf:params:xml:ns:ibe 895 Registrant Contact: 897 Luther Martin 898 Voltage Security 899 1070 Arastradero Rd Suite 100 900 Palo Alto CA 94304 902 Phone: +1 650 543 1280 903 Email: martin@voltage.com 905 XML: 907 BEGIN 908 909 910 911 912 913 914 915 algorithmOID 916 917 918 ibeIdentityInfo 919 920 921 922 924 925 926 927 bodyTags 928 929 930 END 932 7. References 934 7.1. Normative References 936 [AUTH] J. Franks, et al., "HTTP Authentication: Basic and 937 Digest Access Authentication", RFC 2617, June 1999. 939 [B64] N. Freed and N. Borenstein, Multipurpose Internet 940 Mail Extensions(MIME) Part One: Format of Internet 941 Message Bodies," RFC 2045, November 1996. 943 [CMS] R. Housley, "Cryptographic Message Syntax," RFC 944 3852, July 2004. 946 [DOM] P. Mockapetris, "Domain Names - Implementation and 947 Specification," RFC 1035, November 1987. 949 [DOS] P. Ferguson and D. Senie, "Network Ingress 950 Filtering: Defeating Denial of Service Attacks 951 which employ IP Source Address Spoofing," RFC 2827, 952 BCP 38, May 2000. 954 [HTTP] R. Fielding, et al., "Hypertext Transfer Protocol 955 -- HTTP/1.1", RFC 2616, June 1999. 957 [HTTPTLS] E. Rescorla, "HTTP over TLS," RFC 2818, May 958 2000. 960 [KEY] S. Brander, "Key Words for Use in RFCs to Indicate 961 Requirement Levels," BCP 14, RFC 2119, March 1997. 963 [MIME] N. Freed and N. Borenstein, "Multipurpose Internet 964 Mail Extensions (MIME) Part Two: Media Types," RFC 965 2046, November 1996. 967 [TEXTMSG] D. Crocker, "Standard for the format of ARPA 968 internet text messages," RFC 2822, April 2001. 970 [TLS] T. Dierks and E. Rescorla, "The Transport Layer 971 Security (TLS) Protocol Version 1.1," RFC 4346, 972 April 2006. 974 [URI] T. Berners-Lee, R. Fielding, and L. Masinter, 975 "Uniform Resource Identifiers (URI): Generic 976 Syntax", RFC 3986, January 2005. 978 7.2. Informative References 980 [BGPDOS] D. Turk, "Configuring BGP to Block Denial-of- 981 Service Attacks," RFC 3882, September 2004. 983 [DER] ITU-T Recommendation X.680: Information Technology 984 - Abstract Syntax Notation One, 1997. 986 [IBCS] X. Boyen and L. Martin, "Identity-Based 987 Cryptography Standard (IBCS) #1: Supersingular 988 Curve Implementations of the BF and BB1 989 Cryptosystems," draft-martin-ibcs-06.txt, September 990 2007. 992 [IBECMS] L. Martin and M. Schertler, "Using the Boneh- 993 Franklin identity-based encryption algorithm with 994 the Cryptographic Message Syntax (CMS)," draft- 995 ietf-smime-bfibecms-06.txt, September 2007. 997 [NIST] M. Souppaya, J. Wack and K. Kent, "Security 998 Configuration Checklist Program for IT Products - 999 Guidance for Checklist Users and Developers," NIST 1000 Special Publication SP 800-70, May 2005. 1002 [P1363] IEEE P1363, "Standards Specifications for Public- 1003 Key Cryptography," 2001. 1005 [XER] ITU-T Recommendation X.693 - Information Technology 1006 - ASN.1 Encoding Rules - XML Encoding Rules (XER), 1007 December 2001. 1009 [XHTML] M. Baker and P. Stark, "The 1010 'application/xhtml+xml' Media Type," RFC 3236, 1011 January 2002. 1013 Authors' Addresses 1015 Guido Appenzeller 1016 Voltage Security 1017 1070 Arastradero Rd Suite 100 1018 Palo Alto CA 94304 1020 Phone: +1 650 543 1280 1021 Email: guido@voltage.com 1023 Luther Martin 1024 Voltage Security 1025 1070 Arastradero Rd Suite 100 1026 Palo Alto CA 94304 1028 Phone: +1 650 543 1280 1029 Email: martin@voltage.com 1031 Mark Schertler 1032 Tumbleweed Communications 1033 700 Saginaw Dr 1034 Redwood City CA 94063 1036 Phone: +1 650 216 2039 1037 Email: mark.schertler@tumbleweed.com 1039 Intellectual Property Statement 1041 The IETF takes no position regarding the validity or 1042 scope of any Intellectual Property Rights or other rights 1043 that might be claimed to pertain to the implementation or 1044 use of the technology described in this document or the 1045 extent to which any license under such rights might or 1046 might not be available; nor does it represent that it has 1047 made any independent effort to identify any such rights. 1048 Information on the procedures with respect to rights in 1049 RFC documents can be found in BCP 78 and BCP 79. 1051 Copies of IPR disclosures made to the IETF Secretariat 1052 and any assurances of licenses to be made available, or 1053 the result of an attempt made to obtain a general license 1054 or permission for the use of such proprietary rights by 1055 implementers or users of this specification can be 1056 obtained from the IETF on-line IPR repository at 1057 http://www.ietf.org/ipr. 1059 The IETF invites any interested party to bring to its 1060 attention any copyrights, patents or patent applications, 1061 or other proprietary rights that may cover technology 1062 that may be required to implement this standard. Please 1063 address the information to the IETF at ietf-ipr@ietf.org. 1065 Disclaimer of Validity 1067 This document and the information contained herein are 1068 provided on an "AS IS" basis and THE CONTRIBUTOR, THE 1069 ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF 1070 ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE 1071 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 1072 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 1073 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 1074 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1075 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1077 Copyright Statement 1079 Copyright (C) The IETF Trust (2007). 1081 This document is subject to the rights, licenses and 1082 restrictions contained in BCP 78, and except as set forth 1083 therein, the authors retain all their rights. 1085 Acknowledgment 1087 Funding for the RFC Editor function is currently provided 1088 by the Internet Society.