S/MIME Working Group G. Appenzeller Internet Draft Voltage Security Expires: December 2006 June 2006 Identity-based Encryption Private Key Request Protocol 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 a protocol to request private keys from a Private Key Generator (PKG) for an identity-based encryption system. Table of Contents 1. Introduction...................................................2 1.1. Terminology...............................................2 2. Overview.......................................................2 3. Private Key Request............................................3 3.1. Request Structure.........................................3 3.2. Authentication............................................4 Appenzeller Expires December 2006 [Page 1] Internet-Draft IBE Private Key Request June 2006 4. Server Response Format.........................................4 4.1. Response containing a Private Key.........................5 4.2. Responses containing a Redirect...........................6 4.3. Responses indicating an Error.............................6 5. ASN.1 Module...................................................8 6. Security Considerations........................................9 7. IANA Considerations............................................9 8. References.....................................................9 8.1. Normative References......................................9 Author's Address.................................................10 Intellectual Property Statement..................................10 Disclaimer of Validity...........................................11 Copyright Statement..............................................11 Acknowledgment...................................................11 1. Introduction An identity-based encryption system [IBEARCH] allows the encryption of messages using a user’s identity plus a set of public parameters. For decryption users need a private key that is generated by a private key generator. This document defines a protocol to retrieve private keys from the private key generator (PKG) of an IBE system. This document does not describe the actual algorithms used for encryption or the mathematical structure of the public parameters, they are described in [IBCS]. It also does not describe the communication protocol to retrieve public parameters, it is described in [IBEPPS]. 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 RFC-2119 [KEY]. 2. 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 it is requesting a key for Appenzeller Expires December 2006 [Page 2] Internet-Draft IBE Private Key Request June 2006 2. Authentication credentials 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 document 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 URL of the PKG. This can be done from hints included in the IBE message format [IBCMS] and the system parameters of the IBE system [IBEPPS]. 3. Private Key Request To request a private key, a client performs a HTTP POST method as defined in [RFC2616]. The request MUST happen over a secure protocol. The requesting client MUST support either SSL v 3.0 [SSL3] protocol or TLS v 1.1 [TLS]. When requesting the URL the client MUST abort the key request if the server certificate verification of the SSL or TLS connection fails [RFC2618]. 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. 3.1. Request Structure The POST method contains in its body the following XML structure: algorithmOID ibeIdentityInfo Appenzeller Expires December 2006 [Page 3] Internet-Draft IBE Private Key Request June 2006 A SHOULD include a element 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 of the ASN.1 structure IBEIdentityInfo as defined in [IBECMS]. A key request MUST contain a element that contains a XER encoded ASN.1 OBJECT IDENTIFIER that identifies 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. 3.2. 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 [RFC2617]. A client and server SHOULD also support HTTP Digest Auth as defined in [RFC2617]. 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. Server Response Format The key server replies to the HTTP request with an HTTP response. If the response has a redirect, 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: Appenzeller Expires December 2006 [Page 4] Internet-Draft IBE Private Key Request June 2006 bodyTags The responseCode describes the type of response from the key server. The list of currently defined response codes is: 100 KEY_FOLLOWS 101 RESERVED 201 FOLLOW_ENROLL_URL 300 SYSTEM_ERROR 301 INVALID_REQUEST 303 CLIENT_OBSOLETE 304 AUTHORIZATION DENIED 4.1. 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 encoding of the DER encoding 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. Appenzeller Expires December 2006 [Page 5] Internet-Draft IBE Private Key Request June 2006 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 a ASN.1 structure that contains the actual private key. Private key formats for the BB and BF algorithms are defined in [IBCS]. 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.2. 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 URL of the authentication mechanism. An example 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 token contained in the request. 4.3. 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. Appenzeller Expires December 2006 [Page 6] Internet-Draft IBE Private Key Request June 2006 304 – The key request was processed correctly, but the authentication credentials provided by the user were invalid, could not be verified, or do not allow access to keys for this identity. Appenzeller Expires December 2006 [Page 7] Internet-Draft IBE Private Key Request June 2006 5. ASN.1 Module This section defines the ASN.1 module for the encodings discussed in section 4. IBEPKG { joint-iso-itu(2) country(16) us(840) organization(1) identicrypt(114334) ibcs(1) ibcs2(2) pks(1) module (5) version(1) } DEFINITIONS IMPLICIT TAGS ::= BEGIN IMPORTS IBEIdentityInfo FROM BFCMS { joint-iso-itu(2) country(16) us(840) organization(1) identicrypt(114334) ibcs(1) cms(4) module(5) version(1) }; ibcs OBJECT IDENTIFIER ::= { joint-iso-itu(2) country(16) us(840) organization(1) identicrypt(114334) ibcs(1) } -- Private Key Format IBEPrivateKeyReply ::= SEQUENCE { pkgIdentity IBEIdentityInfo, pgkKeyType OBJECT IDENTIFIER, pkgKeyData OCTET STRING, pkgOptions Extensions } Extensions ::= SEQUENCE OF Extension Extension ::= SEQUENCE { id OBJECT IDENTIFIER, value OCTET STRING } ibeParamExt OBJECT IDENTIFIER ::= { ibcs ibcs2(2) pks(1) extensions(2) } END Appenzeller Expires December 2006 [Page 8] Internet-Draft IBE Private Key Request June 2006 6. Security Considerations This entire document relates to security considerations. 7. IANA Considerations No further action by the IANA is necessary for the protocols described in this document. 8. References 8.1. Normative References [CMS] R. Housley, “Cryptographic Message Syntax,” RFC 3369, August 2002. [KEY] S. Brander, “Key Words for Use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997. [P1363] IEEE P1363.3, “Standards Specifications for Public-Key Cryptography,” 2001. [SSL3] A. Frier, P. Karlton, and P. Kocher, "The SSL 3.0 Protocol", Netscape Communications Corp., Nov 18, 1996. [TLS] T. Dierks, E. Rescorla, “The Transport Layer Security Protocol Version 1.1,” RFC 4346, April 2006. [X509] ITU-T Recommendation X.509 (1997 E): Information Technology - Open Systems Interconnection - The Directory: Authentication Framework, June 1997. [IBEARCH] L. Martin, M. Schertler, “Identity-based encryption architecture,” draft-ietf-smime-ibearch-00.txt. [IBCS] X. Boyen, L. Martin, “Identity-based cryptography standard (IBCS) #1: supersingular curve implementations of the BF and BB1 cryptosystems,” draft-ietf-smime-ibcs-00.txt. [IBECMS] M. Schertler, L. Martin, “Using the Boneh-Franklin identity- based encryption algorithm with the Cryptographic Message Syntax (CMS),” draft-ietf-smime-bfibecms-01.txt. [IBEPPS] G. Appenzeller, “Parameter and policy lookup for identity- based encryption,” draft-ietf-smime-ibepkg-00.txt. Appenzeller Expires December 2006 [Page 9] Internet-Draft IBE Private Key Request June 2006 [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.Author's Address [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frysyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., Sink, E. and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999. [jg646] Author's Address Guido Appenzeller Voltage Security 1070 Arastradero Rd Suite 100 Palo Alto CA 94304 Phone: +1 650 543 1280 Email: guido@voltage.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 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. Appenzeller Expires December 2006 [Page 10] Internet-Draft IBE Private Key Request June 2006 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 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 Internet Society (2006). 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 Expires December 2006 [Page 11]