draft-ietf-smime-bfibecms-10.txt   rfc5409.txt 
L. Martin Network Working Group L. Martin
S/MIME Working Group Voltage Security Request for Comments: 5409 Voltage Security
Internet Draft M. Schertler Category: Informational M. Schertler
Intended status: Standards Track Tumbleweed Communications Axway
Using the Boneh-Franklin and Boneh-Boyen Identity-based January 2009
Encryption Algorithms with the Cryptographic Message Syntax
(CMS)
<draft-ietf-smime-bfibecms-10.txt>
Status of this Document Using the Boneh-Franklin and Boneh-Boyen Identity-Based Encryption
Algorithms with the Cryptographic Message Syntax (CMS)
By submitting this Internet-Draft, each author represents Status of This Memo
that any 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 aware will be disclosed, in
accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet This memo provides information for the Internet community. It does
Engineering Task Force (IETF), its areas, and its working not specify an Internet standard of any kind. Distribution of this
groups. Note that other groups may also distribute working memo is unlimited.
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of Copyright Notice
six months and may be updated, replaced, or obsoleted by
other documents at any time. It is inappropriate to use
Internet-Drafts as reference material or to cite them other
than as "work in progress."
The list of current Internet-Drafts can be accessed at Copyright (c) 2009 IETF Trust and the persons identified as the
http://www.ietf.org/ietf/1id-abstracts.txt document authors. All rights reserved.
The list of Internet-Draft Shadow Directories can be This document is subject to BCP 78 and the IETF Trust's Legal
accessed at Provisions Relating to IETF Documents (http://trustee.ietf.org/
http://www.ietf.org/shadow.html license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract Abstract
This document describes the conventions for using the Boneh- This document describes the conventions for using the Boneh-Franklin
Franklin (BF) and Boneh-Boyen (BB1) identity-based (BF) and Boneh-Boyen (BB1) identity-based encryption algorithms in
encryption algorithms in the Cryptographic Message Syntax the Cryptographic Message Syntax (CMS) to encrypt content-encryption
(CMS) to encrypt content-encryption keys. Object identifiers keys. Object identifiers and the convention for encoding a
and the convention for encoding a recipient's identity are recipient's identity are also defined.
also defined.
Table of Contents Table of Contents
1. Introduction............................................2 1. Introduction ....................................................2
1.1. Terminology........................................3 1.1. Terminology ................................................3
1.2. IBE overview.......................................3 1.2. IBE Overview ...............................................3
2. Using identity-based encryption.........................4 2. Using Identity-Based Encryption .................................3
3. Key encryption algorithm identifiers....................7 3. Key Encryption Algorithm Identifiers ............................6
4. Processing by the sender................................8 4. Processing by the Sender ........................................7
5. Processing by the receiver..............................8 5. Processing by the Receiver ......................................7
6. ASN.1 module............................................9 6. ASN.1 Module ....................................................8
7. Security considerations................................11 7. Security Considerations .........................................9
7.1. Attacks that are outside the scope of this 7.1. Attacks outside the Scope of This Document .................9
document...............................................11 7.2. Attacks within the Scope of This Document .................10
7.2. Attacks that are within the scope of this 7.3. Attacks to Which the Protocols Defined in This Document
document...............................................12 Are Susceptible............................................11
7.3. Attacks to which the protocols defined in this 8. References .....................................................12
document are susceptible...............................12 8.1. Normative References ......................................12
8. IANA considerations....................................13 8.2. Informative References ....................................12
9. References.............................................14
9.1. Normative references..............................14
9.2. Informative references............................14
Authors' Addresses........................................15
Intellectual property statement...........................15
Disclaimer of validity....................................16
Copyright statement.......................................16
Acknowledgment............................................16
1. Introduction 1. Introduction
This document defines the way to use the Boneh-Franklin This document defines the way to use the Boneh-Franklin [IBCS] and
[IBCS] and Boneh-Boyen [IBCS] identity-based encryption Boneh-Boyen [IBCS] identity-based encryption (IBE) public-key
(IBE) public-key algorithms in the Cryptographic Message algorithms in the Cryptographic Message Syntax (CMS) [CMS]. IBE is a
Syntax (CMS) [CMS]. IBE is a public key technology for public-key technology for encrypting content-encryption keys (CEKs)
encrypting content-encryption keys (CEKs) that can be that can be implemented within the framework of the CMS: the
implemented within the framework of the CMS: the recipient's recipient's identity is incorporated into the EnvelopedData CMS
identity is incorporated into the EnvelopedData CMS content content type using the OtherRecipientInfo CHOICE in the RecipientInfo
type using the OtherRecipientInfo CHOICE in the field as defined in Section 6.2.5 of [CMS]. This document does not
RecipientInfo field as defined in section 6.2.5 of [CMS]. describe the implementation of the BF and BB1 algorithms, which are
This document does not describe the implementation of the BF described in detail in [IBCS].
and BB1 algorithms, which are described in detail in [IBCS].
IBE algorithms are a type of public-key cryptographic IBE algorithms are a type of public-key cryptographic algorithm in
algorithm in which the public key is calculated directly which the public key is calculated directly from a user's identity
from a user's identity instead of being generated randomly. instead of being generated randomly. This requires a different set
This requires a different set of steps for encryption and of steps for encryption and decryption than would be used with other
decryption than would be used with other public-key public-key algorithms, and these steps are defined in Sections 4 and
algorithms, and these steps are defined in Sections 4 and 5 5 of this document, respectively.
of this document respectively.
This document also defines the object identifiers and syntax This document also defines the object identifiers and syntax of the
of the object that is used to define the identity of a object that is used to define the identity of a message recipient.
message recipient.
CMS values and identity objects are defined using ASN.1 CMS values and identity objects are defined using ASN.1 [ASN1].
[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",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
and "OPTIONAL" in this document are to be interpreted as document are to be interpreted as described in RFC 2119 [KEYWORDS].
described in RFC 2119 [KEYWORDS].
1.2. IBE overview 1.2. IBE Overview
In addition to the client components that are described in In addition to the client components that are described in this
this document, the following additional components are document, the following additional components are required for a
required for a complete IBE messaging system. complete IBE messaging system.
o A Private-key Generator (PKG). The PKG contains the o A Private-Key Generator (PKG). The PKG contains the
cryptographic material, known as a master secret, cryptographic material, known as a master secret, for
for generating an individual's IBE private key. A generating an individual's IBE private key. A PKG accepts an
PKG accepts an IBE user's private key request and, IBE user's private key request and, after successfully
after successfully authenticating them in some way, authenticating them in some way, returns their IBE 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
Parameters include publicly sharable cryptographic publicly sharable cryptographic material, known as IBE public
material, known as IBE public parameters, and parameters, and policy information for the PKG. A PPS provides
policy information for the PKG. A PPS provides a a well-known location for distribution of IBE public parameters
well-known location for distribution of IBE public and policy information for the IBE PKG.
parameters and policy information for the IBE PKG.
The interaction of senders and receivers of IBE-encrypted The interactions of senders and receivers of IBE-encrypted messages
messages are described in [IBE]. All communications are described in [IBE]. All communications between users of an IBE
between users of an IBE system and the PPS or PKG MUST be system and the PPS or PKG MUST be protected using TLS [TLS] as
protected using TLS [TLS] as described in [IBE]. This described in [IBE]. This provides confidentiality and integrity of
provides confidentiality and integrity of all information all information that is delivered to users as well as authentication
that is delivered to users as well as authentication of of the PPS and PKG.
the PPS and PKG.
2. Using identity-based encryption 2. Using Identity-Based Encryption
To use IBE, the ori field in RecipientInfo MUST be used. The To use IBE, the ori field in RecipientInfo MUST be used. The fields
fields are set as follows: oriType is set to ibeORIType; are set as follows: oriType is set to ibeORIType; oriValue is set to
oriValue is set to ibeORIValue. ibeORIValue.
These fields have the following meanings: These fields have the following meanings:
ibeORIType defines the object identifier (OID) that ibeORIType defines the object identifier (OID) that indicates that
indicates that the subsequent ibeORIValue is the information the subsequent ibeORIValue is the information necessary to decrypt
necessary to decrypt the message using IBE. This field MUST the message using IBE. This field MUST be set to the following:
be set to the following:
ibeORIType OBJECT IDENTIFIER ::= { ibeORIType OBJECT IDENTIFIER ::= {
joint-iso-itu(2) country(16) us(840) joint-iso-itu(2) country(16) us(840)
organization(1) identicrypt(114334) organization(1) identicrypt(114334)
ibcs(1) cms(4) ori-oid(1) version(1) ibcs(1) cms(4) ori-oid(1) version(1)
} }
ibeORIValue defines the identity that was used in the IBE algorithm
ibeORIValue defines the identity that was used in the IBE to encrypt the CEK. This is an IBERecipientInfo type, which is
algorithm to encrypt the CEK. This is an IBERecipientInfo defined as follows:
type, which is defined as follows:
IBERecipientInfo ::= SEQUENCE { IBERecipientInfo ::= SEQUENCE {
cmsVersion INTEGER { v3(3) }, cmsVersion INTEGER { v3(3) },
keyFetchMethod OBJECT IDENTIFIER, keyFetchMethod OBJECT IDENTIFIER,
recipientIdentity IBEIdentityInfo, recipientIdentity IBEIdentityInfo,
serverInfo SEQUENCE SIZE (1..MAX) OF serverInfo SEQUENCE SIZE (1..MAX) OF
OIDValuePairs OPTIONAL, OIDValuePairs OPTIONAL,
encryptedKey EncryptedKey encryptedKey EncryptedKey
} }
The fields of IBERecipientInfo MUST be set as follows. The fields of IBERecipientInfo MUST be set as follows.
The cmsVersion MUST be set to 3. The cmsVersion MUST be set to 3.
The keyFetchMethod is the OID that defines the method of The keyFetchMethod is the OID that defines the method of retrieving
retrieving the private key that the recipient MUST use. This the private key that the recipient MUST use. This SHOULD be set to
SHOULD be set to uriPPSOID [IBE] which is defined to be the uriPPSOID [IBE], which is defined to be the following:
following:
uriPPSOID OBJECT IDENTIFIER ::= { uriPPSOID OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) joint-iso-itu-t(2) country(16) us(840)
organization(1) identicrypt(114334) organization(1) identicrypt(114334)
pps-schemas(3) ic-schemas(1) pps-uri(1) version(1) pps-schemas(3) ic-schemas(1) pps-uri(1) version(1)
} }
The recipientIdentity is the data that the sender used to The recipientIdentity is the data that the sender used to calculate
calculate the IBE public key that the sender used to encrypt the IBE public key that the sender used to encrypt the content-
the content-encryption key. This recipientIdentity is used encryption key. This recipientIdentity is used to calculate IBE
to calculate IBE public and private keys as described in public and private keys as described in [IBCS]. This MUST be a DER-
[IBCS]. This MUST be a DER-encoded [DER] IBEIdentityInfo encoded [DER] IBEIdentityInfo type [IBE], which is defined as
type [IBE], which is defined as follows: follows:
IBEIdentityInfo ::= SEQUENCE { IBEIdentityInfo ::= SEQUENCE {
district IA5String, district IA5String,
serial INTEGER, serial INTEGER,
identityType OBJECT IDENTIFIER, identityType OBJECT IDENTIFIER,
identityData OCTET STRING identityData OCTET STRING
} }
The identityType defines the format that is used to encode The identityType defines the format that is used to encode the
the information that defines the identity of the recipient. information that defines the identity of the recipient. This MUST be
This MUST be set to cmsIdentityOID to indicate that set to cmsIdentityOID to indicate that identityData contains an
identityData contains an EmailIdentityData type. The value EmailIdentityData type. The value of cmsIdentityOID is the
of cmsIdentityOID is the following: following:
cmsIdentityOID OBJECT IDENTIFIER ::= { cmsIdentityOID OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) joint-iso-itu-t(2) country(16) us(840)
organization(1) identicrypt(114334) organization(1) identicrypt(114334)
keyschemas(2) icschemas(1) email(1) version(1) keyschemas(2) icschemas(1) email(1) version(1)
} }
The identityData MUST be an EmailIdentityData type, which is The identityData MUST be an EmailIdentityData type, which is defined
defined as follows: as follows:
EmailIdentityData ::= SEQUENCE { EmailIdentityData ::= SEQUENCE {
rfc822Name IA5String, rfc822Name IA5String,
time GeneralizedTime time GeneralizedTime
} }
The rfc822Name field is the e-mail address of the recipient The rfc822Name field is the email address of the recipient in the
in the format defined in Section 4.2.1.6 of [PKIX] for the format defined in Section 4.2.1.6 of [PKIX] for the rfc822Name
rfc822Name subjectAltName variant. Rules for encoding subjectAltName variant. Rules for encoding Internet mail addresses
Internet mail addresses that include internationalized that include internationalized domain names are specified in Section
domain names are specified in Section 7.5 of [PKIX]. 7.5 of [PKIX].
The value of the time field is the UTC time after which the The value of the time field is the UTC time after which the sender
sender wants to let the recipient decrypt the message, so it wants to let the recipient decrypt the message, so it may be called
may be called the "not-before" time. This is usually set to the "not-before" time. This is usually set to the time when the
the time when the message is encrypted, but MAY be set to a message is encrypted, but MAY be set to a future time. The value of
future time. The value of "time" MUST be expressed in "time" MUST be expressed in Greenwich Mean Time (Zulu), MUST include
Greenwich Mean Time(Zulu), MUST include seconds (i.e. times seconds (i.e., times are always YYYYMMDDHHMMSSZ), even where the
are always YYYYMMDDHHMMSSZ), even where the number of number of seconds is equal to zero, and MUST be expressed to the
seconds is equal to zero and MUST be expressed to the
nearest second. nearest second.
The sender of an IBE-encrypted message may want to express The sender of an IBE-encrypted message may want to express this time
this time rounded to a time interval to create a key rounded to a time interval to create a key lifetime. A key lifetime
lifetime. A key lifetime reduces the number of IBE private reduces the number of IBE private keys that a recipient needs to
keys that a recipient needs to retrieve, but still forces retrieve, but still forces the IBE user to periodically re-
the IBE user to periodically re-authenticate. Based on the authenticate. Based on the time interval chosen a recipient would
time interval chosen a recipient would only have to retrieve only have to retrieve a new IBE key once during the interval. To do
a new IBE key once during the interval. To do this, follow this, follow the steps below. Let "time-interval" be the number of
the following steps. Let "time-interval" be the number of
seconds in this larger time interval. seconds in this larger time interval.
1. Find the GeneralizedTime for the not-before value. 1. Find the GeneralizedTime for the not-before value.
2. Convert this GeneralizedTime into the number of 2. Convert this GeneralizedTime into the number of seconds since
seconds since January 1, 1970. Call this January 1, 1970. Call this "total-time".
"total-time." 3. Calculate reduced-time =
3. Calculate reduced-time = (floor (total-time / (floor (total-time / time-interval)) * time-interval.
time-interval)) * time-interval. 4. Convert reduced-time to a GeneralizedTime to get the not-before
4. Convert reduced-time to a GeneralizedTime to get the "time" value.
not-before "time" value.
An example of this algorithm for computing a one week time An example of this algorithm for computing a one-week time interval
interval is as follows. is as follows.
1. Suppose that the GeneralizedTime is 20020401000000Z. 1. Suppose that the GeneralizedTime is 20020401000000Z.
2. Then the total-time is 1017612000. 2. Then the total-time is 1017612000.
3. A time-interval of 1 week is 604800 seconds. 3. A time-interval of 1 week is 604800 seconds.
So the reduced-time = (floor(1017612000/604800)) * So the reduced-time = (floor (1017612000 / 604800)) * 604800 =
604800 = 1017273600. 1017273600.
4. This gives the GeneralizedTime form of the 4. This gives the GeneralizedTime form of the reduced-time of
reduced-time of 20020328000000Z. 20020328000000Z.
When issuing IBE private keys, a PKG SHOULD NOT issue them When issuing IBE private keys, a PKG SHOULD NOT issue them too far
too far into the future. This restriction is to prevent an into the future. This restriction is to prevent an adversary who
adversary who obtains an IBE user's authentication obtains an IBE user's authentication credentials from requesting
credentials from requesting private keys far into the future private keys far into the future and therefore negating the periodic
and therefore negating the periodic IBE user re- IBE user re-authentication that key lifetime provides. For example,
authentication that key lifetime provides. For example if a if a one-week period is chosen for the key lifetime, then IBE private
one week period is chosen for the key lifetime, then IBE keys should not be issued more than one week in advance. Otherwise,
private keys should not be issued more than 1 week in once an adversary gains access to the PKG via the stolen IBE user
advance. Otherwise once an adversary gains access to the PKG credentials, they can request all future keys and negate the IBE user
via the stolen IBE user credentials they can request all authentication restraints in place.
future keys and negate the IBE user authentication
restraints in place.
The serverInfo is an optional sequence of OID-value pairs The serverInfo is an optional sequence of OID-value pairs that are
that are defined to be the following: defined to be the following:
OIDValuePairs ::= SEQUENCE { OIDValuePairs ::= SEQUENCE {
fieldID OBJECT IDENTIFIER, fieldID OBJECT IDENTIFIER,
fieldData OCTET STRING fieldData OCTET STRING
} }
These can be used to convey any other information that might These can be used to convey any other information that might be used
be used by a PKG. Examples of such information could include by a PKG. Examples of such information could include the user
the user interface that the recipient will experience. interface that the recipient will experience. Differences in the
Differences in the user interface could include localization user interface could include localization information or commercial
information or commercial branding information. A client branding information. A client MUST ignore any part of serverInfo
MUST ignore any part of serverInfo that it is unable to that it is unable to process.
process.
The encryptedKey is the result of encrypting the CEK with an The encryptedKey is the result of encrypting the CEK with an IBE
IBE algorithm using recipientIdentity as the IBE public key. algorithm using recipientIdentity as the IBE public key.
3. Key encryption algorithm identifiers 3. Key Encryption Algorithm Identifiers
The BF and BB1 algorithms as defined in [IBCS] have the The BF and BB1 algorithms as defined in [IBCS] have the following
following object identifiers. These object identifiers are object identifiers. These object identifiers are also defined in the
also defined in the ASN.1 module in [IBCS]. ASN.1 module in [IBCS].
bf OBJECT IDENTIFIER ::= { bf OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) joint-iso-itu-t(2) country(16) us(840)
organization(1) identicrypt(114334) organization(1) identicrypt(114334)
ibcs(1) ibcs1(1) ibe-algorithms(2) bf(1) ibcs(1) ibcs1(1) ibe-algorithms(2) bf(1)
} }
This is the object identifier that MUST be inserted in the This is the object identifier that MUST be inserted in the
keyEncryptionAlgorithm field in the CMS when the BF keyEncryptionAlgorithm field in the CMS when the BF algorithm is used
algorithm is used to encrypt the CEK. to encrypt the CEK.
bb1 OBJECT IDENTIFIER ::= { bb1 OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) joint-iso-itu-t(2) country(16) us(840)
organization(1) identicrypt(114334) organization(1) identicrypt(114334)
ibcs(1) ibcs1(1) ibe-algorithms(2) bb1(2) ibcs(1) ibcs1(1) ibe-algorithms(2) bb1(2)
} }
This is the object identifier that MUST be inserted in the This is the object identifier that MUST be inserted in the
keyEncryptionAlgorithm field in the CMS when the BB1 keyEncryptionAlgorithm field in the CMS when the BB1
algorithm is used to encrypt the CEK. algorithm is used to encrypt the CEK.
4. Processing by the sender 4. Processing by the Sender
The sender of a message that uses IBE to encrypt content- The sender of a message that uses IBE to encrypt content-
encryption keys performs the following steps: encryption keys performs the following steps:
1. Selects a set of IBE public parameters to use in the 1. Selects a set of IBE public parameters to use in the
subsequent steps in accordance with his local security subsequent steps in accordance with his local security
policy. He then determines the URI where the public policy. He then determines the URI where the public
parameters can be obtained using the process described in parameters can be obtained using the process described in
[IBE]. This information MUST be encoded in the [IBE]. This information MUST be encoded in the
IBEIdentityInfo as described in Section 2. IBEIdentityInfo as described in Section 2.
skipping to change at page 8, line 43 skipping to change at page 7, line 46
4. This IBE public key is then used to encrypt the 4. This IBE public key is then used to encrypt the
content-encryption key (CEK), using the algorithms that are content-encryption key (CEK), using the algorithms that are
defined in [IBCS]. defined in [IBCS].
5. Sets encryptedKey to the IBE-encrypted CEK. 5. Sets encryptedKey to the IBE-encrypted CEK.
6. Within the CMS, keyEncryptionAlgorithm MUST then be 6. Within the CMS, keyEncryptionAlgorithm MUST then be
set to the appropriate OID for the IBE algorithm that was set to the appropriate OID for the IBE algorithm that was
used (see Section 3). used (see Section 3).
5. Processing by the receiver 5. Processing by the Receiver
Upon receiving a message that has a CEK encrypted with IBE, Upon receiving a message that has a CEK encrypted with IBE,
the recipient performs the following steps to decrypt the the recipient performs the following steps to decrypt the
CEK: CEK:
1. Determines that the CEK is IBE-encrypted by noting that 1. Determines that the CEK is IBE-encrypted by noting that
the oriType of the OtherRecipientInfo type is set to the oriType of the OtherRecipientInfo type is set to
ibeORIType. ibeORIType.
2. Determines that the recipientIdentity was used as the 2. Determines that the recipientIdentity was used as the
skipping to change at page 9, line 22 skipping to change at page 8, line 26
4. Obtains the IBE public parameters from the location 4. Obtains the IBE public parameters from the location
determined in Step 3 using the process defined in determined in Step 3 using the process defined in
[IBE]. [IBE].
5. Obtains the IBE private key needed to decrypt the 5. Obtains the IBE private key needed to decrypt the
encrypted CEK using the process defined in [IBE]. encrypted CEK using the process defined in [IBE].
6. Decrypts the CEK using the IBE private key obtained in 6. Decrypts the CEK using the IBE private key obtained in
Step 4 using the algorithms described in [IBCS]. Step 4 using the algorithms described in [IBCS].
6. ASN.1 module 6. ASN.1 Module
The following ASN.1 module summarizes the ASN.1 definitions The following ASN.1 module summarizes the ASN.1 definitions
defined by this document. defined by this document.
IBECMS-module { IBECMS-module {
joint-iso-itu-t(2) country(16) us(840) joint-iso-itu-t(2) country(16) us(840)
organization(1) identicrypt(114334) organization(1) identicrypt(114334)
ibcs(1) cms(4) module(5) version(1) ibcs(1) cms(4) module(5) version(1)
} }
skipping to change at page 11, line 4 skipping to change at page 9, line 30
fieldID OBJECT IDENTIFIER, fieldID OBJECT IDENTIFIER,
fieldData OCTET STRING fieldData OCTET STRING
} }
EncryptedKey ::= OCTET STRING EncryptedKey ::= OCTET STRING
EmailIdentityData ::= SEQUENCE { EmailIdentityData ::= SEQUENCE {
rfc822Name IA5String, rfc822Name IA5String,
time GeneralizedTime time GeneralizedTime
} }
cmsIdentityOID OBJECT IDENTIFIER ::= { cmsIdentityOID OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) joint-iso-itu-t(2) country(16) us(840)
organization(1) identicrypt(114334) organization(1) identicrypt(114334)
keyschemas(2) icschemas(1) email(1) version(1) keyschemas(2) icschemas(1) email(1) version(1)
} }
END END
7. Security considerations 7. Security Considerations
This document is based on [CMS], [IBCS] and [IBE], and the This document is based on [CMS], [IBCS], and [IBE], and the relevant
relevant security considerations of those documents apply. security considerations of those documents apply.
7.1. Attacks that are outside the scope of this document 7.1. Attacks 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
implement IBE are outside the scope of this document. Such IBE are outside the scope of this document. Such attacks are
attacks are detailed in [IBCS], which defines parameters detailed in [IBCS], which defines parameters that give 80-bit,
that give 80-bit, 112-bit, 128-bit and 256-bit encryption 112-bit, 128-bit, and 256-bit encryption strength. We assume that
strength. We assume that capable administrators of an IBE capable administrators of an IBE system will select parameters that
system will select parameters that provide a sufficient provide a sufficient resistance to cryptanalytic attacks by
resistance to cryptanalytic attacks by adversaries. adversaries.
Attacks that give an adversary the ability to access or Attacks that give an adversary the ability to access or change the
change the information on a PPS or PKG, especially the information on a PPS or PKG, especially the cryptographic material
cryptographic material (referred to in this document as the (referred to in this document as the master secret), will defeat the
master secret), will defeat the security of an IBE system. security of an IBE system. In particular, if the cryptographic
In particular, if the cryptographic material is compromised material is compromised, the adversary will have the ability to
the adversary will have the ability to recreate any user's recreate any user's private key and therefore decrypt all messages
private key and therefore decrypt all messages protected protected with the corresponding public key. To address this
with the corresponding public key. To address this concern, concern, it is highly RECOMMENDED that best practices for physical
it is highly RECOMMENDED that best practices for physical and operational security for PPS and PKG servers be followed and that
and operational security for PPS and PKG servers be followed these servers be configured (sometimes known as hardened) in
and that these servers be configured (sometimes known as accordance with best current practices [NIST]. An IBE system SHOULD
hardened) in accordance with best current practices [NIST]. be operated in an environment where illicit access to the PKG or the
An IBE system SHOULD be operated in an environment where ability to modify the information distributed by the PPS is
illicit access to the PKG or the ability to modify the infeasible for attackers to obtain.
information distributed by the PPS is infeasible for
attackers to obtain.
Attacks that require administrative or IBE user equivalent Attacks that require administrative access or IBE-user-equivalent
access to machines used by either the client or the server access to machines used by either the client or the server components
components defined in this document are also outside the defined in this document are also outside the scope of this document.
scope of this document.
We also assume that all administrators of a system We also assume that all administrators of a system implementing the
implementing the protocols that are defined in this document protocols that are defined in this document are trustworthy and will
are trustworthy and will not abuse their authority to bypass not abuse their authority to bypass the security provided by an IBE
the security provided by an IBE system. This is of system. This is of particular importance with an IBE system, for an
particular importance with an IBE system, for an administrator of a PKG could potentially abuse his authority and
administrator of a PKG could potentially abuse his authority configure the PKG to grant him any IBE private key that the PKG is
and configure the PKG to grant him any IBE private key that capable of calculating. To minimize the possibility of
the PKG is capable of calculating. To minimize the administrators doing this, a system implementing IBE SHOULD implement
possibility of administrators doing this, a system n-out-of-m control for critical administrative functions and SHOULD
implementing IBE SHOULD implement n-out-of-m control for maintain auditable logs of all security-critical events that occur in
critical administrative functions and SHOULD maintain
auditable logs of all security-critical events that occur in
an operating IBE system. an operating IBE system.
Similarly, we assume that users of an IBE system will behave Similarly, we assume that users of an IBE system will behave
responsibly, not sharing their authentication credentials responsibly, not sharing their authentication credentials with
with others. Thus attacks that require such assumptions are others. Thus, attacks that require such assumptions are outside the
outside the scope of this document. scope of this document.
7.2. Attacks that are within the scope of this document
Attacks within the scope of this document are those that 7.2. Attacks within the Scope of This Document
allow an adversary to:
o passively monitor information transmitted between Attacks within the scope of this document are those that allow an
users of an IBE system and the PPS and PKG adversary to:
o passively monitor information transmitted between users of an
IBE system and the PPS and PKG
o masquerade as a PPS or PKG o masquerade as a PPS or PKG
o perform a DOS attack on a PPS or PKG o perform a denial-of-service (DoS) attack on a PPS or PKG
o easily guess an IBE user's authentication
credential
7.3. Attacks to which the protocols defined in this document
are susceptible
All communications between users of an IBE system and the o easily guess an IBE user's authentication credential
PPS or PKG are protected using TLS [TLS]. The IBE system
defined in this document provides no additional security 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 7.3. Attacks to Which the Protocols Defined in This Document
defend against an attacker masquerading as a legitimate IBE Are Susceptible
PPS or PKG. The protocols rely on the server authentication
mechanism of TLS [TLS]. In addition to the TLS server
authentication mechanism IBE client software can provide
protection against this possibility by providing user
interface capabilities that allows users to visually
determine that a connection to PPS and PKG servers is
legitimate. This 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 All communications between users of an IBE system and the PPS or PKG
to attacks against an IBE PPS or PKG. Denial of service are protected using TLS [TLS]. The IBE system defined in this
attacks against either component can result in users unable document provides no additional security for the communications
to encrypt or decrypt using IBE, and users of an IBE system between IBE users and the PPS or PKG. Therefore, the described IBE
SHOULD take the appropriate countermeasures [DOS, BGPDOS] system is completely dependent on the TLS security mechanisms for
that their use of IBE requires. 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 IBE user authentication method used by an IBE PKG SHOULD The protocols defined in this document do not explicitly defend
be of sufficient strength to prevent attackers from easily against an attacker masquerading as a legitimate IBE PPS or PKG. The
guessing the IBE user's authentication credentials through protocols rely on the server authentication mechanism of TLS [TLS].
trial and error. In addition to the TLS server authentication mechanism, IBE client
software can provide protection against this possibility by providing
user interface capabilities that allows users to visually determine
that a connection to PPS and PKG servers is legitimate. This
additional capability can help ensure that users cannot easily be
tricked into providing valid authorization credentials to an
attacker.
8. IANA considerations The protocols defined in this document are also vulnerable to attacks
against an IBE PPS or PKG. Denial-of-service attacks against either
component can result in users unable to encrypt or decrypt using IBE,
and users of an IBE system SHOULD take the appropriate
countermeasures [DOS, BGPDOS] that their use of IBE requires.
No further action by the IANA is necessary for this The IBE user authentication method used by an IBE PKG SHOULD be of
document. sufficient strength to prevent attackers from easily guessing the IBE
user's authentication credentials through trial and error.
9. References 8. References
9.1. Normative references 8.1. Normative References
[ASN1] ITU-T Recommendation X.680: Information Technology - [ASN1] ITU-T Recommendation X.680: Information Technology -
Abstract Syntax Notation One (ASN.1): "Abstract Syntax Notation One (ASN.1): Specification of
Specification of Basic Notation," July 2002. Basic Notation", July 2002.
[CMS] R. Housley, "Cryptographic Message Syntax," RFC 3852, [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC
July 2004. 3852, July 2004.
[DER] ITU-T Recommendation X.690: OSI Networking and System [DER] ITU-T Recommendation X.690: OSI Networking and System
Aspects: Abstract Syntax Notation One (ASN.1), Aspects: Abstract Syntax Notation One (ASN.1), July 2002.
July 2002.
[DOS] P. Ferguson and D. Senie, "Network Ingress Filtering: [DOS] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ Defeating Denial of Service Attacks which employ IP Source
IP Source Address Spoofing," RFC 2827, BCP 38, May Address Spoofing", BCP 38, RFC 2827, May 2000.
2000.
[IBCS] X. Boyen and L. Martin, "Identity-based Cryptography [IBCS] Boyen, X. and L. Martin, "Identity-Based Cryptography
Standard (IBCS) #1: Supersingular Curve Standard (IBCS) #1: Supersingular Curve Implementations of
Implementations of the BF and BB1 Cryptosystems," the BF and BB1 Cryptosystems", RFC 5091, December 2007.
RFC 5091, December 2007.
[IBE] G. Appenzeller, L. Martin and M. Schertler, "Identity- [IBE] Appenzeller, G., Martin, L., and M. Schertler, "Identity-
based Encryption Architecture," draft-ietf-smime- Based Encryption Architecture and Supporting Data
ibearch-06.txt. Structures", RFC 5408, January 2009.
[KEYWORDS] S. Brander, "Key Words for Use in RFCs to [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Indicate Requirement Levels," BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119, March 1997.
March 1997.
[PKIX] D. Cooper, et al., "Internet X.509 Public Key [PKIX] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Infrastructure Certificate and Certificate Housley, R., and W. Polk, "Internet X.509 Public Key
Revocation List (CRL) Profile," RFC 5280, May Infrastructure Certificate and Certificate Revocation List
2008. (CRL) Profile", RFC 5280, May 2008.
[TLS] T. Dierks and E. Rescorla, "The Transport Layer [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security
Security (TLS) Protocol Version 1.1," RFC 4346, (TLS) Protocol Version 1.2", RFC 5246, August 2008.
April 2006.
9.2. Informative references 8.2. Informative References
[BGPDOS] D. Turk, "Configuring BGP to Block Denial-of- [BGPDOS] Turk, D., "Configuring BGP to Block Denial-of-Service
Service Attacks," RFC 3882, September 2004. Attacks", RFC 3882, September 2004.
[NIST] M. Souppaya, J. Wack and K. Kent, "Security [NIST] M. Souppaya, J. Wack and K. Kent, "Security Configuration
Configuration Checklist Program for IT Products - Checklist Program for IT Products - Guidance for Checklist
Guidance for Checklist Users and Developers," NIST Users and Developers", NIST Special Publication SP 800-70,
Special Publication SP 800-70, May 2005. May 2005.
Authors' Addresses Authors' Addresses
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 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 Axway
700 Saginaw Dr 1600 Seaport Blvd, Suite 400
Redwood City CA 94063 Redwood City, CA 94063
USA USA
Phone: +1 650 216 2039 Phone: +1 650 216 2039
Email: mark.schertler@tumbleweed.com EMail: mschertler@us.axway.com
Intellectual property statement
The IETF takes no position regarding the validity or scope
of any Intellectual Property Rights or other rights that
might be claimed to pertain to the implementation or use of
the technology described in this document or the extent to
which any license under such rights might or might not be
available; nor does it represent that it has made any
independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents
can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and
any assurances of licenses to be made available, or the
result of an attempt made to obtain a general license or
permission for the use of such proprietary rights by
implementers or users of this specification can be obtained
from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its
attention any copyrights, patents or patent applications, or
other proprietary rights that may cover technology that may
be required to implement this standard. Please address the
information to the IETF at ietf-ipr@ietf.org.
Disclaimer of validity
This document and the information contained herein are
provided on an "AS IS" basis and THE CONTRIBUTOR, THE
ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY),
THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE
USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS
OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR
A PARTICULAR PURPOSE.
Copyright statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and
restrictions contained in BCP 78, and except as set forth
therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by
the Internet Society.
 End of changes. 81 change blocks. 
340 lines changed or deleted 283 lines changed or added

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