Internet DRAFT - draft-ietf-smime-ibepkg
draft-ietf-smime-ibepkg
S/MIME Working Group G. Appenzeller
Internet Draft Voltage Security
Expires: December 2006 June 2006
Identity-based Encryption
Private Key Request Protocol
<draft-ietf-smime-ibepkg-00.txt>
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:
<ibe:request xmlns:ibe=\"http://www.ietf.org/tbd/ibepkg\">
<ibe:header>
<ibe:client version="clientID"/>
</ibe:header>
<ibe:body>
<ibe:keyRequest>
<ibe:algorithm>
<oid> algorithmOID </oid>
</ibe:algorithm>
<ibe:id>
ibeIdentityInfo
</ibe:id>
</ibe:keyRequest>
</ibe:body>
</ibe:request>
Appenzeller Expires December 2006 [Page 3]
Internet-Draft IBE Private Key Request June 2006
A <ibe:request> SHOULD include a <ibe:clientID> 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 <ibe:algorithm> 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
<ibe:body> 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
<ibe:response xmlns:ic="http://www.ietf.org/tbd/icsip">
<ibe:responseType value="responseCode"/>
<ibe:body>
bodyTags
</ibe:body>
</ibe:response>
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 <ibe:body> must contain a <ibe:privateKey> tag with
a valid private key. An example of this is shown below.
<ibe:response xmlns:ic=" http://www.ietf.org/tbd/icsip">
<ibe:responseType value="100"/>
<ibe:body>
<ibe:privateKey>
privateKey
</ibe:privateKey>
</ibe:body>
</ibe:response>
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
<ibe:location> element that specifies the URL of the authentication
mechanism. An example is shown below.
<ibe:response xmlns:ic=" http://www.ietf.org/tbd/icsip">
<ibe:responseType value="201"/>
<ibe:body>
<ibe:location url="http://www.example.com/enroll.asp"/>
</ibe:body>
</ibe:response>
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]
