draft-ietf-smime-bfibecms-01.txt   draft-ietf-smime-bfibecms-02.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
Expires: April 2007 October 2006
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-01.txt> <draft-ietf-smime-bfibecms-02.txt>
Status of this Document Status of this Document
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or made obsolete by other documents at and may be updated, replaced, or obsoleted by other documents at any
any time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
Abstract Abstract
skipping to change at page 2, line 10 skipping to change at page 2, line 10
(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
2. Using identity-based encryption................................3 2. Using identity-based encryption................................3
4. Convert reduced-time to a GeneralizedTime to get the not-before
"time" value......................................................5
3. Algorithm object identifiers...................................6 3. Algorithm object identifiers...................................6
4. Processing by the sender.......................................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...................................................8
7. Security Considerations........................................9 7. Security Considerations........................................9
7.1. Attacks that are outside the scope of this document.......9 7.1. Attacks that are outside the scope of this document.......9
7.2. Attacks that are within the scope of this document........9 7.2. Attacks that are within the scope of this document.......10
7.3. Attacks that the protocols defined in this document are 7.3. Attacks to which the protocols defined in this document are
susceptible to................................................10 susceptible...................................................10
7.4. Attacks that the protocols defined in this document protect 8. IANA Considerations...........................................11
against.......................................................10 9. References....................................................12
8. IANA Considerations...........................................10 9.1. Normative References.....................................12
9. References....................................................11 Authors' Addresses...............................................13
9.1. Normative References.....................................11 Intellectual Property Statement..................................13
Authors' Addresses...............................................12 Disclaimer of Validity...........................................13
Intellectual Property Statement..................................12 Copyright Statement..............................................14
Disclaimer of Validity...........................................12 Acknowledgment...................................................14
Copyright Statement..............................................13
Acknowledgment...................................................13
1. Introduction 1. Introduction
This document defines the steps needed to use the Boneh-Franklin [BF] This document defines the steps needed to use the Boneh-Franklin [BF]
and Boneh-Boyen [BB1] identity-based encryption (IBE) public-key and 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
skipping to change at page 5, line 20 skipping to change at page 5, line 20
The rfc822Email is the DER-encoded e-mail address of the recipient in The rfc822Email is the DER-encoded e-mail address of the recipient in
the format defined by [RFC822]. the format defined by [RFC822].
The value of "time" is the DER-encoded UTC time after which the The value of "time" is the DER-encoded UTC time after which the
sender wants to let the recipient decrypt the message, so it may be sender wants to let the recipient decrypt the message, so it may be
called the "not-before" time. This is usually set to the time when called the "not-before" time. This is usually set to the time when
the message is encrypted, but MAY be set to a future time. UTC time the message is encrypted, but MAY be set to a future time. UTC time
values are expressed to the nearest second. values are 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 larger time interval to create a key lifetime and reduce rounded to a time interval to create a key lifetime. A key lifetime
the number of IBE private keys that a recipient needs to retrieve. reduces the number of IBE private keys that a recipient needs to
Based on the time interval chosen a recipient would only have to retrieve, but still forces the IBE user to periodically re-
retrieve a new IBE key once during the interval. To do this, follow authenticate. Based on the time interval chosen a recipient would
the following steps. Let "time-interval" be the number of seconds in only have to retrieve a new IBE key once during the interval. To do
this larger time interval. this, follow the following steps. Let "time-interval" be the number
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 since 2. Convert this GeneralizedTime into the number of seconds 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.
skipping to change at page 5, line 49 skipping to change at page 6, line 4
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:
1. Say the GeneralizedTime is 20020401000000Z 1. Say the GeneralizedTime is 20020401000000Z
2. The total-time is 1017612000 2. The total-time is 1017612000
3. A time-interval of 1 week is 604800 seconds. So the reduced- 3. A time-interval of 1 week is 604800 seconds. So the reduced-
time = (floor(1017612000/604800))* 604800 = 1017273600 time = (floor(1017612000/604800))* 604800 = 1017273600
4. Giving the reduced-time GeneralizedTime for a 1 week time 4. Giving the reduced-time GeneralizedTime for a 1 week time
interval of 20020328000000Z interval of 20020328000000Z
When issuing IBE private keys, a PKG SHOULD NOT issue them too far
into the future. This restriction is to prevent an adversary who
obtains an IBE user's authentication credentials from requesting
private keys far into the future and therefore negating the periodic
IBE user re-authentication that key lifetime provides. For example if
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
an adversary gains access to the PKG via the stolen IBE user
credentials they can request all future keys and negate the IBE user
authentication restraints in place.
3. Algorithm object identifiers 3. Algorithm object 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:
bf OBJECT IDENTIFIER ::= { joint-iso-itu(2) country(16) us(840) 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
skipping to change at page 9, line 14 skipping to change at page 9, line 14
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 [IBCS], and the relevant security This document is based on [CMS] and [IBCS], and the relevant security
considerations of those documents apply. In addition, the following considerations of those documents apply.
considerations that are particular to this document.
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 will give the equivalent of in [IBCS], which defines parameters that give 80-bit, 112-bit and
80-bit security, 112-bit security and 128-bit security. We assume 128-bit encryption strength. We assume that capable administrators of
that competent administrators of an IBE system will select parameters an IBE system will select parameters that provide a sufficient
that provide a sufficient resistance to cryptanalytic attacks by resistance to cryptanalytic attacks by adversaries.
adversaries.
Attacks that require access to machines used by either the client or Attacks that give an adversary the ability to access or change the
the server components defined in this document are also outside the information on a PPS or PKG, especially the cryptographic material
scope of this document. Attacks that give an attacker the ability to (referred to in this document as the master secret), will defeat the
access or change the information on a PPS or PKG, especially the security of an IBE system. In particular, if the cryptographic
cryptographic material, will defeat the security of an IBE system. To material is compromised the adversary will have the ability to
address this concern, the PPS and PKG servers SHOULD be configured in recreate any user's private key and therefore decrypt all messages
accordance with best current practices [NIST]. An IBE system should protected with the corresponding public key. To address this concern,
be operated in an environment where such illicit access is infeasible it is highly RECOMMENDED that best practices for physical and
for attackers to obtain. operational security for PPS and PKG servers be followed and that
these servers be configured (sometimes known as hardened) in
accordance with best current practices [NIST]. An IBE system SHOULD
be operated in an environment where illicit access is infeasible for
attackers to obtain.
Attacks that require administrative or IBE user equivalent access to
machines used by either the client or the server components defined
in this document are also outside the scope of this document.
We also assume that all administrators of a system implementing the We also assume that all administrators of a system implementing the
protocols that are defined in this document are trustworthy and will protocols that are defined in this document are trustworthy and will
not abuse their authority to bypass the security provided by an IBE not abuse their authority to bypass the security provided by an IBE
system. Similarly, we assume that users of an IBE system will behave system. Similarly, we assume that users of an IBE system will behave
responsibly, not sharing their authentication credentials with responsibly, not sharing their authentication credentials with
others. Thus attacks that require such assumptions are outside the others. Thus attacks that require such assumptions are outside the
scope of this document. scope of this document.
7.2. Attacks that are within the scope of this document 7.2. Attacks that are within the scope of this document
Attacks that passively monitor information transmitted between users Attacks within the scope of this document are those that allow an
of an IBE system and the PPS and PKG are within the scope of this adversary to:
document, as are attacks that let an adversary masquerade as a PPS or
PKG are also within the scope of this document.
7.3. Attacks that the protocols defined in this document are o passively monitor information transmitted between users of
susceptible to an IBE system and the PPS and PKG
The protocols defined in this document do not explicitly defend o masquerade as a PPS or PKG
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 o perform a DOS attack on a PPS or PKG
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 o easily guess an IBE users authentication credential
against
7.3. Attacks to which the protocols defined in this document are
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 encrypted using SSL 3.0 [SSL] or TLS 1.1 [TLS], which should are protected using TLS 1.1 [TLS]. The IBE system defined in this
provide an adequate level of protection for such communications. document provides no additional security protections for the
communications between IBE users and the PPS or PKG. Therefore the
described IBE system is completely dependent on the TLS security
mechanisms for authentication of the PKG or PPS server and for
confidentiality and integrity of the communications. Should there be
a compromise of the TLS security mechanisms, the integrity of all
communications between an IBE user and the PPS or PKG will be
suspect.
The authentication method used by an IBE PKG should also be The protocols defined in this document do not explicitly defend
sufficiently strong to prevent attackers from easily guessing them against an attacker masquerading as a legitimate IBE PPS or PKG. The
through trial and error. 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 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 [RFC2827, RFC3882] that their use of IBE requires.
The IBE user authentication method selected by an IBE PKG SHOULD be
of sufficient strength to prevent attackers from easily guessing the
IBE 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
skipping to change at page 12, line 5 skipping to change at page 12, line 40
[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, D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source Defeating Denial of Service Attacks which employ IP Source
Address Spoofing," RFC 2827, BCP 38, May 2000. Address Spoofing," RFC 2827, BCP 38, May 2000.
[RFC3882] D. Turk, "Configuring BGP to Block Denial-of-Service [RFC3882] D. Turk, "Configuring BGP to Block Denial-of-Service
Attacks," RFC 3882, September 2004. Attacks," RFC 3882, September 2004.
[TLS] T. Dierks, E. Rescorla, "The Transport Layer Security (TLS)
Protocol Version 1.1," RFC 4346, April 2006.
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
skipping to change at page 13, line 4 skipping to change at page 14, line 4
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 AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 21 change blocks. 
72 lines changed or deleted 104 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/