Network Working Group M. Huang Internet-Draft Huawei Symantec Intended status: Informational July 3, 2009 Expires: January 4, 2010 Identity-Based Encryption (IBE) Cipher Suites for Transport Layer Security (TLS) draft-huang-tls-ibe-00 Status of This Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 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. This Internet-Draft will expire on January 4, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. Huang Expires January 4, 2010 [Page 1] Internet-Draft IBE for TLS July 2009 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document describes a new key exchange method, Identity-Based Encryption (IBE) for the Transport Layer Security (TLS) protocol. This memo specifies an alternative method for transmitting premaster secret securely between the client and server in a TLS handshake process. Some new cipher suites are thus introduced into TLS protocol. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. IBE Overview . . . . . . . . . . . . . . . . . . . . . . . 4 2. Using Identity-Based Encryption . . . . . . . . . . . . . . . 5 2.1. Key-exchange Method . . . . . . . . . . . . . . . . . . . 5 2.2. Client and Server Authentication . . . . . . . . . . . . . 5 3. TLS Extension for IBE . . . . . . . . . . . . . . . . . . . . 5 4. Data Structures and Computations . . . . . . . . . . . . . . . 6 4.1. Client Hello . . . . . . . . . . . . . . . . . . . . . . . 6 4.1.1. IBE Parameters Extension . . . . . . . . . . . . . . . 7 4.2. Server Hello . . . . . . . . . . . . . . . . . . . . . . . 10 4.3. Server Certificate . . . . . . . . . . . . . . . . . . . . 11 4.4. Server Key Exchange . . . . . . . . . . . . . . . . . . . 11 4.5. Certificate Request . . . . . . . . . . . . . . . . . . . 11 4.6. Client Certificate . . . . . . . . . . . . . . . . . . . . 12 4.7. Client Key Exchange . . . . . . . . . . . . . . . . . . . 12 4.8. Certificate Verify . . . . . . . . . . . . . . . . . . . . 13 5. Cipher suites . . . . . . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. Normative References . . . . . . . . . . . . . . . . . . . . . 15 Huang Expires January 4, 2010 [Page 2] Internet-Draft IBE for TLS July 2009 1. Introduction In Public Key Infrastructure (PKI) system, the Certification Authorities (CAs) are deployed in a hierarchical mode. Users who want to validate a certificate signed by one CA must validate the identity of the CA which signed it firstly. Completing the validation of one CA depends on the validation of CAs higher than it in this hierarchical architecture till the root CA is trusted by the user. In this procedure, user must get all certificates of CAs involved in this authority chain and make requests for Certificate Revocation Lists (CRLs) to check if the certificates are still valid. Sometimes it may be involved in cross authentication among different CAs. Users may consume significant time for this processing. Besides, it is an overburden to maintain and issue certificates and CRLs. In Identity-based Encryption (IBE) system, one user can use one of the other user's public information as its public key rather than its public key in certificate, such as email address, IP address, domain name, etc. A sender can encrypt the message with the receiver's public key without retrieving its certificate. The receiver can acquire its corresponding private key from the trusted third party Public Key Generator (PKG) and decrypt the message received from the sender. Thus in IBE system, users need not to spend time on retrieving and validating certificates. In some specific circumstances, it provides a more suitable and convenient method than PKI does. In current actual application of TLS, most users would like to ignore the failure alert of certificate verification that pop up from their browsers and continue to complete the connections to these HTTPS websites. This neglect can be utilized by attackers to masquerade websites using the forged certificates. In IBE-based system, there is no need to verify the receiver's public key for users. Because the identity information used as the public key is well-known and user authentication relies on the authentication performed by PKG. Therefore, the risks brought by user's neglect will be eliminated. In P2P applications environment, it is impossible that all users have their certificates used for authentication in TLS. So it is more convenient using IBE-based mechanism than PKI relied mechanism when using TLS to protect data transmission, especially users can use each other's ID (e.g., email address, IP address, user ID, etc) as the public key to do encryption. This document describes additions to TLS to support IBE, applicable both to TLS Version 1.2 [TLS1.2] and its successors. In particular, it defines: Huang Expires January 4, 2010 [Page 3] Internet-Draft IBE for TLS July 2009 o A key exchange method using the public information as the public key of the receiver. Client encrypts the premaster secret with the public key of the server. The server decrypts it with the corresponding private key retrieved from PKG. o An authentication method allowing the users to compute digital signatures using their private keys from the PKG. Each side can validate the signature with the public key of the other side. It can support both server authentication and client authentication. Implementation of this specification requires familiarity with TLS[TLS1.0][TLS1.1][TLS1.2], and IBE[IBE][IBCS]. 1.1. Conventions 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 RFC2119 [KEYWORDS]. 1.2. IBE Overview RFC 5408[IBE] describes an IBE-based messaging system and defines the components of such a system. The server components required for such a system are the following: o A Public Parameter Server (PPS):IBE public parameters include publicly-sharable cryptographic material, known as IBE public parameters, and policy information for an associated PKG. A PPS provides a well-known location for secure distribution of IBE public parameters and policy information that describe the operation of a PKG. o A Private-key Generator (PKG):The PKG stores and uses cryptographic material, known as a master secret, which is used for generating a user's IBE private key. A PKG accepts an IBE user's private key request, and after successfully authenticating them in some way, returns their IBE private key. The procedures of getting public parameters from PPS and private key from PKG are described in [IBE]. Users MUST verify the PPS using the server certificate and the PKG MUST verify the users who request private keys using their authentication credentials. This provides confidentiality and integrity of the information transmitted from the servers (PPS and PKG) to users and appropriate authentication of the servers (PPS and PKG) and users. Huang Expires January 4, 2010 [Page 4] Internet-Draft IBE for TLS July 2009 2. Using Identity-Based Encryption IBE is a public-key technology for encrypting content-encryption keys (CEKs). Within the IBE system the receiver's identity (ID) is used as a public key. This document does not describe the implementation of the Boneh-Franklin (BF) and Boneh-Boyen (BB1) algorithms, which are described in detail in [IBCS]. 2.1. Key-exchange Method In this memo, a new key-exchange method is introduced. All of the key exchange methods which transmit encrypted premaster secret using public-key encryption can be replaced by the method based on IBE public-key encryption mechanism. The derivation of the TLS master secret from the premaster secret and the subsequent generation of bulk encryption/MAC keys and initialization vectors is independent of and not impacted by the introduction of IBE. 2.2. Client and Server Authentication Server authentication in TLS handshake process which has negotiated IBE cipher suites depends on the server authentication performed by the PKG. In IBE-based system, an entity makes requests for its private key corresponding to certain identity information used as a public key from the PKG. PKG MUST authenticate the requesting entity to make sure it is the entity who claimed to be. Thus, if the encrypted premaster secret is decrypted successfully by the server, it means that the server is successfully authenticated by the PKG and obtains its private key successfully. Just like in PKI-based system, clients trust the identity of the server claimed depending on clients trust the CAs which issued the certificate. In IBE-based system, client trusts the PKG, so it trusts the server which has been validated by that PKG. In the same way, server authenticates the client using IBE-based mechanism depending on the PKG who generates and transmits the private key for the client who has been authenticated successfully. 3. TLS Extension for IBE A new TLS extension is defined in this specification, IBE parameters extension. Client and server can negotiate appropriate information when they decide to use an IBE-based cipher suite using this extension. This extension is used to negotiate the use of specific set of public parameters in specific district and thus the use of specific algorithm supported by each side when negotiating a new session. Huang Expires January 4, 2010 [Page 5] Internet-Draft IBE for TLS July 2009 The client may be configured several trusted PPSs and obtain several sets of public parameters issued by different PPSs. Each set of public parameters contains several algorithms supported by the PKG. So the client and server SHOULD negotiate the use of specific set of public parameters. The client enumerates the sets of public parameters by including an IBE parameters extension in its ClientHello message. The server MUST choose one set by including an IBE parameters extension in its ServerHello message when using IBE- based cipher suite. The client may have certain identities (ClientIDs) used as its public keys. So if the server wants to authenticate the client using IBE- based mechanism, it SHOULD choose one clientID used to verify the identity of the client. The client may know certain server's identities (ServerIDs) which can be used as the server's public key. The client will list all the server's IDs it knew in the IBE parameters extension and the server MUST select or appoint one ID as its public key. The client MUST NOT include this extension in the ClientHello message if it does not propose any IBE cipher suites. In the case of session resumption, the server simply ignores the IBE parameters extension in the current ClientHello message. This extension only plays a role during handshakes negotiating a new session. 4. Data Structures and Computations This section specifies the data structures and computations used by IBE key-exchange and authentication mechanism. The presentation language used here is the same as that used in TLS specification. This memo extends TLS specification, these descriptions should be merged with those in the TLS specification and any others that extend TLS. This means that certain structures may not indicate all possible cases. 4.1. Client Hello When this message is sent: This message is sent as the first message when a client sets up a TLS connection with a server. The client can also send this message as a response to a HelloRequest or on its own initiative in order to renegotiate the security parameters in an existing connection. Structure of this message: The structure of this message is the same as that defined in TLS Huang Expires January 4, 2010 [Page 6] Internet-Draft IBE for TLS July 2009 specification. If the client confirms that it supports IBE-based mechanism, the cipher suites proposed in this message may contain IBE cipher suites. If there are IBE cipher suites provided, the IBE parameters extension specified in 4.1.1 MUST be contained in this message. Actions of the sender: A client that proposes IBE cipher suites in its ClientHello message appends the IBE parameters extension (along with any others) to this message. The client MUST send the IBE parameters extension if it supports IBE and proposes IBE cipher suites. Actions of the receiver: A server that receives a ClientHello message containing an IBE parameters extension MUST select one of the enumerated sets of public parameters contained in the ClientHello message if it selects an IBE cipher suite. This selected set of the proposed public parameters MUST contain the algorithm it supported. If the server does not understand the IBE parameters extension, or is unable to complete the IBE handshake while restricting itself to the enumerated sets of public parameters, it MUST NOT negotiate the use of an IBE cipher suite. Depending on what other cipher suites are proposed by the client and supported by the server, this may result in a fatal handshake failure alert due to the lack of common cipher suites. 4.1.1. IBE Parameters Extension This section specifies a new TLS extension that can be included in the ClientHello message as described in [TLS1.2]. This extension allows a client to enumerate the sets of public parameters and the IDs of the server and itself which can be used as their public keys. The general structure of TLS extensions is described in [TLS1.2], and this specification adds a new type to ExtensionType defined as follows: enum { ibe_parameters(TBD), (65535) } ExtensionType; ibe_parameters: extensions of this type are used to negotiate the set of public parameters and IDs used in the IBE key exchange method and IBE authentication. Huang Expires January 4, 2010 [Page 7] Internet-Draft IBE for TLS July 2009 The "extension_data" field of this extension is IBEParameters structure, which contains at least one set of public parameters retrieved from one PPS. The specific content of IBEParameters is defined as follows: struct { PublicParamsSet public_params_sets; IDInfo server_id_list; IDInfo client_id_list; } IBEParameters; The items within public_params_sets are ordered according to the client's preferences (favorite choice first). The specific public parameters contained in one public parameters set are defined as follows: struct { opaque district_name<1..2^8-1>; uint16 district_serial; ValidityPeriod validity_period; AlgorithmInfo algorithm_info; opaque ibe_identity_type<1..2^8-1>; ParamExtension param_extension_list; } PublicParamsSet; (1) The district_name field is a string of an URI or IRI of PPS/PKG. (2) The district_serial field is an integer that indicates a unique set of IBE public parameters which is available at the URI or IRI specified by the district_name. (3) The validity_period field is a structure which defines the period of validity of a specific set of public parameters. It is defined as follows: struct { opaque not_before[16]; opaque not_after[16]; }ValidityPeriod; The values of not_before and not_after fields MUST be expressed in Greenwich Mean Time (Zulu). Times are always expressed by the form of YYYYMMDDHHMMSSZ. The client SHOULD send the sets of public parameters falling between the not_before time and the not_after time. The server MUST NOT select the public parameters set if it does not. Huang Expires January 4, 2010 [Page 8] Internet-Draft IBE for TLS July 2009 (4) The algorithm_info field is a structure containing public parameters that correspond to IBE algorithm which both the PKG and the client support. The structure is defined as follows: struct { opaque ibe_algorithm_OID<1..2^16-1>; opaque public_parameter_data<1..2^16-1>; }AlgorithmInfo; The ibe_algorithm_OID specifies an IBE algorithm. The OIDs for two IBE algorithms (the Boneh-Franklin and Boneh-Boyen algorithms) and their public_parameter_data structures are defined in [IBCS]. The public_parameter_data contains the actual cryptographic parameters depending on the specific algorithm. The algorithm_info field MUST contain an OID that identifies one algorithm and MAY contain OIDs that identify more than one algorithm supported by the client. The server MUST select one algorithm it supports and prefers to use. (5) The ibe_identity_type field specifies an OID which defines the format used to encode the information that defines the identity of the user. The OID and the required and optional fields for each OID are application dependent. An example of it is given in [IBECMS], which defines the cmsIdentityOID to indicate that identity information contains an EmailIdentityData type. (6) The param_extension_list field is a list of additional parameters which particular implementations may require. The structure of ParamExtension is defined as follows: struct { opaque ibeParamExtensionOID<0..2^16-1>; opaque ibeParamExtensionValue<0..2^16-1>; } ParamExtension; ibeParamExtensionOID specifies the type of an IBE parameter extension. ibeParamExtensionValue is the content of specific extension type specified by the extension OID. Items in server_id_list are strings that can be used as the public keys of server. The server chooses one ID from this list contained in the ClientHello message or appoints a new ID which is not contained in this list. The structure of IDInfo is defined as follows: Huang Expires January 4, 2010 [Page 9] Internet-Draft IBE for TLS July 2009 struct { opaque id_info<1..2^8-1>; }IDInfo; It is RECOMMENDED that the client and the server use the well-known and unique in certain community identities as their public keys, e.g. the server's domain name. The client_id_list field is a list of client identities that can be used as or be used to compute the public key of client. The server can select one of the client IDs as the client's public key according to the configured policies. The selected ID can then be used to verify the client's signature sent in the client's CertificateVerify message. The value of the IDInfo can be an IP address, a domain name, an email address, a phone number or a host name, etc. The detailed description of public parameters and how to obtain them from PPS/PKG can be seen in [IBE]. 4.2. Server Hello When this message is sent: This message is sent in response to a ClientHello message when the server select an acceptalbe set of algorithms. Meaning of this message: This message allows a server to choose one cipher suite. If the server confirms that it supports IBE and then selects an IBE cipher suite, it needs to decide which set of IBE public parameters provided by the client in its IBE parameters extension to be used in IBE key exchange mechanism. Structure of this message: The server's IBE parameters extension has the same structure as the client's IBE parameters extension, see section 4.1.1. Here extension data has one item in public_params_sets it chooses, one item in server_id_list it chooses or appoints and one item in client_id_list. If there is no ServerID listed in the client's extension, the server MUST appoint one ServerID in the its IBE parameters extension. Actions of the sender: The server informs the client of the selected set of public parameters used in IBE key exchange, a server ID used as the public key of the server and a client ID used as the public key of the Huang Expires January 4, 2010 [Page 10] Internet-Draft IBE for TLS July 2009 client via appending an IBE parameters extension to this message. Actions of the receiver: The client that receives a ServerHello message containing an IBE parameters extension MUST respect the server's choice of public parameters set. If there is no IBE parameters extension within the ServerHello message, this may result in a fatal handshake failure alert due to the failure of the negotiation. 4.3. Server Certificate When this message is sent: This message is sent in all IBE-based key exchange methods after the ServerHello message. Structure of this message: The content of this message is empty when an IBE cipher suite is selected. The specific content of this message is defined in future if there are some new circumstances. 4.4. Server Key Exchange This message is not sent when using IBE cipher suites. The premaster key is encrypted and sent in client key exchange message. The server needs to acquire its private key to decrypt out the premaster key. So there is no need to send server key exchange message. 4.5. Certificate Request When this message is sent: This message is sent when the server requests client authentication. Meaning of this message: The server uses this message to suggest acceptable client authentication methods, e.g.IBE-based authentication mechanism. Structure of this message: The structure of this message is the same as structure defined in TLS specification. When the server requires IBE-based authentication mechanism, the client certificate type is IBE. The signature and hash algorithms Huang Expires January 4, 2010 [Page 11] Internet-Draft IBE for TLS July 2009 listed in supported_signature_algorithms MUST be an IBE signature mechanism and the appropriate hash algorithms. The certificate_authorities field is a list of the URIs or IRIs of acceptable PPSs/PKGs from which the client can choose one to acquire its private key used in signature. A new ClientCertificateType is defined as follows: enum { IBE(TBD), (255) } ClientCertificateType; Actions of the sender: The server decides which client authentication methods it would like to use, and conveys this information to the client using the format defined above or in the TLS specification. Actions of the receiver: The client determines whether it has required and suitable information for use with any of the requested methods and whether to proceed with client authentication. 4.6. Client Certificate When this message is sent: This message is sent in response to a CertificateRequest message. Structure of this message: The content of this message is empty when the server wants to authenticate the client using IBE-based mechanism. The specific content of this message is defined in future if there are some new circumstances. 4.7. Client Key Exchange When this message is sent: This message is sent when using certain key exchange methods which require the client to transmit the premaster key to the server. This message MUST be sent immediately after the client certificate message. Structure of this message: This message conveys the encrypted premaster key to the server. The Huang Expires January 4, 2010 [Page 12] Internet-Draft IBE for TLS July 2009 structure is defined as follows: enum { ibe } KeyExchangeAlgorithm; /*just list the extending one*/ struct { select (KeyExchangeAlgorithm) { case ibe: EncryptedPreMasterSecret; } exchange_keys; } ClientKeyExchange; Actions of the sender: The client generates a 48-byte premaster secret, encrypts it with the public key of the server, and sends the result in this message. Actions of the receiver: The server receives the encrypted premaster secret contained in this message and decrypts out the premaster secret with its private key acquired from PKG in advance and the selected set of public parameters. 4.8. Certificate Verify When this message is sent: This message is sent after receiving the server's CertificateRequest message and immediately follow the ClientKeyExchange message. Meaning of this message: This message contains the signature information that proves possession of the private key corresponding to the client's public key. Structure of this message: The structure of this message is the same as that defined in [TLS1.2]. Actions of the sender: The client computes its signature over all handshake messages sent or received starting at client hello and up to but not including this message. The private key used is acquired from the PKG specified in the CertificateRequest message. Huang Expires January 4, 2010 [Page 13] Internet-Draft IBE for TLS July 2009 Actions of the receiver: The server extracts the client's signature information from the CertificateVerify message and verifies it using the clientID selected by the server in its IBE parameters extension. 5. Cipher suites The following defines new IBE cipher suites that use the IBE-based key exchange algorithm. CipherSuite TLS_IBE_WITH_NULL_MD5 CipherSuite TLS_IBE_WITH_NULL_SHA CipherSuite TLS_IBE_WITH_NULL_SHA256 CipherSuite TLS_IBE_WITH_RC4_128_MD5 CipherSuite TLS_IBE_WITH_RC4_128_SHA CipherSuite TLS_IBE_WITH_3DES_EDE_CBC_SHA CipherSuite TLS_IBE_WITH_AES_128_CBC_SHA CipherSuite TLS_IBE_WITH_AES_256_CBC_SHA CipherSuite TLS_IBE_WITH_AES_128_CBC_SHA256 CipherSuite TLS_IBE_WITH_AES_256_CBC_SHA256 Table 1: TLS IBE cipher suites 6. Security Considerations This document is based on [IBCS] and [IBE], and the relevant security considerations of those documents apply. Security discussions specific to IBE, especially masquerading as legitimate PPS/PKG and DoS attack on PPS/PKG can be found in these documents. Sizes of BF and BB1 algorithm parameters required achieving standard levels of bit security. Their usage scenarios are described in [IBCS]. We assume that the server will be properly configured to select parameters that provide a sufficient strength required. Within this document the distribution of the private key is the most important issue to be considered. The client and the server can obtain their private key from the PKG through security physical approaches or security communication channel built between the user and the PKG. The security strength of the TLS using IBE cipher suites described in this document relies on the strength of the mechanism used to authenticate a user requesting a private key from a PKG. A weak mechanism used to authenticate users will result in a weak TLS process relies on the technology. It is required that the Huang Expires January 4, 2010 [Page 14] Internet-Draft IBE for TLS July 2009 authentication mechanism used by PKG must be suitably strong. 7. IANA Considerations IANA is requested to assign: 1. a new ExtensionType value for ibe_parameters in the TLS ExtensionType Registry maintained at http://www.iana.org/ assignments/tls-extensiontype-values/ tls-extensiontype-values.xhtml. 2. a new ClientCertificateType identifier for IBE_authentication in the TLS ClientCertificateType Identifiers Registry maintained at http://www.iana.org/assignments/tls-parameters/ tls-parameters.xhtml. 3. create ten entries in the TLS Cipher Suite Registry maintained at http://www.iana.org/assignments/tls-parameters/ tls-parameters.xhtml. The new cipher suites are listed in section 5. 8. Normative References [IBCS] Boyen, X. and L. Martin, "Identity-Based Cryptography Standard (IBCS) #1: Supersingular Curve Implementations of the BF and BB1 Cryptosystems", RFC 5091, December 2007. [IBE] Appenzeller, G., Martin, L., and M. Schertler, "Identity- Based Encryption Architecture and Supporting Data Structures", RFC 5408, January 2009. [IBECMS] Martin, L. and M. Schertler, "Identity-Based Encryption Architecture and Supporting Data Structures", RFC 5409, January 2009. [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997. [TLS1.0] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [TLS1.1] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 4346, April 2006. [TLS1.2] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. Huang Expires January 4, 2010 [Page 15] Internet-Draft IBE for TLS July 2009 Author's Address Min Huang Huawei Symantec Technologies Co.,Ltd. Keshi Building No.28,Xinxi Road HaiDian District Beijing 100085 China EMail: huangmin@huaweisymantec.com URI: http://www.huaweisymantec.com Huang Expires January 4, 2010 [Page 16]