draft-ietf-smime-ibearch-02.txt   draft-ietf-smime-ibearch-03.txt 
G. Appenzeller G. Appenzeller
L. Martin L. Martin
S/MIME Working Group M. Schertler S/MIME Working Group M. Schertler
Internet Draft Voltage Security Internet Draft Voltage Security
Expires: June 2007 December 2006
Identity-based Encryption Architecture Identity-based Encryption Architecture
<draft-ietf-smime-ibearch-02.txt> <draft-ietf-smime-ibearch-03.txt>
Status of this Document Status of this Document
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or made obsolete by other documents at and may be updated, replaced, or obsoleted by other documents at any
any time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
Abstract Abstract
This document describes the security architecture required to implement This document describes the security architecture required to implement
identity-based encryption, a public-key encryption technology that uses identity-based encryption, a public-key encryption technology that uses
a user`s identity as a public key. 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 IBE Public Parameters.................4 2.2.1. Sender Obtains Recipient's IBE Public Parameters.....5
2.2.2. Sender IBE-encrypts Message..........................5 2.2.2. Construct and Send IBE-encrypts Message..............5
2.3. Receiving and Viewing an IBE-encrypted Message............5 2.3. Receiving and Viewing an IBE-encrypted Message............6
2.3.1. Recipient Obtains IBE Public Parameters from PPS.....5 2.3.1. Recipient Obtains IBE Public Parameters from PPS.....7
2.3.2. Recipient Obtains IBE Private Key from PKG...........6 2.3.2. Recipient Obtains IBE Private Key from PKG...........7
2.3.3. Recipient Decrypts IBE-encrypted Message.............6 2.3.3. Recipient Decrypts IBE-encrypted Message.............7
3. Public Parameter Lookup........................................7 3. Public Parameter Lookup........................................8
3.1. Request Method............................................8 3.1. Request Method............................................9
3.2. Parameter and Policy Format...............................8 3.2. Parameter and Policy Format...............................9
4. Private Key Request Protocol..................................10 4. Private Key Request Protocol..................................12
4.1. Overview.................................................10 4.1. Overview.................................................12
4.2. Private Key Request......................................11 4.2. Private Key Request......................................12
4.3. Request Structure........................................11 4.3. Request Structure........................................13
4.4. Authentication...........................................12 4.4. Authentication...........................................13
4.5. Server Response Format...................................13 4.5. Server Response Format...................................14
4.6. Response Containing a Private Key........................13 4.6. Response Containing a Private Key........................14
4.7. Responses Containing a Redirect..........................14 4.7. Responses Containing a Redirect..........................15
4.8. Responses Indicating an Error............................15 4.8. Responses Indicating an Error............................16
5. ASN.1 Module..................................................16 5. ASN.1 Module..................................................17
6. Security Considerations.......................................18 6. Security Considerations.......................................19
6.1. Attacks that are outside the scope of this document......18 6.1. Attacks that are outside the scope of this document......19
6.2. Attacks that are within the scope of this document.......19 6.2. Attacks that are within the scope of this document.......20
6.3. Attacks that the protocols defined in this document are 6.2.1. Attacks to which the protocols defined in this document
susceptible to................................................19 are susceptible............................................20
6.4. Attacks that the protocols defined in this document protect 7. IANA Considerations...........................................21
against.......................................................19 8. References....................................................22
7. IANA Considerations...........................................19 8.1. Normative References.....................................22
8. References....................................................21 Authors' Addresses...............................................24
8.1. Normative References.....................................21 Intellectual Property Statement..................................24
Authors` Addresses...............................................23 Disclaimer of Validity...........................................25
Intellectual Property Statement..................................23 Copyright Statement..............................................25
Disclaimer of Validity...........................................24 Acknowledgment...................................................25
Copyright Statement..............................................24
Acknowledgment...................................................24
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 NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [KEY]. document are to be interpreted as described in [KEY].
2. Identity-based Encryption 2. Identity-based Encryption
2.1. Overview 2.1. Overview
Identity-based encryption (IBE) is a public-key technology that Identity-based encryption (IBE) is a public-key encryption technology
allows keys to be calculated from an identity. This contrasts with that allows a public key to be calculated from an identity and the
other public-key systems [P1363], in which keys are generated corresponding private key to be calculated from the public key.
randomly. IBE systems have public parameters that define their Calculation of both the public and private keys in an IBE-based
operation, and a user of an IBE system needs to obtain these public system can occur as needed, resulting in just-in-time key material.
parameters before he can do any IBE operations. A user of an IBE This contrasts with other public-key systems [P1363], in which keys
system is capable of calculating the public key of a recipient after are generated randomly and distributed prior to secure communication
he obtains the public parameters for the IBE system and the recipient commencing. The ability to calculate a recipient's public key, in
of an IBE-encrypted message can decrypt an IBE-encrypted message if particular, eliminates the need for the sender and receiver in an
he has both the IBE public parameters and the necessary private key. IBE-based messaging system to interact with each other, either
directly or through a proxy such as a directory server, before
sending secure messages.
With an IBE public key, a user can encrypt messages to a recipient This document describes an IBE-based messaging system and how the
using the conventions of the Cryptographic Message Syntax [CMS]. components of the system work together. The components required for a
Within the framework of the CMS, a recipient also needs one complete IBE messaging system are the following:
additional element of information to decrypt a message: the URI of
where he can obtain the private key that he needs to decrypt the IBE-
encrypted message.
To decrypt an IBE-encrypted message, the recipient needs to obtain o A Private-key Generator (PKG). The PKG contains the
IBE public parameters as well as the private key that corresponds to cryptographic material, known as a master secret, for
the public key that the sender used. A recipient of an IBE-encrypted generating an individual's IBE private key. A PKG accepts an
message obtains the IBE public parameters the same way that the IBE user's private key request and after successfully
sender did. The IBE private key is obtained after authenticating to a authenticating them in some way returns the IBE private key.
private key generator (PKG), a trusted third party that calculates
private keys for users.
This document describes the overall architecture that can be used to o A Public Parameter Server (PPS). IBE System Parameters
implement IBE, and how the components of this architecture work include publicly sharable cryptographic material, known as
together to provide a functioning IBE system. The components required IBE public parameters, and policy information for the PKG. A
for a complete IBE system include the following: PPS provides a well-known location for secure distribution
of IBE public parameters and policy information for the IBE
PKG.
o A Public Parameter Server (PPS). A PPS provides IBE public A logical architecture would be to have a PKG/PPS per a name space,
parameters and policy information for an IBE Private-key such as a DNS zone. The organization that controls the DNS zone would
Generator. Its URI is uniquely identified by the form of an also control the PKG/PPS and thus the determination of which PKG/PSS
identity that it supports. to use when creating public and private keys for the organization's
members. In this case the PPS URI can be uniquely created by the form
of the identity that it supports. This architecture would make it
clear which set of public parameters to use and where to retrieve
them for a given identity (i.e. an RFC822 address).
o A Private-key Generator (PKG) where users can get IBE IBE encrypted messages can use standard message formats, such as the
private keys after authenticating their identity in some Cryptographic Message Syntax [CMS]. How to use IBE with CMS is
way. defined in [IBECMS].
Diagrams of these components and their interactions are shown in the Note that IBE algorithms are used only for encryption, so if digital
following sections. Note that IBE algorithms are used only for signatures are required they will need to be provided by an
encryption, so that any digital signatures that are required will additional mechanism.
need to be provided by an additional mechanism.
2.2. Sending a Message that is Encrypted Using IBE 2.2. Sending a Message that is Encrypted Using IBE
2.2.1. Sender Obtains IBE Public Parameters In order to send an encrypted message, an IBE user must perform the
following steps:
The first step is for the sender of a message to obtain the IBE 1. Obtain the recipient's public parameters
public parameters that he needs for calculating the IBE public key of
the recipient. He obtains this information from a PPS that is hosted
at a well-known URI. The IBE public parameters contain all of the
information that the sender needs to create an IBE-encrypted message
except for the identity of the recipient. Section 3 of this document
describes the URI where a PPS is located, the format of IBE public
parameters, and how to obtain them. The URI from which users obtain
IBE public parameters MUST be authenticated in some way; PPS servers
MUST support TLS 1.1 [TLS] and MAY support SSL 3.0 [SSL] to satisfy
this requirement. Section 3 also describes the way in which identity
formats are defined and a minimum interoperable format that all PPSs
and PKGs MUST support. This step is shown below in Figure 1.
The sender of an IBE-encrypted message selects the PPS and The recipient's IBE public parameters allow the creation of
corresponding PKG based on his local security policy. Different PPSs unique public and private keys for the recipient's domain. A
may provide public parameters that specify different IBE algorithms user of an IBE system is capable of calculating the public key
or different key strengths, for example, or require the use of PKGs of a recipient after he obtains the public parameters for their
that require different levels of authentication before granting IBE IBE system. Once the public parameters for a recipient's domain
private keys. are obtained, IBE-encrypted messages can be sent to all members
of that domain.
2. Construct and Send IBE-encrypted Message
All that is needed, in addition to the IBE public parameters,
is the recipient's identity in order to generate their public
key for use in encrypting messages to them. When this identity
is the same as the identity that a message would be addressed
to, then no more information is needed from a user to send
someone a secure message then is needed to send them an
unsecured message. This is one of the major benefits of an IBE-
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
The sender of a message obtains the IBE public parameters that he
needs for calculating the IBE public key of the recipient from a PPS
that is hosted at a well-known URI. The IBE public parameters contain
all of the information that the sender needs to create an IBE-
encrypted message except for the identity of the recipient. Section 3
of this document describes the URI where a PPS is located, the format
of IBE public parameters, and how to obtain them. The URI from which
users obtain IBE public parameters MUST be authenticated in some way;
PPS servers MUST support TLS 1.1 [TLS] to satisfy this requirement.
Section 3 also describes the way in which 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 Public Parameter Server
<----------------------------- <-----------------------------
IBE Public Parameters IBE Public Parameters
Figure 1 Requesting IBE Public Parameters Figure 1 Requesting IBE Public Parameters
2.2.2. Sender IBE-encrypts Message
The sender of an IBE-encrypted message selects the PPS and
corresponding PKG based on his local security policy. Different PPSs
may provide public parameters that specify different IBE algorithms
or different key strengths, for example, or require the use of PKGs
that require different levels of authentication before granting IBE
private keys.
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 encryption key
(CEK) and uses it to encrypt his message and then encrypts the CEK (CEK) and uses it to encrypt his message and then encrypts the CEK
with the recipient's IBE public key as described in [CMS]. This with the recipient's IBE public key as described in [CMS]. This
operation is shown below in Figure 2. [IBCS] describes the algorithms operation is shown below in Figure 2. [IBCS] describes the algorithms
needed to implement two forms of IBE and [IBECMS] describes how to needed to implement two forms of IBE and [IBECMS] describes how to
use the Cryptographic Message Syntax (CMS) to encapsulate the use the Cryptographic Message Syntax (CMS) to encapsulate the
encrypted message along with the IBE information that the recipient encrypted message along with the IBE information that the recipient
needs to decrypt the message. needs to decrypt the message.
skipping to change at page 5, line 28 skipping to change at page 6, line 18
| |
| |
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
The recipient of an IBE-encrypted message parses the message as In order to read an encrypted message, a recipient of an IBE-
described in [IBECMS]. This gives him the URI where he can obtain the encrypted message parses the message as described in [IBECMS]. This
IBE public parameters required to perform IBE calculations as well as gives him the URI he needs to obtain the IBE public parameters
the identity that was used to encrypt the message. The PPS also gives required to perform IBE calculations as well as the identity that was
the URI of the PKG where the recipient of an IBE-encrypted message used to encrypt the message. Next the recipient must carry out the
can obtain the IBE private keys. After successfully authenticating to following steps:
this PKG the recipient receives the IBE private key over an HTTPS
connection. 1. Obtain the recipient's public parameters
An IBE system's public parameters allow it to uniquely create
public and private keys. The recipient of an IBE-encrypted
message can decrypt an IBE-encrypted message if he has both the
IBE public parameters and the necessary IBE private key. The
PPS can also provide the 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
To decrypt an IBE-encrypted message, in addition to the IBE
public parameters the recipient needs to obtain the private key
that corresponds to the public key that the sender used. The
IBE private key is obtained after successfully authenticating
to a private key generator (PKG), a trusted third party that
calculates private keys for users. The recipient receives the
IBE private key over an HTTPS connection.
3. Decrypt IBE-encrypted message
The IBE private key decrypts the CEK (see section 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 receive
some IBE private keys. Giving a mail filtering appliance permission some IBE private keys. Giving a mail filtering appliance permission
to obtain IBE private keys on behalf of users, for example, can allow to obtain IBE private keys on behalf of users, for example, can allow
the appliance to decrypt and scan encrypted messages for viruses or the appliance to decrypt and scan encrypted messages for viruses or
other malicious features. other malicious features.
2.3.1. Recipient Obtains IBE Public Parameters from PPS 2.3.1. Recipient Obtains IBE Public Parameters from PPS
Before he can perform any IBE calculations related to the message Before he can perform any IBE calculations related to the message
skipping to change at page 6, line 16 skipping to change at page 7, line 26
-----------------------------> ----------------------------->
Recipient Public Parameter Server Recipient Public Parameter Server
<----------------------------- <-----------------------------
IBE Public Parameters IBE Public Parameters
Figure 3 Requesting IBE Public Parameters Figure 3 Requesting IBE Public Parameters
2.3.2. Recipient Obtains IBE Private Key from PKG 2.3.2. Recipient Obtains IBE Private Key from PKG
To obtain an IBE private key, the recipient of an IBE-encrypted To obtain an IBE private key, the recipient of an IBE-encrypted
message provides an identity that was used to calculate an IBE public message provides the IBE public key used to encrypt the message and
key to a PKG and requests the private key that corresponds to the IBE their authentication credentials to a PKG and requests the private
public key. After providing the identity for which a private key is key that corresponds to the IBE public key. Section 4 of this
being requested, a user MUST authenticate to the PKG. Section 4 of document defines the protocol for communicating with a PKG as well as
this document defines the protocol for communicating with a PKG as a minimum interoperable way to authenticate to a PKG that all IBE
well as a minimum interoperable way to authenticate to a PKG that all implementations MUST support. Because the security of IBE private
IBE implementations MUST support. Because the security of IBE private
keys is vital to the overall security of an IBE system, IBE private keys is vital to the overall security of an IBE system, IBE private
keys MUST be transported to recipients over a secure protocol. PKGs keys MUST be transported to recipients over a secure protocol. PKGs
MUST support TLS 1.1 [TLS] and MAY support SSL 3.0 [SSL] for MUST support TLS 1.1 [TLS] for transport of IBE private keys. This
transport of IBE private keys. This operation is shown below in operation is shown below in Figure 4.
Figure 4.
IBE Private Key Request IBE Private Key Request
----------------------------> ---------------------------->
Recipient PKG Recipient PKG
<---------------------------- <----------------------------
IBE Private Key IBE Private Key
Figure 4 Obtaining an IBE Private Key Figure 4 Obtaining an IBE Private Key
2.3.3. Recipient Decrypts IBE-encrypted Message 2.3.3. Recipient Decrypts IBE-encrypted Message
skipping to change at page 8, line 24 skipping to change at page 9, line 27
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.pem
To retrieve the IBE system parameters, the client SHOULD use the HTTP To retrieve the IBE system parameters, the client SHOULD use the HTTP
GET method as defined in [HTTP]. The request MUST happen over a GET method as defined in [HTTP]. The request MUST happen over a
secure protocol. The requesting client MUST support TLS 1.1 [TLS] and secure protocol. The requesting client MUST support TLS 1.1 [TLS].
MAY support SSL 3.0 [SSL]. When requesting the URI the client MUST When requesting the URI the client MUST only accept the system
only accept the system parameter block if the server identity was parameter block if the server identity was verified successfully by
verified successfully by TLS 1.1 or SSL 3.0. TLS 1.1.
A successful GET request returns in its body the Base64 encoding of A successful GET request returns in its body the Base64 encoding of
the DER-encoded [DER] ASN.1 structure that is described in the next the DER-encoded [DER] ASN.1 structure that is described in the next
section. section.
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 Validity,
ibePublicParameters IBEPublicParameters, ibePublicParameters IBEPublicParameters,
ibeIdentitySchema OBJECT IDENTIFIER, ibeIdentitySchema OBJECT IDENTIFIER,
ibeParamExtensions IBEParamExtensions ibeParamExtensions IBEParamExtensions
} }
The version specifies the version of the IBESysParams format. For the
The version specifies the version of the parameter format. For the
format described in this document it MUST be set to 2. The district format described in this document it MUST be set to 2. The district
name is a UTF8String that MUST be a valid domain name as defined by name is an UTF8String that MUST be a valid domain name as defined by
[DOM]. The districtSerial is a serial number that represents a unique [DOM]. The districtSerial is a serial number that represents a unique
set of IBE public parameters. If new parameters are published for a set of IBE public parameters. If new parameters are published for a
district, it MUST be increased to a number greater than the district, it MUST be increased to a number greater than the
previously-used serial number. previously-used serial number.
The validity for IBE public parameters are defined as follows: The validity period or lifetime of a specific instance of the
IBESysParams is defined as follows:
ValidityPeriod ::= SEQUENCE { ValidityPeriod ::= SEQUENCE {
notBefore GeneralizedTime, notBefore GeneralizedTime,
notAfter GeneralizedTime notAfter GeneralizedTime
} }
A client MUST verify that the IBE system parameters that it obtains A client MUST verify that the date on which it utilizes the IBE
are currently within the validity period and SHOULD not use these system parameters falls between the notBefore time and the notAfter
parameters if they are not. times of the IBE system parameters and SHOULD not use the parameters
if they do not.
IBE system parameters MUST be regenerated and republished whenever
the ibePublicParameters, ibeIdentitySchema, or ibeParamExtensions
change for a district. A client SHOULD refetch the IBE system
parameters at an application 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 time
component, as described in [IBECMS]. If such an identity is used, the component, as described in [IBECMS]. If such an identity is used, the
time component of the identity MUST fall between the notBefore time time component of the identity MUST fall between the notBefore time
and the notAfter times of the IBE system parameters. 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 correspond to
IBE algorithms that the PKG associated with this district IBE algorithms that the PKG associated with this district
understands. understands.
skipping to change at page 9, line 47 skipping to change at page 11, line 12
the actual cryptographic parameters. Its specific structure depends the actual cryptographic parameters. Its specific structure depends
on the algorithm. The OIDs for two IBE algorithms, the Boneh-Franklin on the algorithm. The OIDs for two IBE algorithms, the Boneh-Franklin
and Boneh-Boyen algorithms and their publicParameterData structures and Boneh-Boyen algorithms and their publicParameterData structures
are defined in [IBCS]. 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 algorithm
and MAY contain several algorithms. It MUST NOT contain two or more and MAY contain several algorithms. It MUST NOT contain two or more
IBEPublicParameter entries with the same algorithm. A client that IBEPublicParameter entries with the same algorithm. A client that
wants to use IBESysParams can chose any of the algorithms specified wants to use IBESysParams can chose any of the algorithms specified
in the publicParameterData structure. A client MUST implement at in the publicParameterData structure. A client MUST implement at
least the Boneh-Franklin algorithm and MAY implement the Boneh-Boyens least the Boneh-Franklin algorithm and MAY implement the Boneh-Boyen
and other algorithms. If a client does not support any of the and other algorithms. If a client does not support any of the
supported algorithms it MUST generate an error message and fail. 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 identities that
are used with this district. The OIDs and the required and optional are used with this district. The OIDs and the required and optional
fields for each OID are described in [IBECMS]. 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 define
additional parameters that particular implementations may require. additional parameters that particular implementations may require.
skipping to change at page 11, line 23 skipping to change at page 12, line 46
user authentication method for interoperability, and how to pass user authentication method for interoperability, and how to pass
authentication credentials to the server. It assumes that a client authentication credentials to the server. It assumes that a client
has already determined the URI of the PKG. This can be done from has already determined the URI of the PKG. This can be done from
hints included in the IBE message format [IBECMS] and the system hints included in the IBE message format [IBECMS] and the system
parameters of the IBE 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 as
defined in [HTTP]. The request MUST happen over a secure protocol. defined in [HTTP]. The request MUST happen over a secure protocol.
The requesting client MUST support TLS 1.1 [TLS] and MAY support SSL The requesting client MUST support TLS 1.1 [TLS]. When requesting the
3.0 [SSL]. When requesting the URI the client MUST verify the server URI the client MUST verify the server certificate [RFC2818], and MUST
certificate [RFC2818], and MUST abort the key request if the server abort the key request if the server certificate verification of the
certificate verification of the TLS or SSL connection fails. Doing so TLS connection fails. Doing so is critical to protect the
is critical to protect the authentication credentials and the private authentication credentials and the private key against man-in-the-
key against man-in-the-middle attacks when it is transmitted from the middle attacks when it is transmitted from the key server to the
key server to the client. 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:
<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>
skipping to change at page 18, line 35 skipping to change at page 19, line 35
} }
END END
6. Security Considerations 6. Security Considerations
6.1. Attacks that are outside the scope of this document 6.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 implement
IBE are outside the scope of this document. Such attacks are detailed IBE are outside the scope of this document. Such attacks are detailed
in [IBCS], which defines parameters that will give the equivalent of in [IBCS], which defines parameters that give 80-bit, 112-bit and
80-bit security, 112-bit security and 128-bit security. We assume 128-bit encryption strength. We assume that capable administrators of
that competent administrators of an IBE system will select parameters an IBE system will select parameters that provide a sufficient
that provide a sufficient resistance to cryptanalytic attacks by resistance to cryptanalytic attacks by adversaries.
adversaries.
Attacks that require access to machines used by either the client or Attacks that give an adversary the ability to access or change the
the server components defined in this document are also outside the information on a PPS or PKG, especially the cryptographic material
scope of this document. Attacks that give an attacker the ability to (referred to in this document as the master secret), will defeat the
access or change the information on a PPS or PKG, especially the security of an IBE system. In particular, if the cryptographic
cryptographic material, will defeat the security of an IBE system. To material is compromised the adversary will have the ability to
address this concern, the PPS and PKG servers SHOULD be configured in recreate any user's private key and therefore decrypt all messages
accordance with best current practices [NIST]. An IBE system should protected with the corresponding public key. To address this concern,
be operated in an environment where such illicit access is infeasible it is highly RECOMMENDED that best practices for physical and
for attackers to obtain. operational security for PPS and PKG servers be followed and that
these servers be configured (sometimes known as hardened) in
accordance with best current practices [NIST]. An IBE 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
machines used by either the client or the server 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 implementing the
protocols that are defined in this document are trustworthy and will protocols that are defined in this document are trustworthy and will
not abuse their authority to bypass the security provided by an IBE not abuse their authority to bypass the security provided by an IBE
system. Similarly, we assume that users of an IBE system will behave system. Similarly, we assume that users of an IBE system will behave
responsibly, not sharing their authentication credentials with responsibly, not sharing their authentication credentials with
others. Thus attacks that require such assumptions are outside the others. Thus attacks that require such assumptions are outside the
scope of this document. scope of this document.
6.2. Attacks that are within the scope of this document 6.2. Attacks that are within the scope of this document
Attacks that passively monitor information transmitted between users Attacks within the scope of this document are those that allow an
of an IBE system and the PPS and PKG are within the scope of this adversary to:
document, as are attacks that let an adversary masquerade as a PPS or
PKG are also within the scope of this document.
6.3. Attacks that the protocols defined in this document are o passively monitor information transmitted between users of
susceptible to an IBE system and the PPS and PKG
o masquerade as a PPS or PKG
o perform a DOS attack on a PPS or PKG
o easily guess an IBE users authentication credential
6.2.1. Attacks to which the protocols defined in this document are
susceptible
All communications between users of an IBE system and the PPS or PKG
are protected using TLS 1.1 [TLS]. The IBE system defined in this
document provides no additional security protections for the
communications between IBE users and the PPS or PKG. Therefore the
described IBE system is completely dependent on the TLS security
mechanisms for authentication of the PKG or PPS server and for
confidentiality and integrity of the communications. Should there be
a compromise of the TLS security mechanisms, the integrity of all
communications 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 defend
against an attacker masquerading as a legitimate IBE PPS or PKG. To against an attacker masquerading as a legitimate IBE PPS or PKG. The
provide protection against this possibility, client software that protocols rely on the server authentication mechanism of TLS [TLS].
implements the protocols defined in this document SHOULD have a user In addition to the TLS server authentication mechanism IBE client
interface that allows users to view the details of connections to PPS software can provide protection against this possibility by providing
and PKG servers so that users cannot easily be tricked into providing user interface capabilities that allows users to visually determine
valid authorization credentials to an attacker. that a connection to PPS and PKG servers is legitimate. This
additional capability can help ensure that users cannot easily be
tricked into providing valid authorization credentials to an
attacker.
The protocols defined in this document are also vulnerable to attacks The protocols defined in this document are also vulnerable to attacks
against an IBE PPS or PKG. Denial of service attacks against either against an IBE PPS or PKG. Denial of service attacks against either
component can result in users unable to encrypt or decrypt using IBE, component can result in users unable to encrypt or decrypt using IBE,
and users of an IBE system SHOULD take the appropriate and users of an IBE system SHOULD take the appropriate
countermeasures [RFC2827, RFC3882] that their use of IBE requires. countermeasures [RFC2827, RFC3882] that their use of IBE requires.
6.4. Attacks that the protocols defined in this document protect The IBE user authentication method selected by an IBE PKG SHOULD be
against of sufficient strength to prevent attackers from easily guessing the
IBE user's authentication credentials through trial and error.
All communications between users of an IBE system and the PPS or PKG
are encrypted using TLS 1.1 [TLS] or SSL 3.0 [SSL], which should
provide an adequate level of protection for such communications.
The authentication method used by an IBE PKG should also be
sufficiently strong to prevent attackers from easily guessing them
through trial and error.
7. IANA Considerations 7. 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 IANA per
the instructions in RFC 3688, The IETF XML Registry. the instructions in RFC 3688, The IETF XML Registry.
URI: URI:
urn:ietf:params:xml:ns:ibe urn:ietf:params:xml:ns:ibe
skipping to change at page 22, line 39 skipping to change at page 23, line 39
[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, D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source Defeating Denial of Service Attacks which employ IP Source
Address Spoofing," RFC 2827, BCP 38, May 2000. Address Spoofing," RFC 2827, BCP 38, May 2000.
[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.
[SSL3] A. Frier, P. Karlton, P. Kocher, "The SSL 3.0 Protocol,"
Netscape Communications Corp., Nov 18, 1996.
[TLS] T. Dierks, E. Rescorla, "The Transport Layer Security (TLS) [TLS] T. Dierks, E. Rescorla, "The Transport Layer Security (TLS)
Protocol Version 1.1," RFC 4346, April 2006. Protocol Version 1.1," RFC 4346, April 2006.
[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, August Resource Identifiers (URI): Generic Syntax", RFC 2396, August
1998. 1998.
Authors' Addresses Authors' Addresses
Guido Appenzeller Guido Appenzeller
skipping to change at page 24, line 12 skipping to change at page 25, line 12
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
Disclaimer of Validity Disclaimer of Validity
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) the Internet Society (2006). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 35 change blocks. 
180 lines changed or deleted 248 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/