draft-ietf-smime-bfibecms-02.txt   draft-ietf-smime-bfibecms-03.txt 
L. Martin L. Martin
S/MIME Working Group M. Schertler S/MIME Working Group M. Schertler
Internet Draft Voltage Security Internet Draft Voltage Security
Using the Boneh-Franklin and Boneh-Boyen identity-based encryption Using the Boneh-Franklin and Boneh-Boyen identity-based encryption
algorithms with the Cryptographic Message Syntax (CMS) algorithms with the Cryptographic Message Syntax (CMS)
<draft-ietf-smime-bfibecms-02.txt> <draft-ietf-smime-bfibecms-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
skipping to change at page 2, line 9 skipping to change at page 2, line 9
This document describes the conventions for using the Boneh-Franklin This document describes the conventions for using the Boneh-Franklin
(BF) and Boneh-Boyen (BB1) identity-based encryption algorithms in (BF) and Boneh-Boyen (BB1) identity-based encryption algorithms in
the Cryptographic Message Syntax (CMS) to encrypt content encryption the Cryptographic Message Syntax (CMS) to encrypt content encryption
keys. Object identifiers and the convention for encoding a keys. Object identifiers and the convention for encoding a
recipient's identity are also defined. recipient's identity are 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
2. Using identity-based encryption................................3 2. Using identity-based encryption................................3
4. Convert reduced-time to a GeneralizedTime to get the not-before 3. Key encryption algorithm identifiers...........................6
"time" value......................................................5 4. Processing by the sender.......................................7
3. Algorithm object identifiers...................................6
4. Processing by the sender.......................................6
5. Processing by the receiver.....................................7 5. Processing by the receiver.....................................7
6. ASN.1 Module...................................................8 6. ASN.1 module...................................................9
7. Security Considerations........................................9 7. Security considerations.......................................10
7.1. Attacks that are outside the scope of this document.......9 7.1. Attacks that are outside the scope of this document......10
7.2. Attacks that are within the scope of this document.......10 7.2. Attacks that are within the scope of this document.......11
7.3. Attacks to which the protocols defined in this document are 7.3. Attacks to which the protocols defined in this document are
susceptible...................................................10 susceptible...................................................11
8. IANA Considerations...........................................11 8. IANA considerations...........................................12
9. References....................................................12 9. References....................................................13
9.1. Normative References.....................................12 9.1. Normative references.....................................13
Authors' Addresses...............................................13 9.2. Informative references...................................13
Intellectual Property Statement..................................13 Authors' Addresses...............................................14
Disclaimer of Validity...........................................13 Intellectual property statement..................................14
Copyright Statement..............................................14 Disclaimer of validity...........................................14
Acknowledgment...................................................14 Copyright statement..............................................15
Acknowledgment...................................................15
1. Introduction 1. Introduction
This document defines the steps needed to use the Boneh-Franklin [BF] This document defines the way to use the Boneh-Franklin [BF] and
and Boneh-Boyen [BB1] identity-based encryption (IBE) public-key Boneh-Boyen [BB1] identity-based encryption (IBE) public-key
algorithms in the Cryptographic Message Syntax (CMS) [CMS]. IBE is a algorithms in the Cryptographic Message Syntax (CMS) [CMS]. IBE is a
public key technology for encrypting content-encryption keys (CEKs) public key technology for encrypting content-encryption keys (CEKs)
that can be implemented within the framework of the CMS: the that can be implemented within the framework of the CMS: the
recipient's identity is incorporated into the EnvelopedData CMS recipient's identity is incorporated into the EnvelopedData CMS
content type using the OtherRecipientInfo CHOICE in the RecipientInfo content type using the OtherRecipientInfo CHOICE in the RecipientInfo
field as defined in section 6.2.5 of [CMS]. This document does not field as defined in section 6.2.5 of [CMS]. This document does not
describe the implementation of the BF and BB1 algorithms, which are describe the implementation of the BF and BB1 algorithms, which are
described in detail in [IBCS]. described in detail in [IBCS].
IBE algorithms are a type of public-key cryptographic algorithm in IBE algorithms are a type of public-key cryptographic algorithm in
which the public key is calculated directly from a user's identity which the public key is calculated directly from a user's identity
instead of being generated randomly. This requires a different set of instead of being generated randomly. This requires a different set of
steps for encryption and decryption than would be used with other steps for encryption and decryption than would be used with other
public-key algorithms, and these steps are defined in Sections 4 and public-key algorithms, and these steps are defined in Sections 4 and
5 of this document respectively. 5 of this document respectively.
This document also defines the object identifiers and syntax of the This document also defines the object identifiers and syntax of the
object that is used to define the identity of a message recipient. object that is used to define the identity of a message recipient.
CMS values and identity objects are defined using ANS.1 [ASN1]. CMS values and identity objects are defined using ASN.1 [ASN1].
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 RFC-2119 [KEYWORDS]. document are to be interpreted as described in RFC-2119 [KEYWORDS].
2. Using identity-based encryption 1.2. IBE overview
To use IBE, the OtherRecipientInfo field MUST be set to an In addition to the client components that are described in this
IBEOtherRecipient type. document, the following additional components are required for a
complete IBE messaging system:
IBEOtherRecipientInfo ::= SEQUENCE { o A Private-key Generator (PKG). The PKG contains the
ibeORIType OBJECT IDENTIFIER, cryptographic material, known as a master secret, for
ibeORIValue IBERecipientInfo generating an individual's IBE private key. A PKG accepts an
} IBE user's private key request and, after successfully
authenticating them in some way, returns their IBE private
key.
The fields of IBEOtherRecipientInfo have the following meanings: o A Public Parameter Server (PPS). IBE System Parameters
include publicly sharable cryptographic material, known as
IBE public parameters, and policy information for the PKG. A
PPS provides a well-known location for secure distribution
of IBE public parameters and policy information for the IBE
PKG.
The interaction of senders and receivers of IBE-encrypted messages
are described in [IBE].
2. Using identity-based encryption
To use IBE, the ori field in RecipientInfo MUST be used. The fields
are set as follows: oriType is set to ibeORIType; oriValue is set to
ibeORIValue.
These fields have the following meanings:
ibeORIType defines the object identifier (OID) that indicates that ibeORIType defines the object identifier (OID) that indicates that
the subsequent ibeORIValue is the information necessary to decrypt the subsequent ibeORIValue is the information necessary to decrypt
the message using IBE. This field MUST be set to the message using IBE. This field MUST be set to
ibeORIType OBJECT IDENTIFIER ::= { joint-iso-itu(2) country(16) ibeORIType OBJECT IDENTIFIER ::= { joint-iso-itu(2) country(16)
us(840) organization(1) identicrypt(114334) ibcs(1) us(840) organization(1) identicrypt(114334) ibcs(1)
cms(4) ori-oid(1) } cms(4) ori-oid(1) }
ibeORIValue defines the identity that was used in the IBE algorithm ibeORIValue defines the identity that was used in the IBE algorithm
to encrypt the CEK. This is an IBERecipientInfo type. to encrypt the CEK. This is an IBERecipientInfo type.
IBERecipientInfo ::= SEQUENCE { IBERecipientInfo ::= SEQUENCE {
cmsVersion INTEGER { v3(3) }, cmsVersion INTEGER { v3(3) },
keyFetchMethod OBJECT IDENTIFIER, keyFetchMethod OBJECT IDENTIFIER,
skipping to change at page 3, line 43 skipping to change at page 4, line 15
us(840) organization(1) identicrypt(114334) ibcs(1) us(840) organization(1) identicrypt(114334) ibcs(1)
cms(4) ori-oid(1) } cms(4) ori-oid(1) }
ibeORIValue defines the identity that was used in the IBE algorithm ibeORIValue defines the identity that was used in the IBE algorithm
to encrypt the CEK. This is an IBERecipientInfo type. to encrypt the CEK. This is an IBERecipientInfo type.
IBERecipientInfo ::= SEQUENCE { IBERecipientInfo ::= SEQUENCE {
cmsVersion INTEGER { v3(3) }, cmsVersion INTEGER { v3(3) },
keyFetchMethod OBJECT IDENTIFIER, keyFetchMethod OBJECT IDENTIFIER,
recipientIdentity IBEIdentityInfo, recipientIdentity IBEIdentityInfo,
serverInfo SEQUENCE OF OIDValuePairs OPTIONAL, serverInfo SEQUENCE (1..MAX) OF OIDValuePairs OPTIONAL,
encryptedKey EncryptedKey encryptedKey EncryptedKey
} }
The fields of IBERecipientInfo have the following meanings: The fields of IBERecipientInfo have the following meanings:
The cmsVersion MUST be set to 3. The cmsVersion MUST be set to 3.
The keyFetchMethod is the OID that defines the method of retrieving The keyFetchMethod is the OID that defines the method of retrieving
the private key that the recipient MUST use. How to retrieve an IBE the private key that the recipient MUST use. How to retrieve an IBE
private key using the steps defined in [IBE] is defined by the private key using the steps defined in [IBE] is defined by the
keyFetchMethod OID. The method for retrieving private keys that is keyFetchMethod OID. The method for retrieving private keys that is
specified in [IBE] is defined by cmsPPSOID. specified in [IBE] is defined by cmsPPSOID.
cmsPPSOID OBJECT IDENTIFIER ::= { joint-iso-itu(2) country(16) cmsPPSOID OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16)
us(840) organization(1) identicrypt(114334) pps-schemas(3) us(840) organization(1) identicrypt(114334) pps-schemas(3)
ic-schemas(1) pps-uri(1) ic-schemas(1) pps-uri(1)
} }
The recipientIdentity is the data that was used to calculate the The recipientIdentity is the data that was used to calculate the IBE
public key that was used to encrypt the CEK. This MUST be an public key that was used to encrypt the content-encryption key. This
IBEIdentityInfo type. This recipientIdentity is used to calculate IBE MUST be an IBEIdentityInfo type. This recipientIdentity is used to
public and private keys as described in [IBCS]. calculate IBE public and private keys as described in [IBCS].
IBEIdentityInfo ::= SEQUENCE { IBEIdentityInfo ::= SEQUENCE {
District UTF8STRING, district UTF8STRING,
Serial INTEGER, serial INTEGER,
identitySchema OBJECT IDENTIFIER, identitySchema OBJECT IDENTIFIER,
identityData OCTET STRING identityData OCTET STRING
} }
The fields of IBEIdentityInfo have the following meanings. The fields of IBEIdentityInfo have the following meanings.
The district and serial are unique identifiers that are used to The district and serial are unique identifiers that are used to
construct the URI for the location of where the IBE public parameters construct the URI for the location of the necessary IBE public
are located. The construction and use of this URI is defined in parameters. The construction and use of this URI is defined in [IBE].
[IBE].
The identitySchema defines the format that is used to encode the The identitySchema defines the format that is used to encode the
information that defines the identity of the recipient. This MUST be information that defines the identity of the recipient. This MUST be
set to cmsIdentityOID. set to cmsIdentityOID to indicate that identityData contains an
EmailIdentitySchema type.
cmsIdentityOID OBJECT IDENTIFIER ::= { joint-iso-itu(2) country(16) cmsIdentityOID OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16)
us(840) organization(1) identicrypt(114334) keyschemas(2) us(840) organization(1) identicrypt(114334) keyschemas(2)
icschemas(1) rfc822email(1) icschemas(1) rfc822email(1)
} }
The identityData is the identity of the recipient. For use in S/MIME, The identityData field contains the identify information for the
this MUST be an EmailIdentitySchema type which is DER encoded. Other recipient. If the contents of the field is an ASN.1 structure, the
applications MAY use other formats for the identityData. structure MUST be DER encoded before placing it in the OCTET STRING.
EmailIdentitySchema ::= SEQUENCE { EmailIdentitySchema ::= SEQUENCE {
rfc822Email UTF8STRING, rfc822Email UTF8STRING,
time GeneralizedTime time GeneralizedTime
} }
The rfc822Email is the DER-encoded e-mail address of the recipient in The rfc822Email is the e-mail address of the recipient in the format
the format defined by [RFC822]. defined by [RFC822]. E-mail addresses that contain non-ASCII
characters MUST be encoded using punycode [RFC3492].
The value of "time" is the DER-encoded UTC time after which the The value of "time" is the UTC time after which the sender wants to
sender wants to let the recipient decrypt the message, so it may be let the recipient decrypt the message, so it may be called the "not-
called the "not-before" time. This is usually set to the time when before" time. This is usually set to the time when the message is
the message is encrypted, but MAY be set to a future time. UTC time encrypted, but MAY be set to a future time. UTC time values are
values are expressed to the nearest second. expressed to the nearest second.
The sender of an IBE-encrypted message may want to express this time The sender of an IBE-encrypted message may want to express this time
rounded to a time interval to create a key lifetime. A key lifetime rounded to a time interval to create a key lifetime. A key lifetime
reduces the number of IBE private keys that a recipient needs to reduces the number of IBE private keys that a recipient needs to
retrieve, but still forces the IBE user to periodically re- retrieve, but still forces the IBE user to periodically re-
authenticate. Based on the time interval chosen a recipient would authenticate. Based on the time interval chosen a recipient would
only have to retrieve a new IBE key once during the interval. To do only have to retrieve a new IBE key once during the interval. To do
this, follow the following steps. Let "time-interval" be the number this, follow the following steps. Let "time-interval" be the number
of seconds in this larger time interval. of 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 seconds
2. Convert this GeneralizedTime into the number of seconds since since January 1, 1970. Call this "total-time."
January 1, 1970. Call this "total-time."
3. Calculate reduced-time = (floor (total-time / 3. Calculate reduced-time = (floor (total-time /
time-interval)) * time-interval. time-interval)) * time-interval.
4. Convert reduced-time to a GeneralizedTime to get the
4. Convert reduced-time to a GeneralizedTime to get the not-before not-before "time" value.
"time" value.
An example of this algorithm for computing a one week time interval An example of this algorithm for computing a one week time interval
is: is as follows.
1. Say the GeneralizedTime is 20020401000000Z
2. The total-time is 1017612000
3. A time-interval of 1 week is 604800 seconds. So the reduced- 1. Say the GeneralizedTime is 20020401000000Z.
time = (floor(1017612000/604800))* 604800 = 1017273600 2. Then the total-time is 1017612000.
4. Giving the reduced-time GeneralizedTime for a 1 week time 3. A time-interval of 1 week is 604800 seconds.
interval of 20020328000000Z So the reduced-time = (floor(1017612000/604800))*
604800 = 1017273600.
4. This gives the reduced-time GeneralizedTime form of the
reduced-time of 20020328000000Z.
When issuing IBE private keys, a PKG SHOULD NOT issue them too far When issuing IBE private keys, a PKG SHOULD NOT issue them too far
into the future. This restriction is to prevent an adversary who into the future. This restriction is to prevent an adversary who
obtains an IBE user's authentication credentials from requesting obtains an IBE user's authentication credentials from requesting
private keys far into the future and therefore negating the periodic private keys far into the future and therefore negating the periodic
IBE user re-authentication that key lifetime provides. For example if IBE user re-authentication that key lifetime provides. For example if
a one week period is chosen for the key lifetime, then IBE private a one week period is chosen for the key lifetime, then IBE private
keys should not be issued more than 1 week in advance. Otherwise once keys should not be issued more than 1 week in advance. Otherwise once
an adversary gains access to the PKG via the stolen IBE user an adversary gains access to the PKG via the stolen IBE user
credentials they can request all future keys and negate the IBE user credentials they can request all future keys and negate the IBE user
authentication restraints in place. authentication restraints in place.
3. Algorithm object identifiers The serverInfo is an optional series of OID-value pairs that can be
used to convey any other information that might be used by a PKG.
Examples of such information could include the user interface that
the recipient will experience. Differences in the user interface
could include localization information or commercial branding
information.
The encryptedKey is the result of encrypting the CEK with an IBE
algorithm using recipientIdentity as the IBE public key.
3. Key encryption algorithm identifiers
The BF and BB1 algorithms as defined in [IBCS] have the following The BF and BB1 algorithms as defined in [IBCS] have the following
object identifiers: object identifiers. These object identifiers are also defined in the
ASN.1 module in [IBCS].
bf OBJECT IDENTIFIER ::= { joint-iso-itu(2) country(16) us(840) bf OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840)
organization(1) identicrypt(114334) ibcs(1) ibcs1(1) organization(1) identicrypt(114334) ibcs(1) ibcs1(1)
ibe-algorithms(2) bf(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 algorithm is used keyEncryptionAlgorithm field in the CMS when the BF algorithm is used
to encrypt the CEK. to encrypt the CEK.
bb1 OBJECT IDENTIFIER ::= { joint-iso-itu(2) country(16) us(840) bb1 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840)
organization(1) identicrypt(114334) ibcs(1) ibcs1(1) organization(1) identicrypt(114334) ibcs(1) ibcs1(1)
ibe-algorithms(2) bb1(2) } 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 algorithm is keyEncryptionAlgorithm field in the CMS when the BB1 algorithm is
used to encrypt the CEK. 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 encryption The sender of a message that uses IBE to encrypt content encryption
skipping to change at page 8, line 5 skipping to change at page 9, line 5
4. Obtains the IBE public parameters from the location determined 4. Obtains the IBE public parameters from the location determined
in Step 3 using the process defined in [IBE]. in Step 3 using the process defined in [IBE].
5. Obtains the IBE private key needed to decrypt the encrypted CEK 5. Obtains the IBE private key needed to decrypt the encrypted CEK
using the process defined in [IBE]. using the process defined in [IBE].
6. Decrypts the CEK using the IBE private key obtained in Step 4 6. Decrypts the CEK using the IBE private key obtained in Step 4
using the algorithms described in [IBCS]. using the algorithms described in [IBCS].
6. ASN.1 Module 6. ASN.1 module
IBECMS-module { joint-iso-itu(2) country(16) us(840) organization(1) IBECMS-module { joint-iso-itu-t(2) country(16) us(840)
organization(1)
identicrypt(114334) ibcs(1) cms(4) module(5) version(1) identicrypt(114334) ibcs(1) cms(4) module(5) version(1)
} }
DEFINITIONS IMPLICIT TAGS ::= BEGIN DEFINITIONS IMPLICIT TAGS ::= BEGIN
IBEOtherRecipientInfo ::= SEQUENCE { IBEOtherRecipientInfo ::= SEQUENCE {
oriType OBJECT IDENTIFIER, oriType OBJECT IDENTIFIER,
oriValue IBERecipientInfo oriValue IBERecipientInfo
} }
ibeORIType OBJECT IDENTIFIER ::= { joint-iso-itu(2) country(16) ibeORIType OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16)
us(840) organization(1) identicrypt(114334) ibcs(1) us(840) organization(1) identicrypt(114334) ibcs(1)
cms(4) ori-oid(1) cms(4) ori-oid(1)
} }
IBERecipientInfo ::= SEQUENCE { IBERecipientInfo ::= SEQUENCE {
cmsVersion INTEGER { v3(3) }, cmsVersion INTEGER { v3(3) },
keyFetchMethod OBJECT IDENTIFIER, keyFetchMethod OBJECT IDENTIFIER,
recipientIdentity IBEIdentityInfo, recipientIdentity IBEIdentityInfo,
serverInfo SEQUENCE OF OIDValuePairs OPTIONAL, serverInfo SEQUENCE (1..MAX) OF OIDValuePairs OPTIONAL,
encryptedKey EncryptedKey encryptedKey EncryptedKey
} }
IBEIdentityInfo ::= SEQUENCE { IBEIdentityInfo ::= SEQUENCE {
District UTF8STRING, district UTF8STRING,
serial INTEGER, serial INTEGER,
identitySchema OBJECT IDENTIFIER, identitySchema OBJECT IDENTIFIER,
identityData OCTET STRING identityData OCTET STRING
} }
OIDValuePairs ::= SEQUENCE { OIDValuePairs ::= SEQUENCE {
fieldID OBJECT IDENTIFIER, fieldID OBJECT IDENTIFIER,
fieldData OCTET STRING fieldData OCTET STRING
} }
EmailIdentitySchema ::= SEQUENCE { EmailIdentitySchema ::= SEQUENCE {
rfc822Email UTF8STRING, rfc822Email UTF8STRING,
time GeneralizedTime time GeneralizedTime
} }
cmsIdentityOID OBJECT IDENTIFIER ::= { joint-iso-itu(2) country(16) cmsIdentityOID OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16)
us(840) organization(1) identicrypt(114334) keyschemas(2) us(840) organization(1) identicrypt(114334) keyschemas(2)
icschemas(1) rfc822email(1) icschemas(1) rfc822email(1)
} }
cmsPPSOID OBJECT IDENTIFIER ::= { joint-iso-itu(2) country(16)
cmsPPSOID OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16)
us(840) organization(1) identicrypt(114334) pps-schemas(3) us(840) organization(1) identicrypt(114334) pps-schemas(3)
ic-schemas(1) pps-uri(1) ic-schemas(1) pps-uri(1)
} }
END END
7. Security Considerations 7. Security considerations
This document is based on [CMS] and [IBCS], and the relevant security This document is based on [CMS] and [IBCS], and the relevant security
considerations of those documents apply. considerations of those documents apply.
7.1. Attacks that are outside the scope of this document 7.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 give 80-bit, 112-bit and in [IBCS], which defines parameters that give 80-bit, 112-bit, 128-
128-bit encryption strength. We assume that capable administrators of bit and 256-bit encryption strength. We assume that capable
an IBE system will select parameters that provide a sufficient administrators of an IBE system will select parameters that provide a
resistance to cryptanalytic attacks by adversaries. sufficient resistance to cryptanalytic attacks by adversaries.
Attacks that give an adversary the ability to access or change the Attacks that give an adversary the ability to access or change the
information on a PPS or PKG, especially the cryptographic material information on a PPS or PKG, especially the cryptographic material
(referred to in this document as the master secret), will defeat the (referred to in this document as the master secret), will defeat the
security of an IBE system. In particular, if the cryptographic security of an IBE system. In particular, if the cryptographic
material is compromised the adversary will have the ability to material is compromised the adversary will have the ability to
recreate any user's private key and therefore decrypt all messages recreate any user's private key and therefore decrypt all messages
protected with the corresponding public key. To address this concern, protected with the corresponding public key. To address this concern,
it is highly RECOMMENDED that best practices for physical and it is highly RECOMMENDED that best practices for physical and
operational security for PPS and PKG servers be followed and that operational security for PPS and PKG servers be followed and that
these servers be configured (sometimes known as hardened) in these servers be configured (sometimes known as hardened) in
accordance with best current practices [NIST]. An IBE system SHOULD accordance with best current practices [NIST]. An IBE system SHOULD
be operated in an environment where illicit access is infeasible for be operated in an environment where illicit access to the PPS and PKG
attackers to obtain. is infeasible for attackers to obtain.
Attacks that require administrative or IBE user equivalent access to Attacks that require administrative or IBE user equivalent access to
machines used by either the client or the server components defined machines used by either the client or the server components defined
in this document are also outside the scope of this document. 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. This is of particular importance with an IBE system, for an
administrator of a PKG could potentially abuse his authority and
configure the PKG to grant him any IBE private key that the PKG is
capable of calculating. To minimize the possibility of administrators
doing this, a system implementing IBE SHOULD implement n-out-of-m
control for critical administrative functions and SHOULD maintain
auditable logs of all security-critical events that occur in an
operating IBE 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.
7.2. Attacks that are within the 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 allow an Attacks within the scope of this document are those that allow an
adversary to: adversary to:
o passively monitor information transmitted between users of o passively monitor information transmitted between users of
an IBE system and the PPS and PKG an IBE system and the PPS and PKG
o masquerade as a PPS or PKG o masquerade as a PPS or PKG
o perform a DOS attack on a PPS or PKG o perform a DOS attack on a PPS or PKG
o easily guess an IBE users authentication credential o easily guess an IBE user's authentication credential
7.3. Attacks to which the protocols defined in this document are 7.3. Attacks to which the protocols defined in this document are
susceptible susceptible
All communications between users of an IBE system and the PPS or PKG All communications between users of an IBE system and the PPS or PKG
are protected using TLS 1.1 [TLS]. The IBE system defined in this are protected using TLS [TLS]. The IBE system defined in this
document provides no additional security protections for the document provides no additional security for the communications
communications between IBE users and the PPS or PKG. Therefore the between IBE users and the PPS or PKG. Therefore the described IBE
described IBE system is completely dependent on the TLS security system is completely dependent on the TLS security mechanisms for
mechanisms for authentication of the PKG or PPS server and for authentication of the PKG or PPS server and for confidentiality and
confidentiality and integrity of the communications. Should there be integrity of the communications. Should there be a compromise of the
a compromise of the TLS security mechanisms, the integrity of all TLS security mechanisms, the integrity of all communications between
communications between an IBE user and the PPS or PKG will be an IBE user and the PPS or PKG will be suspect.
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. The against an attacker masquerading as a legitimate IBE PPS or PKG. The
protocols rely on the server authentication mechanism of TLS [TLS]. protocols rely on the server authentication mechanism of TLS [TLS].
In addition to the TLS server authentication mechanism IBE client In addition to the TLS server authentication mechanism IBE client
software can provide protection against this possibility by providing software can provide protection against this possibility by providing
user interface capabilities that allows users to visually determine user interface capabilities that allows users to visually determine
that a connection to PPS and PKG servers is legitimate. This that a connection to PPS and PKG servers is legitimate. This
additional capability can help ensure that users cannot easily be additional capability can help ensure that users cannot easily be
tricked into providing valid authorization credentials to an tricked into providing valid authorization credentials to an
attacker. 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.
The IBE user authentication method selected by an IBE PKG SHOULD be The IBE user authentication method used by an IBE PKG SHOULD be of
of sufficient strength to prevent attackers from easily guessing the sufficient strength to prevent attackers from easily guessing the IBE
IBE user's authentication credentials through trial and error. user's authentication credentials through trial and error.
8. IANA Considerations 8. IANA considerations
All of the object identifiers used in this document were assigned by All of the object identifiers used in this document were assigned by
the National Institute of Standards and Technology (NIST), so no the National Institute of Standards and Technology (NIST), so no
further action by the IANA is necessary for this document. further action by the IANA is necessary for this document.
9. References 9. References
9.1. Normative References 9.1. Normative references
[ASN1] CCITT, Recommendation X.209: Specification of Basic Encoding [ASN1] CCITT, "Recommendation X.209: Specification of Basic Encoding
Rules for Abstract Syntax Notation One (ASN.1). 1998. Rules for Abstract Syntax Notation One (ASN.1)," 1998.
[CMS] R. Housley, "Cryptographic Message Syntax," RFC 3369, August [CMS] R. Housley, "Cryptographic Message Syntax," RFC 3369, August
2002. 2002.
[IBCS] X. Boyen, L. Martin, "Identity-based cryptography standard [IBCS] X. Boyen, L. Martin, "Identity-based Cryptography Standard
(IBCS) #1: supersingular curve implementations of the BF (IBCS) #1: Supersingular Curve Implementations of the BF
and BB1 cryptosystems," draft-ieft-martin-ibcs-00.txt. and BB1 Cryptosystems," draft-ieft-martin-ibcs-03.txt.
[IBE] G. Appenzeller, L. Martin, M. Schertler, "Identity-based [IBE] G. Appenzeller, L. Martin and M. Schertler, "Identity-based
Encryption Architecture," draft-ietf-ibearch-01.txt. Encryption Architecture," draft-ietf-ibearch-01.txt.
[KEYWORDS] S. Brander, "Key Words for Use in RFCs to Indicate [KEYWORDS] S. Brander, "Key Words for Use in RFCs to Indicate
Requirement Levels," BCP 14, RFC 2119, March 1997. Requirement Levels," BCP 14, RFC 2119, March 1997.
[NIST] M. Souppaya, J. Wack, K. Kent, "Security Configuration
Checklist Program for IT Products - Guidance for Checklist
Users and Developers," NIST Special Publication SP 800-70, May
2005.
[RFC822] D. Crocker, "Standard for the format of ARPA internet text [RFC822] D. Crocker, "Standard for the format of ARPA internet text
messages," RFC 822, August 1982. messages," RFC 822, August 1982.
[RFC2827] P. Ferguson, D. Senie, "Network Ingress Filtering: [RFC2827] P. Ferguson and 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.
[RFC3492] A. Costello, "Punycode: A Bootstring encoding of Unicode
for Internationalized Domain Names in Applications (IDNA),"
RFC 3492, March 2003.
[RFC3882] D. Turk, "Configuring BGP to Block Denial-of-Service [RFC3882] D. Turk, "Configuring BGP to Block Denial-of-Service
Attacks," RFC 3882, September 2004. Attacks," RFC 3882, September 2004.
[TLS] T. Dierks, E. Rescorla, "The Transport Layer Security (TLS) [TLS] T. Dierks and E. Rescorla, "The Transport Layer Security (TLS)
Protocol Version 1.1," RFC 4346, April 2006. Protocol Version 1.1," RFC 4346, April 2006.
9.2. Informative references
[NIST] M. Souppaya, J. Wack and K. Kent, "Security Configuration
Checklist Program for IT Products - Guidance for Checklist
Users and Developers," NIST Special Publication SP 800-70,
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
Phone: +1 650 543 1280 Phone: +1 650 543 1280
Email: martin@voltage.com Email: martin@voltage.com
Mark Schertler Mark Schertler
Voltage Security Voltage Security
1070 Arastradero Rd Suite 100 1070 Arastradero Rd Suite 100
Palo Alto CA 94304 Palo Alto CA 94304
Phone: +1 650 543 1280 Phone: +1 650 543 1280
Email: mark@voltage.com Email: mark@voltage.com
Intellectual Property Statement Intellectual property statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 13, line 47 skipping to change at page 14, line 47
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its 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 this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity Disclaimer of validity
This document and the information contained herein are provided on an This document and the information contained herein are 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, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE 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 IETF Trust (2007). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and 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
 End of changes. 58 change blocks. 
121 lines changed or deleted 161 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/