draft-ietf-smime-ibearch-05.txt   draft-ietf-smime-ibearch-06.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: March 2008 Tumbleweed Communications Expires: May 2008 Tumbleweed Communications
September 2007 November 2007
Identity-based Encryption Architecture Identity-based Encryption Architecture
<draft-ietf-smime-ibearch-05.txt> <draft-ietf-smime-ibearch-06.txt>
Status of this Document Status of this Document
By submitting this Internet-Draft, each author represents By submitting this Internet-Draft, each author represents
that any applicable patent or other IPR claims of which that any applicable patent or other IPR claims of which
he or she is aware have been or will be disclosed, and he or she is aware have been or will be disclosed, and
any of which he or she becomes aware will be disclosed, any of which he or she becomes aware will be disclosed,
in accordance with 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
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 The list of Internet-Draft Shadow Directories can be
accessed at accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
Abstract Abstract
This document describes the security architecture required This document describes the security architecture required
to implement identity-based encryption, a public-key to implement identity-based encryption, a public-key
encryption technology that uses a user's identity to encryption technology that uses a user's identity as a
generate their public key. 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 IBE-encrypted.........4
2.2.1. Sender Obtains Recipient's Public Parameters5 2.2.1. Sender Obtains Public Parameters...........5
2.2.2. Construct and Send IBE-encrypts Message....6 2.2.2. Construct and Send IBE-encrypted 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 PPS7 2.3.1. Recipient Obtains Public Parameters........7
2.3.2. Recipient Obtains IBE Private Key from PKG.8 2.3.2. Recipient Obtains IBE Private Key..........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............................14
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.........................16
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................18
4.8. Responses Indicating an Error..................17 4.8. Responses Indicating an Error..................18
5. Security Considerations.............................18 5. ASN.1 Module........................................19
5.1. Attacks that are outside the scope of this 6. Security Considerations.............................21
document............................................18 6.1. Attacks that are outside the scope of this
5.2. Attacks that are within the scope of this document............................................21
document............................................19 6.2. Attacks that are within the scope of this
5.2.1. Attacks to which the protocols defined in document............................................22
this document are susceptible....................19 6.2.1. Attacks to which the protocols defined in
6. IANA Considerations.................................20 this document are susceptible....................22
7. References..........................................21 7. IANA Considerations.................................23
7.1. Normative References...........................21 8. References..........................................24
7.2. Informative References.........................22 8.1. Normative References...........................24
Authors' Addresses.....................................24 8.2. Informative References.........................25
Intellectual Property Statement........................24 Authors' Addresses.....................................26
Disclaimer of Validity.................................25 Intellectual Property Statement........................26
Copyright Statement....................................25 Disclaimer of Validity.................................27
Acknowledgment.........................................25 Copyright Statement....................................27
Acknowledgment.........................................27
1. Introduction 1. Introduction
This document describes the security architecture This document describes the security architecture
required to implement identity-based encryption, a required to implement identity-based encryption, a
public-key encryption technology that uses a user's public-key encryption technology that uses a user's
identity as a public key. identity as a public key. Objects used in this
implementation are defined using ASN.1 [ASN1].
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be "MAY", and "OPTIONAL" in this document are to be
interpreted as described in [KEY]. interpreted as described in [KEY].
2. Identity-based Encryption 2. Identity-based Encryption
skipping to change at page 4, line 7 skipping to change at page 4, line 7
with each other, either directly or through a proxy such with each other, either directly or through a proxy such
as a directory server, before sending secure messages. as a directory server, before sending secure messages.
This document describes an IBE-based messaging system and This document describes an IBE-based messaging system and
how the components of the system work together. The how the components of the system work together. The
components required for a complete IBE messaging system components required for a complete IBE messaging system
are the following: are the following:
o A Private-key Generator (PKG). The PKG contains o A Private-key Generator (PKG). The PKG contains
the cryptographic material, known as a master the cryptographic material, known as a master
secret, for generating an individual's IBE secret, which is used for generating an
private key. A PKG accepts an IBE user's private individual's IBE private key. A PKG accepts an
key request and after successfully IBE user's private key request, and after
authenticating them in some way returns the IBE successfully authenticating them in some way
private key. returns, their IBE private key.
o A Public Parameter Server (PPS). IBE System o A Public Parameter Server (PPS). IBE System
Parameters include publicly sharable Parameters include publicly-sharable
cryptographic material, known as IBE public cryptographic material, known as IBE public
parameters, and policy information for the PKG. parameters, and policy information for an
A PPS provides a well-known location for secure associated PKG. A PPS provides a well-known
distribution of IBE public parameters and policy location for secure distribution of IBE public
information for the IBE PKG. parameters and policy information for the IBE
PKG.
A logical architecture would be to have a PKG/PPS per a A logical architecture would be to have a PKG/PPS per a
name space, such as a DNS zone. The organization that name space, such as a DNS zone. The organization that
controls the DNS zone would also control the PKG/PPS and controls the DNS zone would also control the PKG/PPS and
thus the determination of which PKG/PSS to use when thus the determination of which PKG/PSS to use when
creating public and private keys for the organization's creating public and private keys for the organization's
members. In this case the PPS URI can be uniquely created members. In this case the PPS URI can be uniquely created
by the form of the identity that it supports. This by the form of the identity that it supports. This
architecture would make it clear which set of public architecture would make it clear which set of public
parameters to use and where to retrieve them for a given parameters to use and where to retrieve them for a given
identity (i.e. an RFC 2822 address [TEXTMSG]). identity (for example, an RFC 2822 address [TEXTMSG]).
IBE encrypted messages can use standard message formats, IBE encrypted messages can use standard message formats,
such as the Cryptographic Message Syntax [CMS]. How to such as the Cryptographic Message Syntax [CMS]. How to
use IBE with CMS is defined in [IBECMS]. Unless use IBE with CMS is defined in [IBECMS].
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 Note that IBE algorithms are used only for encryption, so
if digital signatures are required they will need to be if digital signatures are required they will need to be
provided 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 IBE-encrypted
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 A user of an IBE system is capable of calculating
creation of unique public and private keys. A user the public key of a recipient after he obtains the
of an IBE system is capable of calculating the
public key of a recipient after he obtains the
public parameters for their IBE system. Once the public parameters for their IBE system. Once the
public parameters are obtained, IBE-encrypted public parameters are obtained, IBE-encrypted
messages can be sent. 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 In addition to the IBE public parameters, all that
parameters, is the recipient's identity in order to is needed to construct an IBE-encrypted message is
generate their public key for use in encrypting the recipient's identity, which can be used to
messages to them. When this identity is the same as generate their public key. When this identity is
the identity that a message would be addressed to, the same as the identity that a message would be
then no more information is needed from a user to addressed to, then no more information is needed
send someone a secure message then is needed to from a user to send them a secure message then is
send them an unsecured message. This is one of the needed to send them an unsecured message. This is
major benefits of an IBE-based secure messaging one of the major benefits of an IBE-based secure
system. Examples of identities can be an messaging system. Examples of identities can be an
individual, group, or role identifiers. individual, group, or role identifiers.
2.2.1. Sender Obtains Recipient's Public Parameters 2.2.1. Sender Obtains Public Parameters
The sender of a message obtains the IBE public parameters The sender of a message obtains the IBE public parameters
that he needs for calculating the IBE public key of the that he needs for calculating the IBE public key of the
recipient from a PPS that is hosted at a well-known URI. recipient from a PPS that is hosted at a well-known URI.
The IBE public parameters contain all of the information The IBE public parameters contain all of the information
that the sender needs to create an IBE-encrypted message that the sender needs to create an IBE-encrypted message
except for the identity of the recipient. Section 3 of except for the identity of the recipient. Section 3 of
this document describes the URI [URI] where a PPS is this document describes the URI [URI] where a PPS is
located, the format of IBE public parameters, and how to located, the format of IBE public parameters, and how to
obtain them. The URI from which users obtain IBE public obtain them. The URI from which users obtain IBE public
skipping to change at page 6, line 12 skipping to change at page 6, line 12
Figure 1 Requesting IBE Public Parameters Figure 1 Requesting IBE Public Parameters
The sender of an IBE-encrypted message selects the PPS The sender of an IBE-encrypted message selects the PPS
and 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 example, or require the use of PKGs that require
different levels of authentication before granting IBE different levels of authentication before granting IBE
private keys. private keys.
2.2.2. Construct and Send IBE-encrypts Message 2.2.2. Construct and Send IBE-encrypted 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 encryption key (CEK) and uses it to encrypt his message
message and then encrypts the CEK with the recipient's and then encrypts the CEK with the recipient's IBE public
IBE public key as described in [CMS]. This operation is key as described in [CMS]. This operation is shown below
shown below in Figure 2. [IBCS] describes the algorithms in Figure 2. [IBCS] describes the algorithms needed to
needed to implement two forms of IBE and [IBECMS] implement two forms of IBE and [IBECMS] describes how to
describes how to use the Cryptographic Message Syntax use the Cryptographic Message Syntax (CMS) to encapsulate
(CMS) to encapsulate the encrypted message along with the the encrypted message along with the IBE information that
IBE information that the recipient needs to decrypt the the recipient needs to decrypt the message.
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 In order to read an encrypted message, a recipient of an
IBE-encrypted message parses the message as described in IBE-encrypted message parses the message as described in
[IBECMS]. This gives him the URI he needs to obtain the [IBECMS]. This gives him the URI he needs to obtain the
IBE public parameters required to perform IBE IBE public parameters that are required to perform IBE
calculations as well as the identity that was used to calculations as well as a component of the identity that
encrypt the message. Next the recipient must carry out was used to encrypt the message. Next the recipient must
the following steps: 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 An IBE system's public parameters allow it to
uniquely create public and private keys. The uniquely create public and private keys. The
recipient of an IBE-encrypted message can decrypt recipient of an IBE-encrypted message can decrypt
an IBE-encrypted message if he has both the IBE an IBE-encrypted message if he has both the IBE
public parameters and the necessary IBE private public parameters and the necessary IBE private
key. The PPS can also provide the URI of the PKG key. The PPS can also provide the URI of the PKG
where the recipient of an IBE-encrypted message can where the recipient of an IBE-encrypted message can
skipping to change at page 7, line 19 skipping to change at page 7, line 18
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 To decrypt an IBE-encrypted message, in addition to
the IBE public parameters the recipient needs to the IBE public parameters the recipient needs to
obtain the private key that corresponds to the obtain the private key that corresponds to the
public key that the sender used. The IBE private public key that the sender used. The IBE private
key is obtained after successfully authenticating key is obtained after successfully authenticating
to a private key generator (PKG), a trusted third to a private key generator (PKG), a trusted third
party that calculates private keys for users. The party that calculates private keys for users. The
recipient receives the IBE private key over an recipient then receives the IBE private key over a
HTTPS connection. secure 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 The PKG may allow users other than the intended recipient
to 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 appliance permission to obtain IBE private keys on behalf
of users, for example, can allow the appliance to decrypt of users, for example, can allow the appliance to decrypt
and scan encrypted messages for viruses or other and scan encrypted messages for viruses or other
malicious features. malicious features.
2.3.1. Recipient Obtains Public Parameters from PPS 2.3.1. Recipient Obtains Public Parameters
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 encrypted message needs to obtain the IBE public
parameters that were used in the encryption operation. parameters that were used in the encryption operation.
This operation is shown below in Figure 3. The comments This operation is shown below in Figure 3. Because the
in Section 2.2.1 also apply to this operation. use of the correct public parameters is vital to the
overall security of an IBE system, IBE public parameters
MUST be transported to recipients over a secure protocol.
PPSs MUST support TLS 1.1 [TLS] or its successors, using
the latest version supported by both parties, for
transport of IBE public parameters. In addition, users
MUST verify that the subject name in the server
certificate matches the URI of the PPS. The comments 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
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 encrypted message provides the IBE public key used to
encrypt the message and their authentication credentials encrypt the message and their authentication credentials
to a PKG and requests the private key that corresponds to to a PKG and requests the private key that corresponds to
the IBE public key. Section 4 of this document defines the IBE public key. Section 4 of this document defines
the protocol for communicating with a PKG as well as a the protocol for communicating with a PKG as well as a
minimum interoperable way to authenticate to a PKG that minimum interoperable way to authenticate to a PKG that
all IBE implementations MUST support. Because the all IBE implementations MUST support. Because the
security of IBE private keys is vital to the overall security of IBE private keys is vital to the overall
skipping to change at page 9, line 25 skipping to change at page 9, line 37
public parameters for the BF and BB1 algorithms are public parameters for the BF and BB1 algorithms are
described in [IBCS]. 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 3. The schema to format the identity strings. When
issuing a private key, the PKG often wants to limit issuing a private key, the PKG often wants to limit
who can obtain private keys. For example for an who can obtain private keys. For example for an
identity string that contains "bob@example.com", identity string that contains "bob@example.com,"
only the owner of the identity string should be able only the owner of the identity string should be able
to request the private key. To ensure that the PKG to request the private key. To ensure that the PKG
can interpret the identity string for which a can interpret the identity string for which a
private key is requested, the encryption engine and private key is requested, the encryption engine and
the PKG have to use the same schema for identity the PKG have to use the same schema for identity
strings. Identity schemas are described in [IBECMS] strings. Identity schemas are described in [IBECMS]
This section specifies how a component of an IBE system This section specifies how a component of an IBE system
can retrieve these parameters. A sending or receiving can retrieve these parameters. A sending or receiving
client MUST allow configuration of these parameters client MUST allow configuration of these parameters
skipping to change at page 10, line 33 skipping to change at page 10, line 44
successfully by TLS 1.1 [TLS] 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 encoding of the DER-encoded [DER] IBESysParams structure
that is described in the next section. This structure that is described in the next section. This structure
MUST be served as an application/octet-stream MIME type MUST be served as an application/octet-stream MIME type
[MIME]. [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 structure of the form
IBESysParams ::= SEQUENCE { IBESysParams ::= SEQUENCE {
version INTEGER { v2(2) }, version INTEGER { v2(2) },
districtName UTF8String, districtName IA5String,
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 The version specifies the version of the IBESysParams
format. For the format described in this document it MUST format. For the format described in this document it MUST
be set to 2. The district name is an UTF8String that MUST be set to 2. The district name is an IA5String that MUST
be a valid domain name as defined by [DOM]. The be a valid domain name as defined by [DOM]. The
districtSerial is a serial number that represents a districtSerial is a serial number that represents a
unique set of IBE public parameters. If new parameters unique set of IBE public parameters. If new parameters
are published for a district, it MUST be increased to a are published for a district, it MUST be increased to a
number greater than the previously-used serial number. number greater than the previously-used serial number.
The validity period or lifetime of a specific instance of The validity period or lifetime of a specific instance of
the 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 A client MUST verify that the date on which it utilizes
the IBE system parameters falls between the notBefore the IBE system parameters falls between the notBefore
time and the notAfter times of the IBE system parameters time and the notAfter time of the IBE system parameters
and SHOULD not use 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 configurable interval to ensure that it has the most
current version on the IBE system parameters. current version on the IBE system parameters.
It is possible to create identities for use in IBE that It is possible to create identities for use in IBE that
have a time component, as described in [IBECMS]. If such have a time component, as described in [IBECMS]. If such
an identity is used, the time component of the identity an identity is used, the time component of the identity
MUST fall between the notBefore time and the notAfter MUST fall between the notBefore time and the notAfter
times of the IBE system parameters. times of the IBE system parameters.
IBEPublicParameters is a set of public parameters that IBEPublicParameters is a structure containing public
correspond to IBE algorithms that the PKG associated with parameters that correspond to IBE algorithms that the PKG
this district understands. associated with 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 publicParameterData is a DER-encoded [DER] structure that
structure that contains the actual cryptographic contains the actual cryptographic parameters. Its
parameters. Its specific structure depends on the specific structure depends on the algorithm. The OIDs for
algorithm. The OIDs for two IBE algorithms, the Boneh- two IBE algorithms, the Boneh-Franklin and Boneh-Boyen
Franklin and Boneh-Boyen algorithms and their algorithms and their publicParameterData structures are
publicParameterData structures are defined in [IBCS]. 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 contain two or more IBEPublicParameter entries with the
same algorithm. A client that wants to use IBESysParams same algorithm. A client that wants to use IBESysParams
can chose any of the algorithms specified in the can chose any of the algorithms specified in the
publicParameterData structure. A client MUST implement at publicParameterData structure. A client MUST implement at
least the Boneh-Franklin algorithm and MAY implement the least the Boneh-Franklin algorithm and MAY implement the
Boneh-Boyen and other algorithms. If a client does not Boneh-Boyen and other algorithms. If a client does not
support any of the supported algorithms it MUST generate support any of the supported algorithms it MUST generate
skipping to change at page 12, line 44 skipping to change at page 13, line 22
The contents of the octet string are defined by the The contents of the octet string are defined by the
specific extension type. The System Parameters of a specific extension type. The System Parameters of a
district MAY have any number of extensions, including district MAY have any number of extensions, including
zero. zero.
The IBEParamExtension pkgURI defines the URI of the The IBEParamExtension pkgURI defines the URI of the
Private Key Generator of the district. If the PKG is Private Key Generator of the district. If the PKG is
publicly accessible, this extension SHOULD be present to publicly accessible, this extension SHOULD be present to
allow the automatic retrieval of private keys for allow the automatic retrieval of private keys for
recipients of encrypted messages. For this extension the recipients of encrypted messages. For this extension the
OCTET STRING contains a UTF8String with the URI of the OCTET STRING is an IA5String containing the URI of the
key server. 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
skipping to change at page 14, line 41 skipping to change at page 15, line 27
</ibe:keyRequest> </ibe:keyRequest>
</ibe:body> </ibe:body>
</ibe:request> </ibe:request>
A <ibe:request> SHOULD include a <ibe:clientID> element, A <ibe:request> SHOULD include a <ibe:clientID> element,
an ASCII string that identifies the client type and an ASCII string that identifies the client type and
client version. client version.
A key request MUST contain a valid ibeIdentityInfo that A key request MUST contain a valid ibeIdentityInfo that
the private key is requested for. This identity is the the private key is requested for. This identity is the
base64 encoding of the DER encoding [DER] of the ASN.1 base64 encoding of the DER encoding [DER] of the
structure IBEIdentityInfo as defined in [IBECMS]. structure IBEIdentityInfo, an example of which is defined
in [IBECMS].
A key request MUST contain a <ibe:algorithmOID> element A key request MUST contain a <ibe:algorithmOID> element
that contains a XER [XER] encoded ASN.1 OBJECT IDENTIFIER that contains a DER-encoded [DER] OBJECT IDENTIFIER that
[DER] that identifies the algorithm for which a key is identifies the algorithm for which a key is requested.
requested. OIDs for the BB1 and BF algorithms are listed OIDs for the BB1 and BF algorithms are listed in [IBCS].
in [IBCS].
A client MAY include optional additional XML elements in A client MAY include optional additional XML elements in
the <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. authenticate the client before issuing the key.
Authentication may either be done through the key request Authentication may either be done through the key request
structure or as part of the secure transport protocol. structure or as part of the secure transport protocol.
skipping to change at page 16, line 33 skipping to change at page 17, line 17
<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 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 SIZE (1..MAX) OF PKGOption
}
PKGOption ::= SEQUENCE {
optionID OBJECT IDENTIFIER,
critical BOOLEAN DEFAULT FALSE,
optionValue OCTET STRING
} }
The pkgIdentity is an IBEIdentityInfo structure as The pkgIdentity is an IBEIdentityInfo structure as
defined in [IBECMS]. It MUST be identical to the defined in [IBECMS]. It MUST be identical to the
IBEIdentityInfo structure that was sent in the key IBEIdentityInfo structure that was sent in the key
request. request.
The pkgAlgorithm is an OID that identifies the algorithm The pkgAlgorithm is an OID that identifies the algorithm
of 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 pkgKeyData is a structure that contains the actual
the actual private key. Private-key formats for the BB private key. Private-key formats for the BB and BF
and BF algorithms are defined in [IBCS]. algorithms are defined in [IBCS].
A server MAY pass back additional information to a client A server MAY pass back additional information to a client
in the pkgOptions structure. The contents of the in the pkgOptions structure.
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 replies to the client with response code 201 and the body
MUST contain a <ibe:location> element that specifies the MUST contain a <ibe:location> element that specifies the
URI of the authentication mechanism. Such a response MUST URI of the authentication mechanism. Such a response MUST
be encoded as an application/xhtml+xml MIME type [XHTML]. be encoded as an application/xhtml+xml MIME type [XHTML].
An example of such a response is shown below. An example of such a response is shown below.
skipping to change at page 17, line 39 skipping to change at page 18, line 31
</ibe:response> </ibe:response>
The client can now contact the authentication mechanism The client can now contact the authentication mechanism
to 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 obtained the credential, it sends a new key request to
the PKG with the correct authentication credentials the PKG with the correct authentication credentials
contained in the 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 If the server replies with an error code from 300 through
MUST abort the request and discard any data that is part 399, the client MUST abort the request and discard any
of the response. data that is part of the response.
The meaning of the response codes for errors is as The meaning of the response codes for errors is as
follows: 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 301 - The request to the server is invalid or the server
is 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 303 - The server is not able to serve key requests for
this type of client. A client with a newer version of the this type of client. A client with a newer version of the
protocol 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 authentication credentials provided by the user were
invalid, could not be verified, or do not allow access to invalid, could not be verified, or do not allow access to
keys for this identity. keys for this identity.
5. Security Considerations 5. ASN.1 Module
5.1. Attacks that are outside the scope of this document The following ASN.1 module summarizes the ASN.1
definitions discussed in this document.
IBEARCH-module { joint-iso-itu-t(2) country(16) us(840)
organization(1) identicrypt(114334) ibcs(1) ibearch(5)
module(5) version(1)
}
DEFINITIONS IMPLICIT TAGS ::= BEGIN
IBESysParams ::= SEQUENCE {
version INTEGER { v2(2) },
districtName IA5String,
districtSerial INTEGER,
validity ValidityPeriod,
ibePublicParameters IBEPublicParameters,
ibeIdentitySchema OBJECT IDENTIFIER,
ibeParamExtensions IBEParamExtensions OPTIONAL
}
ValidityPeriod ::= SEQUENCE {
notBefore GeneralizedTime,
notAfter GeneralizedTime
}
IBEPublicParameters ::= SEQUENCE (1..MAX) OF
IBEPublicParameter
IBEPublicParameter ::= SEQUENCE {
ibeAlgorithm OBJECT IDENTIFIER,
publicParameterData OCTET STRING
}
IBEParamExtensions ::= SEQUENCE OF IBEParamExtension
IBEParamExtension ::= SEQUENCE {
ibeParamExtensionOID OBJECT IDENTIFIER,
ibeParamExtensionValue OCTET STRING
}
ibcs OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840)
organization(1) identicrypt(114334) ibcs(1)
}
ibeParamExt OBJECT IDENTIFIER ::= {
ibcs ibcs3(3) parameter-extensions(2)
}
pkgURI OBJECT IDENTIFIER ::= { ibeParamExt pkgURI(1) }
IBEPrivateKeyReply ::= SEQUENCE {
pkgIdentity IBEIdentityInfo,
pgkAlgorithm OBJECT IDENTIFIER,
pkgKeyData OCTET STRING,
pkgOptionsSEQUENCE SIZE (1..MAX) OF PKGOption
}
PKGOption ::= SEQUENCE {
optionID OBJECT IDENTIFIER,
critical BOOLEAN DEFAULT FALSE,
optionValue OCTET STRING
}
END
6. Security Considerations
6.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. implement IBE are outside the scope of this document.
Such attacks are detailed in [IBCS], which defines Such attacks are detailed in [IBCS], which defines
parameters that give 80-bit, 112-bit and 128-bit parameters that give 80-bit, 112-bit and 128-bit
encryption strength. We assume that capable encryption strength. We assume that capable
administrators of an IBE system will select parameters administrators of an IBE system will select parameters
that provide a sufficient resistance to cryptanalytic that provide a sufficient resistance to cryptanalytic
attacks by adversaries. attacks by adversaries.
skipping to change at page 19, line 9 skipping to change at page 22, line 16
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 implementing the protocols that are defined in this
document are trustworthy and will not abuse their document are trustworthy and will not abuse their
authority to bypass the security provided by an IBE authority to bypass the security provided by an IBE
system. Similarly, we assume that users of an IBE system system. Similarly, we assume that users of an IBE system
will behave responsibly, not sharing their authentication will behave responsibly, not sharing their authentication
credentials with others. Thus attacks that require such credentials with others. Thus attacks that require such
assumptions are outside the scope of this document. assumptions are outside the scope of this document.
5.2. Attacks that are within the scope of this document 6.2. Attacks that are within the scope of this document
Attacks within the scope of this document are those that Attacks within the scope of this document are those that
allow an adversary to: allow an adversary to:
o passively monitor information transmitted o passively monitor information transmitted
between users of an IBE system and the PPS and between users of an IBE system and the PPS and
PKG 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 o easily guess an IBE users authentication
credential credential
5.2.1. Attacks to which the protocols defined in this 6.2.1. Attacks to which the protocols defined in this
document are susceptible document are susceptible
All communications between users of an IBE system and the All communications between users of an IBE system and the
PPS or PKG are protected using TLS 1.1 [TLS]. The IBE PPS or PKG are protected using TLS 1.1 [TLS]. The IBE
system defined in this document provides no additional system defined in this document provides no additional
security protections for the communications between IBE security protections for the communications between IBE
users and the PPS or PKG. Therefore the described IBE users and the PPS or PKG. Therefore the described IBE
system is completely dependent on the TLS security system is completely dependent on the TLS security
mechanisms for authentication of the PKG or PPS server mechanisms for authentication of the PKG or PPS server
and for confidentiality and integrity of the and for confidentiality and integrity of the
skipping to change at page 20, line 18 skipping to change at page 23, line 25
users unable to encrypt or decrypt using IBE, and users users unable to encrypt or decrypt using IBE, and users
of an IBE system SHOULD take the appropriate of an IBE system SHOULD take the appropriate
countermeasures [DOS, BGPDOS] that their use of IBE countermeasures [DOS, BGPDOS] that their use of IBE
requires. 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 SHOULD be of sufficient strength to prevent attackers
from easily guessing the IBE user's authentication from easily guessing the IBE user's authentication
credentials through trial and error. credentials through trial and error.
6. IANA Considerations 7. IANA Considerations
The XML defined in this document will be registered with The XML defined in this document will be registered with
the IANA per the instructions in RFC 3688, The IETF XML the IANA per the instructions in RFC 3688, The IETF XML
Registry. Registry.
URI: URI:
urn:ietf:params:xml:ns:ibe urn:ietf:params:xml:ns:ibe
Registrant Contact: Registrant Contact:
skipping to change at page 21, line 30 skipping to change at page 24, 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
7. References 8. References
7.1. Normative References 8.1. Normative References
[ASN1] ITU-T Recommendation X.680: Information Technology
- Abstract Syntax Notation One, 1997.
[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 [B64] N. Freed and N. Borenstein, Multipurpose Internet
Mail Extensions(MIME) Part One: Format of Internet Mail Extensions(MIME) Part One: Format of Internet
Message Bodies," RFC 2045, November 1996. Message Bodies," RFC 2045, November 1996.
[CMS] R. Housley, "Cryptographic Message Syntax," RFC [CMS] R. Housley, "Cryptographic Message Syntax," RFC
3852, July 2004. 3852, July 2004.
[DER] CCITT, "Recommendation X.209: Specification of
Basic Encoding Rules for Abstract Syntax Notation
One (ASN.1)," 1998.
[DOM] P. Mockapetris, "Domain Names - Implementation and [DOM] P. Mockapetris, "Domain Names - Implementation and
Specification," RFC 1035, November 1987. Specification," RFC 1035, November 1987.
[DOS] P. Ferguson and D. Senie, "Network Ingress [DOS] P. Ferguson and D. Senie, "Network Ingress
Filtering: Defeating Denial of Service Attacks Filtering: Defeating Denial of Service Attacks
which employ IP Source Address Spoofing," RFC 2827, which employ IP Source Address Spoofing," RFC 2827,
BCP 38, May 2000. BCP 38, May 2000.
[HTTP] R. Fielding, et al., "Hypertext Transfer Protocol [HTTP] R. Fielding, et al., "Hypertext Transfer Protocol
-- HTTP/1.1", RFC 2616, June 1999. -- HTTP/1.1", RFC 2616, June 1999.
skipping to change at page 22, line 29 skipping to change at page 25, line 37
internet text messages," RFC 2822, April 2001. internet text messages," RFC 2822, April 2001.
[TLS] T. Dierks and E. Rescorla, "The Transport Layer [TLS] T. Dierks and E. Rescorla, "The Transport Layer
Security (TLS) Protocol Version 1.1," RFC 4346, Security (TLS) Protocol Version 1.1," RFC 4346,
April 2006. April 2006.
[URI] T. Berners-Lee, R. Fielding, and L. Masinter, [URI] T. Berners-Lee, R. Fielding, and L. Masinter,
"Uniform Resource Identifiers (URI): Generic "Uniform Resource Identifiers (URI): Generic
Syntax", RFC 3986, January 2005. Syntax", RFC 3986, January 2005.
7.2. Informative References [XHTML] M. Baker and P. Stark, "The
'application/xhtml+xml' Media Type," RFC 3236,
January 2002.
8.2. Informative References
[BGPDOS] D. Turk, "Configuring BGP to Block Denial-of- [BGPDOS] D. Turk, "Configuring BGP to Block Denial-of-
Service Attacks," RFC 3882, September 2004. Service Attacks," RFC 3882, September 2004.
[DER] ITU-T Recommendation X.680: Information Technology
- Abstract Syntax Notation One, 1997.
[IBCS] X. Boyen and L. Martin, "Identity-Based [IBCS] X. Boyen and L. Martin, "Identity-Based
Cryptography Standard (IBCS) #1: Supersingular Cryptography Standard (IBCS) #1: Supersingular
Curve Implementations of the BF and BB1 Curve Implementations of the BF and BB1
Cryptosystems," draft-martin-ibcs-06.txt, September Cryptosystems," draft-martin-ibcs-06.txt, September
2007. 2007.
[IBECMS] L. Martin and M. Schertler, "Using the Boneh- [IBECMS] L. Martin and M. Schertler, "Using the Boneh-
Franklin identity-based encryption algorithm with Franklin identity-based encryption algorithm with
the Cryptographic Message Syntax (CMS)," draft- the Cryptographic Message Syntax (CMS)," draft-
ietf-smime-bfibecms-06.txt, September 2007. ietf-smime-bfibecms-06.txt, September 2007.
[NIST] M. Souppaya, J. Wack and K. Kent, "Security [NIST] M. Souppaya, J. Wack and K. Kent, "Security
Configuration Checklist Program for IT Products - Configuration Checklist Program for IT Products -
Guidance for Checklist Users and Developers," NIST Guidance for Checklist Users and Developers," NIST
Special Publication SP 800-70, May 2005. Special Publication SP 800-70, May 2005.
[P1363] IEEE P1363, "Standards Specifications for Public- [P1363] IEEE P1363, "Standards Specifications for Public-
Key Cryptography," 2001. Key Cryptography," 2001.
[XER] ITU-T Recommendation X.693 - Information Technology
- ASN.1 Encoding Rules - XML Encoding Rules (XER),
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
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
USA
Phone: +1 650 543 1280 Phone: +1 650 543 1280
Email: martin@voltage.com Email: martin@voltage.com
Mark Schertler Mark Schertler
Tumbleweed Communications Tumbleweed Communications
700 Saginaw Dr 700 Saginaw Dr
Redwood City CA 94063 Redwood City CA 94063
USA
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 The IETF takes no position regarding the validity or
scope of any Intellectual Property Rights or other rights scope of any Intellectual Property Rights or other rights
that might be claimed to pertain to the implementation or that might be claimed to pertain to the implementation or
use of the technology described in this document or the use of the technology described in this document or the
 End of changes. 54 change blocks. 
136 lines changed or deleted 215 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/