draft-ietf-smime-ibearch-00.txt   draft-ietf-smime-ibearch-01.txt 
G. Appenzeller
L. Martin L. Martin
S/MIME Working Group M. Schertler S/MIME Working Group M. Schertler
Internet Draft Voltage Security Internet Draft Voltage Security
Expires: April 2007 October 2006
Identity-based Encryption Architecture Identity-based Encryption Architecture
<draft-ietf-smime-ibearch-00.txt> <draft-ietf-smime-ibearch-01.txt>
Status of this Document Status of this Document
By submitting this Internet-Draft, each author represents that any 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 applicable patent or other IPR claims of which he or she is aware
or will be disclosed, and any of which he or she becomes aware will be have been or will be disclosed, and any of which he or she becomes
disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at
time. It is inappropriate to use Internet-Drafts as reference any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
Abstract Abstract
This document describes the security architecture required to implement This document describes the security architecture required to implement
identity-based encryption, a public-key encryption technology that uses identity-based encryption, a public-key encryption technology that uses
a users identity as a public key. a user`s identity as a public key.
Table of Contents Table of Contents
1. Introduction...................................................2 1. Introduction...................................................3
1.1. Terminology...............................................2 1.1. Terminology...............................................3
2. Identity-based Encryption......................................2 2. Identity-based Encryption......................................3
2.1. Overview..................................................2 2.1. Overview..................................................3
2.2. Sending a message that is encrypted using IBE.............3 2.2. Sending a Message that is Encrypted Using IBE.............4
2.2.1. Sender obtains IBE public parameters.................3 2.2.1. Sender Obtains IBE Public Parameters.................4
2.2.2. Sender IBE-encrypts message..........................4 2.2.2. Sender IBE-encrypts Message..........................5
2.3. Receiving and viewing an IBE-encrypted message............4 2.3. Receiving and Viewing an IBE-encrypted Message............5
2.3.1. Recipient obtains IBE private key from PKG...........5 2.3.1. Recipient Obtains IBE Public Parameters from PPS.....5
2.3.2. Recipient decrypts IBE-encrypted message.............6 2.3.2. Recipient Obtains IBE Private Key from PKG...........6
3. Security Considerations........................................6 2.3.3. Recipient Decrypts IBE-encrypted Message.............6
4. IANA Considerations............................................6 3. Public Parameter Lookup........................................7
5. References.....................................................6 3.1. Request Method............................................8
5.1. Normative References......................................6 3.2. Parameter and Policy Format...............................8
Author's Address..................................................7 4. Private Key Request Protocol..................................10
Intellectual Property Statement...................................7 4.1. Overview.................................................10
Disclaimer of Validity............................................8 4.2. Private Key Request......................................11
Copyright Statement...............................................8 4.3. Request Structure........................................11
Acknowledgment....................................................8 4.4. Authentication...........................................12
4.5. Server Response Format...................................13
4.6. Response Containing a Private Key........................13
4.7. Responses Containing a Redirect..........................14
4.8. Responses Indicating an Error............................15
5. ASN.1 Module..................................................16
6. Security Considerations.......................................18
6.1. Attacks that are outside the scope of this document......18
6.2. Attacks that are within the scope of this document.......19
6.3. Attacks that the protocols defined in this document are
susceptible to................................................19
6.4. Attacks that the protocols defined in this document protect
against.......................................................19
7. IANA Considerations...........................................20
8. References....................................................20
8.1. Normative References.....................................20
Authors` Addresses...............................................22
Intellectual Property Statement..................................22
Disclaimer of Validity...........................................23
Copyright Statement..............................................23
Acknowledgment...................................................23
1. Introduction 1. Introduction
This document describes the security architecture required to This document describes the security architecture required to
implement identity-based encryption, a public-key encryption implement identity-based encryption, a public-key encryption
technology that uses a users identity as a public key. technology that uses a user`s identity as a public key.
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [KEY]. document are to be interpreted as described in [KEY].
2. Identity-based Encryption 2. Identity-based Encryption
2.1. Overview 2.1. Overview
Identity-based encryption (IBE) is a public-key technology that Identity-based encryption (IBE) is a public-key technology that
allows keys to be calculated from an identity. This contrasts with allows keys to be calculated from an identity. This contrasts with
other public-key systems [P1363], in which keys are generated other public-key systems [P1363], in which keys are generated
randomly. Much like other public-key systems, IBE systems have public randomly. IBE systems have public parameters that define their
parameters that define their operation, and a user of an IBE system operation, and a user of an IBE system needs to obtain these public
needs to obtain these public parameters before he can do any IBE parameters before he can do any IBE operations. A user of an IBE
operations. A user of an IBE system is capable of calculating the system is capable of calculating the public key of a recipient after
public key of a recipient after he obtains the public parameters for he obtains the public parameters for the IBE system and the recipient
the IBE system and the recipient of an IBE-encrypted message can of an IBE-encrypted message can decrypt an IBE-encrypted message if
decrypt an IBE-encrypted message if he has both the IBE public he has both the IBE public parameters and the necessary private key.
parameters and the necessary private key.
With an IBE public key, a user can encrypt messages to a recipient With an IBE public key, a user can encrypt messages to a recipient
using the conventions of the Cryptographic Message Syntax [CMS]. using the conventions of the Cryptographic Message Syntax [CMS].
Within the framework of the CMS, a recipient also needs one Within the framework of the CMS, a recipient also needs one
additional element of information to decrypt a message: the URI of additional element of information to decrypt a message: the URI of
where he can obtain the private key that he needs to decrypt the IBE- where he can obtain the private key that he needs to decrypt the IBE-
encrypted message. encrypted message.
To decrypt an IBE-encrypted message, the recipient needs to obtain To decrypt an IBE-encrypted message, the recipient needs to obtain
IBE public parameters as well as the private key that corresponds to IBE public parameters as well as the private key that corresponds to
skipping to change at page 3, line 22 skipping to change at page 4, line 7
private key generator (PKG), a trusted third party that calculates private key generator (PKG), a trusted third party that calculates
private keys for users. private keys for users.
This document describes the overall architecture that can be used to This document describes the overall architecture that can be used to
implement IBE, and how the components of this architecture work implement IBE, and how the components of this architecture work
together to provide a functioning IBE system. The components required together to provide a functioning IBE system. The components required
for a complete IBE system include the following: for a complete IBE system include the following:
o A Public Parameter Server (PPS). A PPS provides IBE public o A Public Parameter Server (PPS). A PPS provides IBE public
parameters and policy information for an IBE Private-key parameters and policy information for an IBE Private-key
Generator and is uniquely identified by the form of an Generator. Its URI is uniquely identified by the form of an
identity that it supports. identity that it supports.
o A URI for a Private-key Generator (PKG) where users can get o A Private-key Generator (PKG) where users can get IBE
IBE private keys after authenticating their identity in some private keys after authenticating their identity in some
way. way.
Diagrams of these components and their interactions are shown in the Diagrams of these components and their interactions are shown in the
following sections. Note that IBE algorithms are used only for following sections. Note that IBE algorithms are used only for
encryption, so that any digital signatures that are required will encryption, so that any digital signatures that are required will
need to be provided by an additional mechanism. need to be provided by an additional mechanism.
2.2. Sending a message that is encrypted using IBE 2.2. Sending a Message that is Encrypted Using IBE
2.2.1. Sender obtains IBE public parameters 2.2.1. Sender Obtains IBE Public Parameters
The first step is for the sender of a message to obtain the IBE The first step is for the sender of a message to obtain the IBE
public parameters that he needs for calculating the IBE public key of public parameters that he needs for calculating the IBE public key of
the recipient. He obtains this information from a PPS that is hosted the recipient. He obtains this information from a PPS that is hosted
at a well-known URI. The IBE public parameters contain all of the at a well-known URI. The IBE public parameters contain all of the
information that the sender needs to create an IBE-encrypted message information that the sender needs to create an IBE-encrypted message
except for the identity of the recipient. [IBEPPS] describes the URI except for the identity of the recipient. Section 3 of this document
where a PPS is located, the format of IBE public parameters, and how describes the URI where a PPS is located, the format of IBE public
to obtain them. The URI from which users obtain IBE public parameters parameters, and how to obtain them. The URI from which users obtain
MUST be authenticated in some way as defined in [IBEPPS], for IBE public parameters MUST be authenticated in some way; PPS servers
example, by using the SSL 3.0 protocol [SSL3]. [IBEPPS] also MUST support TLS 1.1 [TLS] and MAY support SSL 3.0 [SSL] to satisfy
describes the way in which identity formats are defined and a minimum this requirement. Section 3 also describes the way in which identity
interoperable format that all PPSs and PKGs MUST support. This step formats are defined and a minimum interoperable format that all PPSs
is shown below in Figure 1. and PKGs MUST support. This step is shown below in Figure 1.
The sender of an IBE-encrypted message selects the PPS and The sender of an IBE-encrypted message selects the PPS and
corresponding PKG based on his local security policy. Different PPSs corresponding PKG based on his local security policy. Different PPSs
may provide public parameters that specify different IBE algorithms may provide public parameters that specify different IBE algorithms
or different key strengths, for example, or different PKGs may or different key strengths, for example, or require the use of PKGs
require different levels of authentication before granting IBE that require different levels of authentication before granting IBE
private keys. private keys.
IBE Public Parameter Request IBE Public Parameter Request
-----------------------------> ----------------------------->
Sender Public Parameter Server Sender Public Parameter Server
<----------------------------- <-----------------------------
IBE Public Parameters IBE Public Parameters
Figure 1 Requesting IBE Public Parameters Figure 1 Requesting IBE Public Parameters
2.2.2. Sender IBE-encrypts Message
2.2.2. Sender IBE-encrypts message
To IBE-encrypt a message, the sender chooses a content encryption key To IBE-encrypt a message, the sender chooses a content encryption key
(CEK) and uses it to encrypt his message and then encrypts the CEK (CEK) and uses it to encrypt his message and then encrypts the CEK
with the recipients IBE public key as described in [CMS]. This with the recipient`s IBE public key as described in [CMS]. This
operation is shown below in Figure 2. [IBCS] describes the algorithms operation is shown below in Figure 2. [IBCS] describes the algorithms
needed to implement two forms of IBE and [IBECMS] describes how to needed to implement two forms of IBE and [IBECMS] describes how to
use the Cryptographic Message Syntax (CMS) to encapsulate the use the Cryptographic Message Syntax (CMS) to encapsulate the
encrypted message along with the IBE information that the recipient encrypted message along with the IBE information that the recipient
needs to decrypt the message, including the URI of the PPS and PKG. needs to decrypt the message.
CEK ----> Sender ----> IBE-encrypted CEK CEK ----> Sender ----> IBE-encrypted CEK
^ ^
| |
| |
Recipients Identity Recipient`s Identity
and IBE Public Parameters and IBE Public Parameters
Figure 2 Using an IBE Public-key Algorithm to Encrypt Figure 2 Using an IBE Public-key Algorithm to Encrypt
2.3. Receiving and viewing an IBE-encrypted message 2.3. Receiving and Viewing an IBE-encrypted Message
The recipient of an IBE-encrypted message parses the message as The recipient of an IBE-encrypted message parses the message as
described in [IBECMS]. This gives him the URI where he can obtain the described in [IBECMS]. This gives him the URI where he can obtain the
IBE public parameters required to perform IBE calculations as well as IBE public parameters required to perform IBE calculations as well as
the identity that was used to encrypt the messsage. The PPS also the identity that was used to encrypt the message. The PPS also gives
gives the URI of the PKG where the recipient of an IBE-encrypted the URI of the PKG where the recipient of an IBE-encrypted message
message can obtain the IBE private keys. After successfully can obtain the IBE private keys. After successfully authenticating to
authenticating to this PKG the recipient, will receive the IBE this PKG the recipient receives the IBE private key over an HTTPS
private key. connection.
The PKG may allow users other than the intended recipient to receive The PKG may allow users other than the intended recipient to receive
some IBE private keys. Giving a mail filtering appliance permission some IBE private keys. Giving a mail filtering appliance permission
to obtain IBE private keys on behalf of users, for example, can allow to obtain IBE private keys on behalf of users, for example, can allow
the appliance to decrypt and scan encrypted messages for viruses or the appliance to decrypt and scan encrypted messages for viruses or
other malicious features. other malicious features.
2.3.1. Recipient obtains IBE public parameters from PPS 2.3.1. Recipient Obtains IBE Public Parameters from PPS
Before he can perform any IBE calculations related to the message Before he can perform any IBE calculations related to the message
that he has received, the recipient of an IBE-encrypted message needs that he has received, the recipient of an IBE-encrypted message needs
to obtain the IBE public parameters that were used in the encryption to obtain the IBE public parameters that were used in the encryption
operation. This operation is shown below in Figure 3. The comments in operation. This operation is shown below in Figure 3. The comments in
Section 2.2.1 also apply to this operation. Section 2.2.1 also apply to this operation.
IBE Public Parameter Request IBE Public Parameter Request
-----------------------------> ----------------------------->
Recipient Public Parameter Server Recipient Public Parameter Server
<----------------------------- <-----------------------------
IBE Public Parameters IBE Public Parameters
Figure 3 Requesting IBE Public Parameters Figure 3 Requesting IBE Public Parameters
2.3.2. Recipient obtains IBE private key from PKG 2.3.2. Recipient Obtains IBE Private Key from PKG
To obtain an IBE private key, the recipient of an IBE-encrypted To obtain an IBE private key, the recipient of an IBE-encrypted
message provides an identity that was used to calculate an IBE public message provides an identity that was used to calculate an IBE public
key to a PKG and requests the private key that corresponds to the IBE key to a PKG and requests the private key that corresponds to the IBE
public key. After providing the identity for which a private key is public key. After providing the identity for which a private key is
being requested, a user MUST authenticate to the PKG. [IBEPKG] being requested, a user MUST authenticate to the PKG. Section 4 of
defines the protocol for communicating with a PKG as well as a this document defines the protocol for communicating with a PKG as
minimum interoperable way to authenticate to a PKG that all IBE well as a minimum interoperable way to authenticate to a PKG that all
implementations MUST support. Because the security of IBE private IBE implementations MUST support. Because the security of IBE private
keys is vital to the overall security of an IBE system, 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 keys MUST be transported to recipients over a secure protocol. PKGs
MUST support the SSL v 3.0 [SSL3] protocol and SHOULD support the TLS MUST support TLS 1.1 [TLS] and MAY support SSL 3.0 [SSL] for
v 1.1 [TLS] protocol for transport of IBE private keys. This transport of IBE private keys. This operation is shown below in
operation is shown below in Figure 4. Figure 4.
IBE Private Key Request IBE Private Key Request
----------------------------> ---------------------------->
Recipient PKG Recipient PKG
<---------------------------- <----------------------------
IBE Private Key IBE Private Key
Figure 4 Obtaining an IBE Private Key Figure 4 Obtaining an IBE Private Key
2.3.3. Recipient decrypts IBE-encrypted message 2.3.3. Recipient Decrypts IBE-encrypted Message
After obtaining the necessary IBE private key, the recipient uses After obtaining the necessary IBE private key, the recipient uses
that IBE private key and the corresponding IBE public parameters to that IBE private key and the corresponding IBE public parameters to
decrypt the CEK. This operation is shown below in Figure 5. He then decrypt the CEK. This operation is shown below in Figure 5. He then
uses the CEK to decrypt the encrypted message content. uses the CEK to decrypt the encrypted message content as specified in
[IBECMS].
IBE-encrypted CEK ----> Recipient ----> CEK IBE-encrypted CEK ----> Recipient ----> CEK
^ ^
| |
| |
IBE Private Key IBE Private Key
and IBE Public Parameters and IBE Public Parameters
Figure 5 Using an IBE Public-key Algorithm to Decrypt Figure 5 Using an IBE Public-key Algorithm to Decrypt
3. Security Considerations 3. Public Parameter Lookup
This entire document relates to security considerations. 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:
4. IANA Considerations 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].
No further action by the IANA is necessary for the protocols 2. The URI of the PKG. Knowledge of this URI allows recipients to
described in this document. request a private key as described in Section 4 of this
document.
5. References 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]
5.1. Normative References 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.
[CMS] R. Housley, “Cryptographic Message Syntax,” RFC 3369, August The following section outlines the URI request method to retrieve a
parameter block and describes the structure of the parameter block
itself.
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.pem
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] and
MAY support SSL 3.0 [SSL]. When requesting the URI the client MUST
only accept the system parameter block if the server identity was
verified successfully by TLS 1.1 or SSL 3.0.
A successful GET request returns in its body the Base64 encoding of
the DER-encoded [DER] ASN.1 structure that is described in the next
section.
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 Validity,
ibePublicParameters IBEPublicParameters,
ibeIdentitySchema OBJECT IDENTIFIER,
ibeParamExtensions IBEParamExtensions
}
The version specifies the version of the parameter format. For the
format described in this document it MUST be set to 2. The district
name is a 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.
The validity for IBE public parameters are defined as follows:
ValidityPeriod ::= SEQUENCE {
notBefore GeneralizedTime,
notAfter GeneralizedTime
}
A client MUST verify that the IBE system parameters that it obtains
are currently within the validity period and SHOULD not use these
parameters if they are not.
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 OF IBEPublicParameter
IBEPublicParameter ::= SEQUENCE {
ibeAlgorithm OBJECT IDENTIFIER,
publicParameterData OCTET STRING
}
The ibeAlgorithm OID specifies an IBE algorithm. The
publicParameterData is a DER encoded 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].
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-Boyens
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.
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] and MAY support SSL
3.0 [SSL]. 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 or SSL 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:
<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>
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 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
<ibe:body> part of the key request.
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:
<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_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 <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 [B64] 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.
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 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.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
<ibe:location> element that specifies the URI 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 URI="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 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, could not be verified,
or do not allow access to keys for this identity.
5. ASN.1 Module
IBE1-module { joint-iso-itu(2) country(16) us(840) organization(1)
identicrypt(114334) ibcs(1) cms(4) module(5) version(1)
}
DEFINITIONS IMPLICIT TAGS ::= BEGIN
IBEOtherRecipientInfo ::= SEQUENCE {
oriType OBJECT IDENTIFIER,
oriValue IBERecipientInfo
}
ibeORIType OBJECT IDENTIFIER ::= { joint-iso-itu(2) country(16)
us(840) organization(1) identicrypt(114334) ibcs(1)
cms(4) ori-oid(1)
}
IBERecipientInfo ::= SEQUENCE {
cmsVersion INTEGER { v0(0) },
keyFetchMethod OBJECT IDENTIFIER,
recipientIdentity IBEIdentityInfo,
serverInfo SEQUENCE OF OIDValuePairs OPTIONAL,
encryptedKey EncryptedKey
}
IBEIdentityInfo ::= SEQUENCE {
District UTF8STRING,
Serial INTEGER,
identitySchema OBJECT IDENTIFIER,
identityData OCTET STRING
}
OIDValuePairs ::= SEQUENCE {
fieldID OBJECT IDENTIFIER,
fieldData OCTET STRING
}
EmailIdentitySchema ::= SEQUENCE {
rfc822Email UTF8STRING,
time GeneralizedTime
}
cmsIdentityOID OBJECT IDENTIFIER ::= { joint-iso-itu(2) country(16)
us(840) organization(1) identicrypt(114334) keyschemas(2)
icschemas(1) rfc822email(1)
}
cmsPPSOID OBJECT IDENTIFIER ::= { joint-iso-itu(2) country(16)
us(840) organization(1) identicrypt(114334) pps-schemas(3)
ic-schemas(1) pps-uri(1)
}
ibcs OBJECT IDENTIFIER ::= {
joint-iso-itu(2) country(16) us(840) organization(1)
identicrypt(114334) ibcs(1)
}
-- The IBE System parameters consist of a set of public parameters
-- for the encryption algorithms supported by the district,
-- the identity schema, the URI of the PKG and further optional
-- parameters
IBESysParams ::= SEQUENCE {
Version INTEGER { v2(2) },
districtName UTF8String,
districtSerial INTEGER,
validity Validity,
ibePublicParameters IBEPublicParameters,
ibeIdentitySchema OBJECT IDENTIFIER,
ibeParamExtensions IBEParamExtensions
}
-- Validity designates the time interval for which these parameters
-- are valid.
Validity ::= SEQUENCE {
notBefore GeneralizedTime,
notAfter GeneralizedTime
}
-- Public Parameters for the IBE Algorithm
-- ibeAlgorithm is the algorithm OID from IBCS, e.g. "bb" or "bf"
-- publicParameterData is a DER encoded ASN.1 public parameter
-- block, e.g. BFPublicParamaters, BBPublicParamaters
IBEPublicParameters ::= SEQUENCE OF IBEPublicParameter
IBEPublicParameter ::= SEQUENCE {
ibeAlgorithm OBJECT IDENTIFIER,
publicParameterData OCTET STRING
}
IBEParamExtensions ::= SEQUENCE OF IBEParamExtension
IBEParamExtension ::= SEQUENCE {
ibeParamExtensionOID OBJECT IDENTIFIER,
ibeParamExtensionValue OCTET STRING
}
ibeParamExt OBJECT IDENTIFIER ::= {
ibcs ibcs3(3) parameter-extensions(2)
}
-- Defined Extensions:
-- pkgURI: URI of the PKG, value is a UTF8String
pkgURI OBJECT IDENTIFIER ::= { ibeParamExt pkgURI(1) }
-- Private Key Format
IBEPrivateKeyReply ::= SEQUENCE {
pkgIdentity IBEIdentityInfo,
pgkKeyType OBJECT IDENTIFIER,
pkgKeyData OCTET STRING,
pkgOptions IBEParamExtensions
}
END
6. Security Considerations
6.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 will give the equivalent of
80-bit security, 112-bit security and 128-bit security. We assume
that competent administrators of an IBE system will select parameters
that provide a sufficient resistance to cryptanalytic attacks by
adversaries.
Attacks that require access to machines used by either the client or
the server components defined in this document are also outside the
scope of this document. Attacks that give an attacker the ability to
access or change the information on a PPS or PKG, especially the
cryptographic material, will defeat the security of an IBE system. To
address this concern, the PPS and PKG servers SHOULD be configured in
accordance with best current practices [NIST]. An IBE system should
be operated in an environment where such illicit access is infeasible
for attackers to obtain.
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.
6.2. Attacks that are within the scope of this document
Attacks that passively monitor information transmitted between users
of an IBE system and the PPS and PKG are within the scope of this
document, as are attacks that let an adversary masquerade as a PPS or
PKG are also within the scope of this document.
6.3. Attacks that the protocols defined in this document are
susceptible to
The protocols defined in this document do not explicitly defend
against an attacker masquerading as a legitimate IBE PPS or PKG. To
provide protection against this possibility, client software that
implements the protocols defined in this document SHOULD have a user
interface that allows users to view the details of connections to PPS
and PKG servers so 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.
6.4. Attacks that the protocols defined in this document protect
against
All communications between users of an IBE system and the PPS or PKG
are encrypted using TLS 1.1 [TLS] or SSL 3.0 [SSL], which should
provide an adequate level of protection for such communications.
The authentication method used by an IBE PKG should also be
sufficiently strong to prevent attackers from easily guessing them
through trial and error.
7. IANA Considerations
The XML defined in this document will be registered with the IANA per
the instructions in RFC 3688, The IETF XML Registry, once the format
has been agreed upon.
8. References
8.1. Normative References
[AUTH] 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.
[B64] N. Freed, 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. 2002.
[IBEPPS] G. Appenzeller, “Identity-based Encryption Parameter and [DER] ITU-T Recommendation X.680: Information Technology - Abstract
Policy Lookup,” draft-ietf-smime-ibepps-00.txt, June 2006. Syntax Notation One, 1997.
[IBCS] X. Boyen, L. Martin, “Identity-Based Cryptography Standard [DOM] P. Mockapetris, "Domain Names - Implementation and
Specification," RFC 1035, November 1987.
[HTTP] 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.
[IBCS] X. Boyen, L. Martin, "Identity-Based Cryptography Standard
(IBCS) #1: Supersingular Curve Implementations of the BF and (IBCS) #1: Supersingular Curve Implementations of the BF and
BB1 Cryptosystems,” draft-ietf-smime-ibcs-00.txt, June 2006. BB1 Cryptosystems," draft-ietf-martin-ibcs-00.txt, September
2006.
[IBECMS] M. Schertler, L. Martin, “Using the Boneh-Franklin identity- [IBECMS] L. Martin, M. Schertler, "Using the Boneh-Franklin identity-
based encryption algorithm with the Cryptographic Message based encryption algorithm with the Cryptographic Message
Syntax (CMS),” draft-ietf-smime-bfibecms-01.txt, June 2006. Syntax (CMS)," draft-ietf-smime-bfibecms-01.txt, September
2006.
[IBEPKG] G. Appenzeller, Identity-based Encryption Private Key [KEY] S. Brander, "Key Words for Use in RFCs to Indicate Requirement
Request Protocol, draft-ietf-smime-ibepkg-00.txt, June 2006. Levels," BCP 14, RFC 2119, March 1997.
[KEY] S. Brander, “Key Words for Use in RFCs to Indicate Requirement [NIST] M. Souppaya, J. Wack, K. Kent, "Security Configuration
Levels,” BCP 14, RFC 2119, March 1997. Checklist Program for IT Products - Guidance for Checklist
Users and Developers," NIST Special Publication SP 800-70, May
2005.
[P1363] IEEE P1363.3, “Standards Specifications for Public-Key [P1363] IEEE P1363, "Standards Specifications for Public-Key
Cryptography,” 2001. Cryptography," 2001.
[RFC2818] E. Rescorla, "HTTP over TLS," RFC 2818, May 2000.
[RFC2827] P. Ferguson, D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing," RFC 2827, BCP 38, May 2000.
[RFC3882] D. Turk, "Configuring BGP to Block Denial-of-Service
Attacks," RFC 3882, September 2004.
[SSL3] A. Frier, P. Karlton, P. Kocher, "The SSL 3.0 Protocol," [SSL3] A. Frier, P. Karlton, P. Kocher, "The SSL 3.0 Protocol,"
Netscape Communications Corp., Nov 18, 1996. Netscape Communications Corp., Nov 18, 1996.
[TLS] T. Dierks, E. Rescorla, “The Transport Layer Security Protocol [TLS] T. Dierks, E. Rescorla, "The Transport Layer Security (TLS)
Version 1.1,” RFC 4346, April 2006. Protocol Version 1.1," RFC 4346, April 2006.
Authors’ Addresses [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, August
1998.
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 Luther Martin
Voltage Security Voltage Security
1070 Arastradero Rd Suite 100 1070 Arastradero Rd Suite 100
Palo Alto CA 94304 Palo Alto CA 94304
Phone: +1 650 543 1280 Phone: +1 650 543 1280
Email: martin@voltage.com Email: martin@voltage.com
Mark Schertler Mark Schertler
skipping to change at page 8, line 20 skipping to change at page 23, line 5
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an 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 attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at ietf-
ietf-ipr@ietf.org. ipr@ietf.org.
Disclaimer of Validity Disclaimer of Validity
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2006). Copyright (C) the Internet Society (2006).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 47 change blocks. 
100 lines changed or deleted 708 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/