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

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