G. Appenzeller L. Martin S/MIME Working Group Voltage Security Internet Draft M. Schertler Expires: January 2008 Tumbleweed Communications July 2007 Identity-based Encryption Architecture Status of this Document By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract This document describes the security architecture required to implement identity-based encryption, a public-key encryption technology that uses a user's identity to generate their public key. Appenzeller, et al. Expires January 2008 [Page 1] Internet-Draft IBE Architecture July 2007 Table of Contents 1. Introduction 3 1.1. Terminology 3 2. Identity-based Encryption 3 2.1. Overview 3 2.2. Sending a Message that is Encrypted Using IBE 4 2.2.1. Sender Obtains Recipient's Public Parameters 5 2.2.2. Construct and Send IBE-encrypts Message 6 2.3. Receiving and Viewing an IBE-encrypted Message 6 2.3.1. Recipient Obtains Public Parameters from PPS 7 2.3.2. Recipient Obtains IBE Private Key from PKG 8 2.3.3. Recipient Decrypts IBE-encrypted Message 8 3. Public Parameter Lookup 9 3.1. Request Method 10 3.2. Parameter and Policy Format 10 4. Private Key Request Protocol 13 4.1. Overview 13 4.2. Private Key Request 13 4.3. Request Structure 14 4.4. Authentication 15 4.5. Server Response Format 15 4.6. Response Containing a Private Key 16 4.7. Responses Containing a Redirect 17 4.8. Responses Indicating an Error 17 5. Security Considerations 18 5.1. Attacks that are outside the scope of this document 18 5.2. Attacks that are within the scope of this document 19 5.2.1. Attacks to which the protocols defined in this document are susceptible 19 6. IANA Considerations 20 7. References 21 7.1. Normative References 21 Authors' Addresses 23 Intellectual Property Statement 23 Disclaimer of Validity 24 Copyright Statement 24 Acknowledgment 24 Appenzeller, et al. Expires January 2008 [Page 2] Internet-Draft IBE Architecture July 2007 1. Introduction This document describes the security architecture required to implement identity-based encryption, a public-key encryption technology that uses a user's identity as a public key. 1.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [KEY]. 2. Identity-based Encryption 2.1. Overview Identity-based encryption (IBE) is a public-key encryption technology that allows a public key to be calculated from an identity and the corresponding private key to be calculated from the public key. A public key can be calculated by anyone who has the necessary mathematical parameters that are needed for the calculation; a cryptographic secret is needed to calculate a private key, and the calculation can only be performed by a trusted server which has this secret. Calculation of both the public and private keys in an IBE- based system can occur as needed, resulting in just-in-time key material. This contrasts with other public-key systems [P1363], in which keys are generated randomly and distributed prior to secure communication commencing. The ability to calculate a recipient's public key, in particular, eliminates the need for the sender and receiver in an IBE-based messaging system to interact with each other, either directly or through a proxy such as a directory server, before sending secure messages. This document describes an IBE-based messaging system and how the components of the system work together. The components required for a complete IBE messaging system are the following: Appenzeller, et al. Expires January 2008 [Page 3] Internet-Draft IBE Architecture July 2007 o A Private-key Generator (PKG). The PKG contains the cryptographic material, known as a master secret, for generating an individual's IBE private key. A PKG accepts an IBE user's private key request and after successfully authenticating them in some way returns the IBE private key. o A Public Parameter Server (PPS). IBE System Parameters include publicly sharable cryptographic material, known as IBE public parameters, and policy information for the PKG. A PPS provides a well-known location for secure distribution of IBE public parameters and policy information for the IBE PKG. A logical architecture would be to have a PKG/PPS per a name space, such as a DNS zone. The organization that controls the DNS zone would also control the PKG/PPS and thus the determination of which PKG/PSS to use when creating public and private keys for the organization's members. In this case the PPS URI can be uniquely created by the form of the identity that it supports. This architecture would make it clear which set of public parameters to use and where to retrieve them for a given identity (i.e. an RFC822 address). IBE encrypted messages can use standard message formats, such as the Cryptographic Message Syntax [CMS]. How to use IBE with CMS is defined in [IBECMS]. Unless explicitly noted otherwise, all ASN.1 [DER] structures in this document are defined in the ASN.1 module of [IBECMS]. Note that IBE algorithms are used only for encryption, so if digital signatures are required they will need to be provided by an additional mechanism. 2.2. Sending a Message that is Encrypted Using IBE In order to send an encrypted message, an IBE user must perform the following steps: 1. Obtain the recipient's public parameters The recipient's IBE public parameters allow the creation of unique public and private keys. A user of an IBE system is capable of calculating the public key of a recipient after he obtains the public parameters for their IBE system. Once the public parameters are obtained, IBE-encrypted messages can be sent. Appenzeller, et al. Expires January 2008 [Page 4] Internet-Draft IBE Architecture July 2007 2. Construct and Send IBE-encrypted Message All that is needed, in addition to the IBE public parameters, is the recipient's identity in order to generate their public key for use in encrypting messages to them. When this identity is the same as the identity that a message would be addressed to, then no more information is needed from a user to send someone a secure message then is needed to send them an unsecured message. This is one of the major benefits of an IBE- based secure messaging system. Examples of identities can be an individual, group, or role identifiers. 2.2.1. Sender Obtains Recipient's Public Parameters The sender of a message obtains the IBE public parameters that he needs for calculating the IBE public key of the recipient from a PPS that is hosted at a well-known URI. The IBE public parameters contain all of the information that the sender needs to create an IBE-encrypted message except for the identity of the recipient. Section 3 of this document describes the URI where a PPS is located, the format of IBE public parameters, and how to obtain them. The URI from which users obtain IBE public parameters MUST be authenticated in some way; PPS servers MUST support TLS 1.1 [TLS] to satisfy this requirement. Section 3 also describes the way in which identity formats are defined and a minimum interoperable format that all PPSs and PKGs MUST support. This step is shown below in Figure 1. IBE Public Parameter Request -----------------------------> Sender PPS <----------------------------- IBE Public Parameters Figure 1 Requesting IBE Public Parameters Appenzeller, et al. Expires January 2008 [Page 5] Internet-Draft IBE Architecture July 2007 The sender of an IBE-encrypted message selects the PPS and corresponding PKG based on his local security policy. Different PPSs may provide public parameters that specify different IBE algorithms or different key strengths, for example, or require the use of PKGs that require different levels of authentication before granting IBE private keys. 2.2.2. Construct and Send IBE-encrypts Message To IBE-encrypt a message, the sender chooses a content- encryption key key (CEK) and uses it to encrypt his message and then encrypts the CEK with the recipient's IBE public key as described in [CMS]. This operation is shown below in Figure 2. [IBCS] describes the algorithms needed to implement two forms of IBE and [IBECMS] describes how to use the Cryptographic Message Syntax (CMS) to encapsulate the encrypted message along with the IBE information that the recipient needs to decrypt the message. CEK ----> Sender ----> IBE-encrypted CEK ^ | | Recipient's Identity and IBE Public Parameters Figure 2 Using an IBE Public-key Algorithm to Encrypt 2.3. Receiving and Viewing an IBE-encrypted Message In order to read an encrypted message, a recipient of an IBE- encrypted message parses the message as described in [IBECMS]. This gives him the URI he needs to obtain the IBE public parameters required to perform IBE calculations as well as the identity that was used to encrypt the message. Next the recipient must carry out the following steps: 1. Obtain the recipient's public parameters An IBE system's public parameters allow it to uniquely create public and private keys. The recipient of an IBE- encrypted message can decrypt an IBE-encrypted message if he has both the IBE public parameters and the necessary IBE private key. The PPS can also provide the Appenzeller, et al. Expires January 2008 [Page 6] Internet-Draft IBE Architecture July 2007 URI of the PKG where the recipient of an IBE-encrypted message can obtain the IBE private keys. 2. Obtain the IBE private key from the PKG To decrypt an IBE-encrypted message, in addition to the IBE public parameters the recipient needs to obtain the private key that corresponds to the public key that the sender used. The IBE private key is obtained after successfully authenticating to a private key generator (PKG), a trusted third party that calculates private keys for users. The recipient receives the IBE private key over an HTTPS connection. 3. Decrypt IBE-encrypted message The IBE private key decrypts the CEK (see section 2.2.2). The CEK is then used to decrypt encrypted message. The PKG may allow users other than the intended recipient to receive some IBE private keys. Giving a mail filtering appliance permission to obtain IBE private keys on behalf of users, for example, can allow the appliance to decrypt and scan encrypted messages for viruses or other malicious features. 2.3.1. Recipient Obtains Public Parameters from PPS Before he can perform any IBE calculations related to the message that he has received, the recipient of an IBE- encrypted message needs to obtain the IBE public parameters that were used in the encryption operation. This operation is shown below in Figure 3. The comments in Section 2.2.1 also apply to this operation. IBE Public Parameter Request -----------------------------> Recipient PPS <----------------------------- IBE Public Parameters Figure 3 Requesting IBE Public Parameters Appenzeller, et al. Expires January 2008 [Page 7] Internet-Draft IBE Architecture July 2007 2.3.2. Recipient Obtains IBE Private Key from PKG To obtain an IBE private key, the recipient of an IBE- encrypted message provides the IBE public key used to encrypt the message and their authentication credentials to a PKG and requests the private key that corresponds to the IBE public key. Section 4 of this document defines the protocol for communicating with a PKG as well as a minimum interoperable way to authenticate to a PKG that all IBE implementations MUST support. Because the security of IBE private keys is vital to the overall security of an IBE system, IBE private keys MUST be transported to recipients over a secure protocol. PKGs MUST support TLS 1.1 [TLS] or its successors, using the latest version supported by both parties, for transport of IBE private keys. This operation is shown below in Figure 4. IBE Private Key Request ----------------------------> Recipient PKG <---------------------------- IBE Private Key Figure 4 Obtaining an IBE Private Key 2.3.3. Recipient Decrypts IBE-encrypted Message After obtaining the necessary IBE private key, the recipient uses that IBE private key and the corresponding IBE public parameters to decrypt the CEK. This operation is shown below in Figure 5. He then uses the CEK to decrypt the encrypted message content as specified in [IBECMS]. IBE-encrypted CEK ----> Recipient ----> CEK ^ | | IBE Private Key and IBE Public Parameters Figure 5 Using an IBE Public-key Algorithm to Decrypt Appenzeller, et al. Expires January 2008 [Page 8] Internet-Draft IBE Architecture July 2007 3. Public Parameter Lookup For an identity-based encryption (IBE) system to operate, the sender, receiver and the private key generator (PKG) must agree on a number of parameters, specifically: 1. The Public Parameters of the PKG. The public parameters are part of the encryption (and in some cases decryption) operation of the IBE system. Generation of public parameters and the master secret, as well as the mathematical structure of the public parameters for the BF and BB1 algorithms are described in [IBCS]. 2. The URI of the PKG. Knowledge of this URI allows recipients to request a private key as described in Section 4 of this document. 3. The schema to format the identity strings. When issuing a private key, the PKG often wants to limit who can obtain private keys. For example for an identity string that contains "bob@example.com", only the owner of the identity string should be able to request the private key. To ensure that the PKG can interpret the identity string for which a private key is requested, the encryption engine and the PKG have to use the same schema for identity strings. Identity schemas are described in [IBECMS] This section specifies how a component of an IBE system can retrieve these parameters. A sending or receiving client MUST allow configuration of these parameters manually, e.g. through editing a configuration file. However for simplified configuration a client MAY also implement the PP URI request method described in this document to fetch the system parameters based on a configured URI. This is especially useful for federating between IBE systems. By specifying a single URI a client can be configured to fetch all the relevant parameters for a remote PKG. These public parameters can then be used to encrypt messages to recipients who authenticate to and retrieve private keys from that PKG. The following section outlines the URI request method to retrieve a parameter block and describes the structure of the parameter block itself. Appenzeller, et al. Expires January 2008 [Page 9] Internet-Draft IBE Architecture July 2007 3.1. Request Method The configuration URI SHOULD be an HTTPS URI [HTTP] of the format: http_URI = "https:" "//" host [ ":" port ] [ abs_path ] An example URI for ibe system parameters is https://ibe-0000.example.com/example.com.pp To retrieve the IBE system parameters, the client SHOULD use the HTTP GET method as defined in [HTTP]. The request MUST happen over a secure protocol. The requesting client MUST support TLS 1.1 [TLS] or its successors and SHOULD use the latest version supported by both parties. When requesting the URI the client MUST only accept the system parameter block if the server identity was verified successfully by TLS 1.1 [TLS] or its successors. A successful GET request returns in its body the Base64 encoding of the DER-encoded [DER] IBESysParams structure that is described in the next section. This structure MUST be served as an application/octet-stream MIME type [RFC2046]. 3.2. Parameter and Policy Format The IBE System parameters are a set of IBESysParams ::= SEQUENCE { version INTEGER { v2(2) }, districtName UTF8String, districtSerial INTEGER, validity ValidityPeriod, ibePublicParameters IBEPublicParameters, ibeIdentitySchema OBJECT IDENTIFIER, ibeParamExtensions IBEParamExtensions OPTIONAL } The version specifies the version of the IBESysParams format. For the format described in this document it MUST be set to 2. The district name is an UTF8String that MUST be a valid domain name as defined by [DOM]. The districtSerial is a serial number that represents a unique set of IBE public parameters. If new parameters are published for a district, it MUST be increased to a number greater than the previously-used serial number. Appenzeller, et al. Expires January 2008 [Page 10] Internet-Draft IBE Architecture July 2007 The validity period or lifetime of a specific instance of the IBESysParams is defined as follows: ValidityPeriod ::= SEQUENCE { notBefore GeneralizedTime, notAfter GeneralizedTime } 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. IBE system parameters MUST be regenerated and republished whenever the ibePublicParameters, ibeIdentitySchema, or ibeParamExtensions change for a district. A client SHOULD refetch the IBE system parameters at an application configurable interval to ensure that it has the most current version on the IBE system parameters. It is possible to create identities for use in IBE that have a time component, as described in [IBECMS]. If such an identity is used, the time component of the identity MUST fall between the notBefore time and the notAfter times of the IBE system parameters. IBEPublicParameters is a set of public parameters that correspond to IBE algorithms that the PKG associated with this district understands. IBEPublicParameters ::= SEQUENCE (1..MAX) OF IBEPublicParameter IBEPublicParameter ::= SEQUENCE { ibeAlgorithm OBJECT IDENTIFIER, publicParameterData OCTET STRING } The ibeAlgorithm OID specifies an IBE algorithm. The publicParameterData is a DER-encoded [DER] ASN.1 structure that contains the actual cryptographic parameters. Its specific structure depends on the algorithm. The OIDs for two IBE algorithms, the Boneh-Franklin and Boneh-Boyen algorithms and their publicParameterData structures are defined in [IBCS]. Appenzeller, et al. Expires January 2008 [Page 11] Internet-Draft IBE Architecture July 2007 The IBESysParams of a district MUST contain at least one algorithm and MAY contain several algorithms. It MUST NOT contain two or more IBEPublicParameter entries with the same algorithm. A client that wants to use IBESysParams can chose any of the algorithms specified in the publicParameterData structure. A client MUST implement at least the Boneh-Franklin algorithm and MAY implement the Boneh-Boyen and other algorithms. If a client does not support any of the supported algorithms it MUST generate an error message and fail. ibeIdentitySchema is an OID that defines the type of identities that are used with this district. The OIDs and the required and optional fields for each OID are described in [IBECMS]. IBEParamExtensions is a set of extensions that can be used to define additional parameters that particular implementations may require. IBEParamExtensions ::= SEQUENCE OF IBEParamExtension IBEParamExtension ::= SEQUENCE { ibeParamExtensionOID OBJECT IDENTIFIER, ibeParamExtensionValue OCTET STRING } The contents of the octet string are defined by the specific extension type. The System Parameters of a district MAY have any number of extensions, including zero. The IBEParamExtension pkgURI defines the URI of the Private Key Generator of the district. If the PKG is publicly accessible, this extension SHOULD be present to allow the automatic retrieval of private keys for recipients of encrypted messages. For this extension the OCTET STRING contains a UTF8String with the URI of the key server. Appenzeller, et al. Expires January 2008 [Page 12] Internet-Draft IBE Architecture July 2007 ibeParamExt OBJECT IDENTIFIER ::= { ibcs ibcs3(3) parameter-extensions(2) } pkgURI OBJECT IDENTIFIER ::= { ibeParamExt pkgURI(1) } 4. Private Key Request Protocol 4.1. Overview In an identity-based encryption (IBE) system messages are encrypted using a public key that is locally calculated from public parameters and a user`s identity and decrypted using a private key that corresponds to the user`s public key. These private keys are generated by a private key generator (PKG) based on a global secret called a master secret. When requesting a private key, a client has to transmit two parameters: 1. The identity for which it is requesting a key 2. Authentication credentials for the individual requesting the key These two are often not the same as a single user may have access to multiple aliases. For example an email user may have access to the keys that correspond to two different email addresses, e.g. bob@example.com and bob.smith@example.com. This section defines the protocol to request private keys, a minimum user authentication method for interoperability, and how to pass authentication credentials to the server. It assumes that a client has already determined the URI of the PKG. This can be done from hints included in the IBE message format [IBECMS] and the system parameters of the IBE system. 4.2. Private Key Request To request a private key, a client performs a HTTP POST method as defined in [HTTP]. The request MUST happen over a secure protocol. The requesting client MUST support TLS 1.1 [TLS] or its successors, using the latest version supported by both the client and the PKG. When requesting the URI the client MUST verify the server certificate [RFC2818], and MUST abort the key request if the server certificate verification of the TLS Appenzeller, et al. Expires January 2008 [Page 13] Internet-Draft IBE Architecture July 2007 connection fails. Doing so is critical to protect the authentication credentials and the private key against man-in- the-middle attacks when it is transmitted from the key server to the client. 4.3. Request Structure The POST method contains in its body the following XML structure that MUST be encoded as an application/xhtml+xml MIME type [RFC3236]: algorithmOID ibeIdentityInfo A SHOULD include a element, an ASCII string that identifies the client type and client version. A key request MUST contain a valid ibeIdentityInfo that the private key is requested for. This identity is the base64 encoding of the DER encoding [DER] of the ASN.1 structure IBEIdentityInfo as defined in [IBECMS]. A key request MUST contain a element that contains a XER [XER] encoded ASN.1 OBJECT IDENTIFIER [DER] that identifies the algorithm for which a key is requested. OIDs for the BB1 and BF algorithms are listed in [IBCS]. A client MAY include optional additional XML elements in the part of the key request. Appenzeller, et al. Expires January 2008 [Page 14] Internet-Draft IBE Architecture July 2007 4.4. Authentication When a client requests a key from a PKG, the PKG SHOULD authenticate the client before issuing the key. Authentication may either be done through the key request structure or as part of the secure transport protocol. A client or server implementing the request protocol MUST support HTTP Basic Auth as described in [AUTH]. A client and server SHOULD also support HTTP Digest Auth as defined in [AUTH]. For authentication methods that are not done by the transport protocol, a client MAY include additional authentication information in xml elements in the body part of the key request. If a client does not know how to authenticate to a server, the client MAY send a key request without authentication information. If the key server requires the client to authenticate externally, it MAY reply with a 201 response code as defined below to redirect the client to the correct authentication mechanism. 4.5. Server Response Format The key server replies to the HTTP request with an HTTP response. If the response contains a client error or server error status code, the client MUST abort the key request and fail. If the PKG replies with a HTTP response that has a status code indicating success, the body of the reply MUST contain the following XML structure that MUST be encoded as an application/xhtml+xml MIME type [RFC3236]: bodyTags The responseCode describes the type of response from the key server. The list of currently defined response codes is: Appenzeller, et al. Expires January 2008 [Page 15] Internet-Draft IBE Architecture July 2007 100 KEY_FOLLOWS 101 RESERVED 201 FOLLOW_ENROLL_URI 300 SYSTEM_ERROR 301 INVALID_REQUEST 303 CLIENT_OBSOLETE 304 AUTHORIZATION DENIED 4.6. Response Containing a Private Key If the key request was successful, the key server responds with KEY FOLLOWS, and the must contain a tag with a valid private key. An example of this is shown below. privateKey The privateKey is the Base64 [B64] encoding of the DER encoding [DER] of the following ASN.1 structure: IBEPrivateKeyReply ::= SEQUENCE { pkgIdentity IBEIdentityInfo, pgkAlgorithm OBJECT IDENTIFIER pkgKeyData OCTET STRING pkgOptions SEQUENCE OF Extensions } The pkgIdentity is an IBEIdentityInfo structure as defined in [IBECMS]. It MUST be identical to the IBEIdentityInfo structure that was sent in the key request. The pkgAlgorithm is an OID that identifies the algorithm of the returned private key. The OIDs for the BB and BF algorithms are defined in [IBCS]. The pkgKeyData is an ASN.1 [DER] structure that contains the actual private key. Private-key formats for the BB and BF algorithms are defined in [IBCS]. Appenzeller, et al. Expires January 2008 [Page 16] Internet-Draft IBE Architecture July 2007 A server MAY pass back additional information to a client in the pkgOptions structure. The contents of the structure are defined in the ASN.1 module below. 4.7. Responses Containing a Redirect A Key Server MAY support authenticating user to external authentication mechanism. If this is the case, the server replies to the client with response code 201 and the body MUST contain a element that specifies the URI of the authentication mechanism. Such a response MUST be encoded as an application/xhtml+xml MIME type [RFC3236]. An example of such a response is shown below. The client can now contact the authentication mechanism to obtain authentication credentials. Once the client has obtained the credential, it sends a new key request to the PKG with the correct authentication credentials contained in the request. 4.8. Responses Indicating an Error If the server replies with a 3xx error code, the client MUST abort the request and discard any data that is part of the response. The meaning of the response codes for errors is as follows: 300 - This indicates an internal server error of the PKG. 301 - The request to the server is invalid or the server is not able to fulfill this type of request. 303 - The server is not able to serve key requests for this type of client. A client with a newer version of the protocol is required. 304 - The key request was processed correctly, but the authentication credentials provided by the user were invalid, Appenzeller, et al. Expires January 2008 [Page 17] Internet-Draft IBE Architecture July 2007 could not be verified, or do not allow access to keys for this identity. 5. Security Considerations 5.1. Attacks that are outside the scope of this document Attacks on the cryptographic algorithms that are used to implement IBE are outside the scope of this document. Such attacks are detailed in [IBCS], which defines parameters that give 80-bit, 112-bit and 128-bit encryption strength. We assume that capable administrators of an IBE system will select parameters that provide a sufficient resistance to cryptanalytic attacks by adversaries. Attacks that give an adversary the ability to access or change the information on a PPS or PKG, especially the cryptographic material (referred to in this document as the master secret), will defeat the security of an IBE system. In particular, if the cryptographic material is compromised the adversary will have the ability to recreate any user's private key and therefore decrypt all messages protected with the corresponding public key. To address this concern, it is highly RECOMMENDED that best practices for physical and operational security for PPS and PKG servers be followed and that these servers be configured (sometimes known as hardened) in accordance with best current practices [NIST]. An IBE system SHOULD be operated in an environment where illicit access is infeasible for attackers to obtain. Attacks that require administrative or IBE user equivalent access to machines used by either the client or the server components defined in this document are also outside the scope of this document. We also assume that all administrators of a system implementing the protocols that are defined in this document are trustworthy and will not abuse their authority to bypass the security provided by an IBE system. Similarly, we assume that users of an IBE system will behave responsibly, not sharing their authentication credentials with others. Thus attacks that require such assumptions are outside the scope of this document. Appenzeller, et al. Expires January 2008 [Page 18] Internet-Draft IBE Architecture July 2007 5.2. Attacks that are within the scope of this document Attacks within the scope of this document are those that allow an adversary to: o passively monitor information transmitted between users of an IBE system and the PPS and PKG o masquerade as a PPS or PKG o perform a DOS attack on a PPS or PKG o easily guess an IBE users authentication credential 5.2.1. Attacks to which the protocols defined in this document are susceptible All communications between users of an IBE system and the PPS or PKG are protected using TLS 1.1 [TLS]. The IBE system defined in this document provides no additional security protections for the communications between IBE users and the PPS or PKG. Therefore the described IBE system is completely dependent on the TLS security mechanisms for authentication of the PKG or PPS server and for confidentiality and integrity of the communications. Should there be a compromise of the TLS security mechanisms, the integrity of all communications between an IBE user and the PPS or PKG will be suspect. The protocols defined in this document do not explicitly defend against an attacker masquerading as a legitimate IBE PPS or PKG. The protocols rely on the server authentication mechanism of TLS [TLS]. In addition to the TLS server authentication mechanism IBE client software can provide protection against this possibility by providing user interface capabilities that allows users to visually determine that a connection to PPS and PKG servers is legitimate. This additional capability can help ensure that users cannot easily be tricked into providing valid authorization credentials to an attacker. The protocols defined in this document are also vulnerable to attacks against an IBE PPS or PKG. Denial of service attacks against either component can result in users unable to encrypt or decrypt using IBE, and users of an IBE system SHOULD take the appropriate countermeasures [RFC2827, RFC3882] that their use of IBE requires. Appenzeller, et al. Expires January 2008 [Page 19] Internet-Draft IBE Architecture July 2007 The IBE user authentication method selected by an IBE PKG SHOULD be of sufficient strength to prevent attackers from easily guessing the IBE user's authentication credentials through trial and error. 6. IANA Considerations The XML defined in this document will be registered with the IANA per the instructions in RFC 3688, The IETF XML Registry. URI: urn:ietf:params:xml:ns:ibe Registrant Contact: Luther Martin Voltage Security 1070 Arastradero Rd Suite 100 Palo Alto CA 94304 Phone: +1 650 543 1280 Email: martin@voltage.com XML: Appenzeller, et al. Expires January 2008 [Page 20] Internet-Draft IBE Architecture July 2007 BEGIN algorithmOID ibeIdentityInfo bodyTags END 7. References 7.1. Normative References [AUTH] J. Franks, et al., "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999. [B64] N. Freed and N. Borenstein, Multipurpose Internet Mail Extensions(MIME) Part One: Format of Internet Message Bodies," RFC 2045, November 1996. [CMS] R. Housley, "Cryptographic Message Syntax," RFC 3369, August 2002. [DER] ITU-T Recommendation X.680: Information Technology - Abstract Syntax Notation One, 1997. [DOM] P. Mockapetris, "Domain Names - Implementation and Specification," RFC 1035, November 1987. [HTTP] R. Fielding, et al., "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Appenzeller, et al. Expires January 2008 [Page 21] Internet-Draft IBE Architecture July 2007 [IBCS] X. Boyen and L. Martin, "Identity-Based Cryptography Standard (IBCS) #1: Supersingular Curve Implementations of the BF and BB1 Cryptosystems," draft-ietf-martin- ibcs-00.txt, September 2006. [IBECMS] L. Martin and M. Schertler, "Using the Boneh-Franklin identity-based encryption algorithm with the Cryptographic Message Syntax (CMS)," draft-ietf-smime- bfibecms-01.txt, September 2006. [KEY] S. Brander, "Key Words for Use in RFCs to Indicate Requirement Levels," BCP 14, RFC 2119, March 1997. [NIST] M. Souppaya, J. Wack and K. Kent, "Security Configuration Checklist Program for IT Products - Guidance for Checklist Users and Developers," NIST Special Publication SP 800-70, May 2005. [P1363] IEEE P1363, "Standards Specifications for Public-Key Cryptography," 2001. [RFC2046] N. Freed and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types," RFC 2046, November 1996. [RFC2818] E. Rescorla, "HTTP over TLS," RFC 2818, May 2000. [RFC2827] P. Ferguson and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing," RFC 2827, BCP 38, May 2000. [RFC3236] M. Baker and P. Stark, "The 'application/xhtml+xml' Media Type," RFC 3236, January 2002. [RFC3882] D. Turk, "Configuring BGP to Block Denial-of-Service Attacks," RFC 3882, September 2004. [TLS] T. Dierks and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1," RFC 4346, April 2006. [URI] T. Berners-Lee, R. Fielding, and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. Appenzeller, et al. Expires January 2008 [Page 22] Internet-Draft IBE Architecture July 2007 [XER] ITU-T Recommendation X.693 - Information Technology - ASN.1 Encoding Rules - XML Encoding Rules (XER), December 2001. Authors' Addresses Guido Appenzeller Voltage Security 1070 Arastradero Rd Suite 100 Palo Alto CA 94304 Phone: +1 650 543 1280 Email: guido@voltage.com Luther Martin Voltage Security 1070 Arastradero Rd Suite 100 Palo Alto CA 94304 Phone: +1 650 543 1280 Email: martin@voltage.com Mark Schertler Tumbleweed Communications 700 Saginaw Dr Redwood City CA 94063 Phone: +1 650 216 2039 Email: mark.schertler@tumbleweed.com Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of Appenzeller, et al. Expires January 2008 [Page 23] Internet-Draft IBE Architecture July 2007 this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Appenzeller, et al. Expires January 2008 [Page 24]