draft-ietf-smime-bfibecms-00.txt   draft-ietf-smime-bfibecms-01.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 identity-based encryption algorithm with Expires: April 2007 October 2006
the Cryptographic Message Syntax (CMS)
<draft-ietf-smime-bfibecms-00.txt> Using the Boneh-Franklin and Boneh-Boyen identity-based encryption
algorithms with the Cryptographic Message Syntax (CMS)
<draft-ietf-smime-bfibecms-01.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 have been applicable patent or other IPR claims of which he or she is aware
or will be disclosed, and any of which he or she becomes aware will be have been or will be disclosed, and any of which he or she becomes
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 obsoleted by other documents at any and may be updated, replaced, or made obsolete by other documents at
time. It is inappropriate to use Internet-Drafts as reference any 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 conventions for using the Boneh-Franklin This document describes the conventions for using the Boneh-Franklin
identity-based encryption (BF-IBE) algorithm in the Cryptographic (BF) and Boneh-Boyen (BB1) identity-based encryption algorithms in
Message Syntax (CMS). The BF-IBE algorithm supports the transport of the Cryptographic Message Syntax (CMS) to encrypt content encryption
symmetric keys to encrypt content encryption keys. Object keys. Object identifiers and the convention for encoding a
identifiers and the convention for encoding a recipient’s identity recipient's identity are also defined.
are also defined.
Table of Contents Table of Contents
1. Introduction...................................................2 1. Introduction...................................................2
1.1. Terminology...............................................2 1.1. Terminology...............................................3
2. Using identity-based encryption................................3 2. Using identity-based encryption................................3
3. Algorithm object identifier....................................5 3. Algorithm object identifiers...................................6
4. Processing by the sender.......................................6 4. Processing by the sender.......................................6
5. Processing by the receiver.....................................6 5. Processing by the receiver.....................................7
6. ASN.1 Module...................................................7 6. ASN.1 Module...................................................8
7. Security Considerations........................................9 7. Security Considerations........................................9
8. IANA Considerations............................................9 7.1. Attacks that are outside the scope of this document.......9
9. References....................................................10 7.2. Attacks that are within the scope of this document........9
9.1. Normative References.....................................10 7.3. Attacks that the protocols defined in this document are
Author's Addresses...............................................10 susceptible to................................................10
Intellectual Property Statement..................................10 7.4. Attacks that the protocols defined in this document protect
Disclaimer of Validity...........................................11 against.......................................................10
Copyright Statement..............................................11 8. IANA Considerations...........................................10
Acknowledgment...................................................11 9. References....................................................11
9.1. Normative References.....................................11
Authors' Addresses...............................................12
Intellectual Property Statement..................................12
Disclaimer of Validity...........................................12
Copyright Statement..............................................13
Acknowledgment...................................................13
1. Introduction 1. Introduction
This document defines the steps needed to use the Boneh-Franklin This document defines the steps needed to use the Boneh-Franklin [BF]
identity-based encryption (BF-IBE) public-key algorithm [BF] in the and Boneh-Boyen [BB1] identity-based encryption (IBE) public-key
Cryptographic Message Syntax (CMS) [CMS]. BF-IBE is a public key algorithms in the Cryptographic Message Syntax (CMS) [CMS]. IBE is a
technology for encrypting content-encryption keys (CEKs). The public key technology for encrypting content-encryption keys (CEKs)
recipient’s identity is incorporated into the EnvelopedData CMS that can be implemented within the framework of the CMS: the
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-IBE algorithm, which is describe the implementation of the BF and BB1 algorithms, which are
described in detail in [IBCS]. described in detail in [IBCS].
The BF-IBE algorithm is a public-key algorithm in which the public IBE algorithms are a type of public-key cryptographic algorithm in
key is calculated directly from a user’s identity instead of being which the public key is calculated directly from a user's identity
generated randomly. This document defines the object identifiers and instead of being generated randomly. This requires a different set of
syntax of the object that is used to define the identity of a message steps for encryption and decryption than would be used with other
recipient. public-key algorithms, and these steps are defined in Sections 4 and
5 of this document respectively.
This document also defines the object identifiers and syntax of the
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 ANS.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 2. Using identity-based encryption
skipping to change at page 3, line 11 skipping to change at page 3, line 22
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 2. Using identity-based encryption
To use IBE, the OtherRecipientInfo field MUST be set to an To use IBE, the OtherRecipientInfo field MUST be set to an
IBEOtherRecipient type. IBEOtherRecipient type.
IBEOtherRecipientInfo ::= SEQUENCE { IBEOtherRecipientInfo ::= SEQUENCE {
ibeORIType OBJECT IDENTIFIER, ibeORIType OBJECT IDENTIFIER,
ibeORIValue IBERecipientInfo ibeORIValue IBERecipientInfo
} }
The fields of IBEOtherRecipientInfo have the following meanings: The fields of IBEOtherRecipientInfo 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 BF-IBE ibeORIValue defines the identity that was used in the IBE algorithm
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 { v0(0) },
keyFetchMethod OBJECT IDENTIFIER, keyFetchMethod OBJECT IDENTIFIER,
recipientIdentity IBEIdentityInfo, recipientIdentity IBEIdentityInfo,
serverInfo SEQUENCE OF OIDValuePairs OPTIONAL, serverInfo SEQUENCE OF OIDValuePairs OPTIONAL,
encryptedKey EncryptedKey encryptedKey EncryptedKey
} }
The fields of IBERecipientInfo have the following meanings: The fields of IBERecipientInfo have the following meanings:
cmsVersion MUST be set to 0. The cmsVersion MUST be set to 3.
keyFetchMethod is the OID that defines the method of retrieving the The keyFetchMethod is the OID that defines the method of retrieving
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 [IBEPPS] 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 [IBEPPS] 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(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)
} }
recipientIdentity is the data that was used to calculate the public The recipientIdentity is the data that was used to calculate the
key that was used to encrypt the CEK. This MUST be an IBEIdentityInfo public key that was used to encrypt the CEK. This MUST be an
type. This recipientIdentity is used to calculate IBE public and IBEIdentityInfo type. This recipientIdentity is used to calculate IBE
private keys as described in [IBCS]. 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.
district and serial are unique identifiers that are used to construct The district and serial are unique identifiers that are used to
the URI for the location of where the IBE public parameters are construct the URI for the location of where the IBE public parameters
located. The construction and use of this URI is defined in [IBEPPS]. are located. The construction and use of this URI is defined in
[IBE].
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.
cmsIdentityOID OBJECT IDENTIFIER ::= { joint-iso-itu(2) country(16) cmsIdentityOID OBJECT IDENTIFIER ::= { joint-iso-itu(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)
} }
identityData is the data that defines the identity of the recipient. The identityData is the identity of the recipient. For use in S/MIME,
This MUST be an EmailIdentitySchema type which is DER encoded. this MUST be an EmailIdentitySchema type which is DER encoded. Other
applications MAY use other formats for the identityData.
EmailIdentitySchema ::= SEQUENCE { EmailIdentitySchema ::= SEQUENCE {
rfc822Email UTF8STRING, rfc822Email UTF8STRING,
time GeneralizedTime
time UTCTime
} }
rfc822Email is the DER-encoded e-mail address of the recipient in the The rfc822Email is the DER-encoded e-mail address of the recipient in
format defined by [RFC822]. the format defined by [RFC822].
time is the DER-encoded UTC time at which the sender wants to let the The value of "time" is the DER-encoded UTC time after which the
recipient decrypt the message, so it may be called the “not-before” sender wants to let the recipient decrypt the message, so it may be
time. This is usually set to the time when the message is encrypted, called the "not-before" time. This is usually set to the time when
but MAY be set to a future time. UTC time values are expressed to the the message is encrypted, but MAY be set to a future time. UTC time
nearest second, but the sender of an IBE-encrypted message may want values are expressed to the nearest second.
to express this time rounded to a larger time interval to reduce the
number of IBE private keys that a recipient needs to retrieve. To do
this, follow the following steps. Let “time-interval” be the number
of seconds in this larger time interval.
1. Find the UTC time for the not-before value. The sender of an IBE-encrypted message may want to express this time
rounded to a larger time interval to create a key lifetime and reduce
the number of IBE private keys that a recipient needs to retrieve.
Based on the time interval chosen a recipient would 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 of seconds in
this larger time interval.
2. Convert this UTC time into the number of seconds since 1. Find the GeneralizedTime for the not-before value.
January 1, 1970. Call this “total-time.” 2. Convert this GeneralizedTime into the number of seconds since
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 UTC time to get the not-before value. 4. Convert reduced-time to a GeneralizedTime to get the not-before
"time" value.
3. Algorithm object identifier An example of this algorithm for computing a one week time interval
is:
The BF-IBE algorithm as defined in [IBCS] has the following object 1. Say the GeneralizedTime is 20020401000000Z
identifier:
bf-ibe OBJECT IDENTIFIER ::= { joint-iso-itu(2) country(16) us(840) 2. The total-time is 1017612000
3. A time-interval of 1 week is 604800 seconds. So the reduced-
time = (floor(1017612000/604800))* 604800 = 1017273600
4. Giving the reduced-time GeneralizedTime for a 1 week time
interval of 20020328000000Z
3. Algorithm object identifiers
The BF and BB1 algorithms as defined in [IBCS] have the following
object identifiers:
bf OBJECT IDENTIFIER ::= { joint-iso-itu(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-IBE algorithm is keyEncryptionAlgorithm field in the CMS when the BF algorithm is used
to encrypt the CEK.
bb1 OBJECT IDENTIFIER ::= { joint-iso-itu(2) country(16) us(840)
organization(1) identicrypt(114334) ibcs(1) ibcs1(1)
ibe-algorithms(2) bb1(2) }
This is the object identifier that MUST be inserted in the
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 BF-IBE to encrypt content The sender of a message that uses IBE to encrypt content encryption
encryption keys performs the following steps: keys performs the following steps:
1. Selects a set of IBE public parameters to use in the subsequent 1. Selects a set of IBE public parameters to use in the subsequent
steps in accordance with his local security policy. He then steps in accordance with his local security policy. He then
determines the URI where the public parameters can be obtained using determines the URI where the public parameters can be obtained using
the process described in [IBEPPS]. This information MUST be encoded the process described in [IBE]. This information MUST be encoded in
in the IBEIdentityInfo as described in [IBEPPS]. the IBEIdentityInfo as described in Section 2.
2. Sets the fields of an OtherRecipientInfo object to their 2. Sets the fields of an OtherRecipientInfo object to their
appropriate values as described in Section 2. appropriate values as described in Section 2.
3. Calculates a BF-IBE public key as defined in [IBCS] using this 3. Calculates an IBE public key as defined in [IBCS] using this
IBEIdentityInfo as the identity information. IBEIdentityInfo as the identity information.
4. This BF-IBE public key is then used to encrypt the content 4. This IBE public key is then used to encrypt the content
encryption key (CEK), using the algorithms that are defined in encryption key (CEK), using the algorithms that are defined in
[IBCS]. [IBCS].
5. Sets encryptedKey to the BF-IBE-encrypted CEK. 5. Sets encryptedKey to the IBE-encrypted CEK.
6. Within the CMS, keyEncryptionAlgorithm MUST then be set to bf- 6. Within the CMS, keyEncryptionAlgorithm MUST then be set to the
ibe (see Section 3). appropriate OID for the IBE algorithm that was used (see Section 3).
5. Processing by the receiver 5. Processing by the receiver
Upon receiving a message that has a CEK encrypted with BF-IBE, the Upon receiving a message that has a CEK encrypted with IBE, the
recipient performs the following steps to decrypt the CEK: recipient performs the following steps to decrypt the CEK:
1. Determines that the CEK is IBE-encrypted by noting that the 1. Determines that the CEK is IBE-encrypted by noting that the
oriType of the OtherRecipientInfo type is set to ibeORIType. oriType of the OtherRecipientInfo type is set to ibeORIType.
2. Determines that the recipientIdentity was used as the identity 2. Determines that the recipientIdentity was used as the identity
in BF encryption of the CEK. in IBE encryption of the CEK.
3. Determines the location of the IBE public parameters and the 3. Determines the location of the IBE public parameters and the
IBE Private Key Generator as described in [IBEPPS]. IBE Private Key Generator as described in [IBE].
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 [IBEPPS]. 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 [IBE3]. 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
BFCMS-module { joint-iso-itu(2) country(16) us(840) organization(1) IBECMS-module { joint-iso-itu(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(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 { v0(0) },
keyFetchMethod OBJECT IDENTIFIER, keyFetchMethod OBJECT IDENTIFIER,
recipientIdentity IBEIdentityInfo, recipientIdentity IBEIdentityInfo,
serverInfo SEQUENCE OF OIDValuePairs OPTIONAL, serverInfo SEQUENCE 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 UTCTime
} }
cmsIdentityOID OBJECT IDENTIFIER ::= { joint-iso-itu(2) country(16) cmsIdentityOID OBJECT IDENTIFIER ::= { joint-iso-itu(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(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 [IBCS1], and the relevant This document is based on [CMS] and [IBCS], and the relevant security
security considerations of those documents apply. considerations of those documents apply. In addition, the following
considerations that are particular to this document.
7.1. Attacks that are outside the scope of this document
Attacks on the cryptographic algorithms that are used to implement
IBE are outside the scope of this document. Such attacks are detailed
in [IBCS], which defines parameters that will give the equivalent of
80-bit security, 112-bit security and 128-bit security. We assume
that competent administrators of an IBE system will select parameters
that provide a sufficient resistance to cryptanalytic attacks by
adversaries.
Attacks that require access to machines used by either the client or
the server components defined in this document are also outside the
scope of this document. Attacks that give an attacker the ability to
access or change the information on a PPS or PKG, especially the
cryptographic material, will defeat the security of an IBE system. To
address this concern, the PPS and PKG servers SHOULD be configured in
accordance with best current practices [NIST]. An IBE system should
be operated in an environment where such illicit access is infeasible
for attackers to obtain.
We also assume that all administrators of a system implementing the
protocols that are defined in this document are trustworthy and will
not abuse their authority to bypass the security provided by an IBE
system. Similarly, we assume that users of an IBE system will behave
responsibly, not sharing their authentication credentials with
others. Thus attacks that require such assumptions are outside the
scope of this document.
7.2. Attacks that are within the scope of this document
Attacks that passively monitor information transmitted between users
of an IBE system and the PPS and PKG are within the scope of this
document, as are attacks that let an adversary masquerade as a PPS or
PKG are also within the scope of this document.
7.3. Attacks that the protocols defined in this document are
susceptible to
The protocols defined in this document do not explicitly defend
against an attacker masquerading as a legitimate IBE PPS or PKG. To
provide protection against this possibility, client software that
implements the protocols defined in this document SHOULD have a user
interface that allows users to view the details of connections to PPS
and PKG servers so that users cannot easily be tricked into providing
valid authorization credentials to an attacker.
The protocols defined in this document are also vulnerable to Denial
of Service attacks against an IBE PPS or PKG. DOS attacks against
either component can result in users unable to access the information
and services required to encrypt or decrypt using IBE, and users of
an IBE system SHOULD take the appropriate countermeasures [RFC2827,
RFC3882] that their use of IBE requires.
7.4. Attacks that the protocols defined in this document protect
against
All communications between users of an IBE system and the PPS or PKG
are encrypted using SSL 3.0 [SSL] or TLS 1.1 [TLS], 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.
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-smime-ibcs-00.txt. and BB1 cryptosystems," draft-ieft-martin-ibcs-00.txt.
[IBEPPS] G. Appenzeller, “Parameter and Policy Lookup for Identity- [IBE] G. Appenzeller, L. Martin, M. Schertler, "Identity-based
based Encryption,” draft-ietf-ibepps-00.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.
[RFC822] D. Crocker, “Standard for the format of ARPA internet text [NIST] M. Souppaya, J. Wack, K. Kent, "Security Configuration
messages,” RFC 822, August 1982. Checklist Program for IT Products - Guidance for Checklist
Users and Developers," NIST Special Publication SP 800-70, May
2005.
Authors’ Addresses [RFC822] D. Crocker, "Standard for the format of ARPA internet text
messages," RFC 822, August 1982.
[RFC2827] P. Ferguson, D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing," RFC 2827, BCP 38, May 2000.
[RFC3882] D. Turk, "Configuring BGP to Block Denial-of-Service
Attacks," RFC 3882, September 2004.
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
 End of changes. 98 change blocks. 
161 lines changed or deleted 222 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/