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