One document matched: draft-ietf-smime-ibearch-00.txt
L. Martin
S/MIME Working Group M. Schertler
Internet Draft Voltage Security
Expires: December 2006 June 2006
Identity-based Encryption Architecture
<draft-ietf-smime-ibearch-00.txt>
Status of this Document
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
or will be disclosed, and any of which he or she becomes aware will be
disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
This document describes the security architecture required to implement
identity-based encryption, a public-key encryption technology that uses
a user’s identity as a public key.
Table of Contents
1. Introduction...................................................2
1.1. Terminology...............................................2
2. Identity-based Encryption......................................2
2.1. Overview..................................................2
2.2. Sending a message that is encrypted using IBE.............3
2.2.1. Sender obtains IBE public parameters.................3
Martin, Schertler Expires December 2006 [Page 1]
Internet-Draft IBE Architecture June 2006
2.2.2. Sender IBE-encrypts message..........................4
2.3. Receiving and viewing an IBE-encrypted message............4
2.3.1. Recipient obtains IBE private key from PKG...........5
2.3.2. Recipient decrypts IBE-encrypted message.............6
3. Security Considerations........................................6
4. IANA Considerations............................................6
5. References.....................................................6
5.1. Normative References......................................6
Author's Address..................................................7
Intellectual Property Statement...................................7
Disclaimer of Validity............................................8
Copyright Statement...............................................8
Acknowledgment....................................................8
1. Introduction
This document describes the security architecture required to
implement identity-based encryption, a public-key encryption
technology that uses a user’s identity as a public key.
1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [KEY].
2. Identity-based Encryption
2.1. Overview
Identity-based encryption (IBE) is a public-key technology that
allows keys to be calculated from an identity. This contrasts with
other public-key systems [P1363], in which keys are generated
randomly. Much like other public-key systems, IBE systems have public
parameters that define their operation, and a user of an IBE system
needs to obtain these public parameters before he can do any IBE
operations. A user of an IBE system is capable of calculating the
public key of a recipient after he obtains the public parameters for
the IBE system and the recipient of an IBE-encrypted message can
decrypt an IBE-encrypted message if he has both the IBE public
parameters and the necessary private key.
With an IBE public key, a user can encrypt messages to a recipient
using the conventions of the Cryptographic Message Syntax [CMS].
Within the framework of the CMS, a recipient also needs one
additional element of information to decrypt a message: the URI of
Martin, Schertler Expires December 2006 [Page 2]
Internet-Draft IBE Architecture June 2006
where he can obtain the private key that he needs to decrypt the IBE-
encrypted message.
To decrypt an IBE-encrypted message, the recipient needs to obtain
IBE public parameters as well as the private key that corresponds to
the public key that the sender used. A recipient of an IBE-encrypted
message obtains the IBE public parameters the same way that the
sender did. The IBE private key is obtained after authenticating to a
private key generator (PKG), a trusted third party that calculates
private keys for users.
This document describes the overall architecture that can be used to
implement IBE, and how the components of this architecture work
together to provide a functioning IBE system. The components required
for a complete IBE system include the following:
o A Public Parameter Server (PPS). A PPS provides IBE public
parameters and policy information for an IBE Private-key
Generator and is uniquely identified by the form of an
identity that it supports.
o A URI for a Private-key Generator (PKG) where users can get
IBE private keys after authenticating their identity in some
way.
Diagrams of these components and their interactions are shown in the
following sections. Note that IBE algorithms are used only for
encryption, so that any digital signatures that are required will
need to be provided by an additional mechanism.
2.2. Sending a message that is encrypted using IBE
2.2.1. Sender obtains IBE public parameters
The first step is for the sender of a message to obtain the IBE
public parameters that he needs for calculating the IBE public key of
the recipient. He obtains this information from a PPS that is hosted
at a well-known URI. The IBE public parameters contain all of the
information that the sender needs to create an IBE-encrypted message
except for the identity of the recipient. [IBEPPS] describes the URI
where a PPS is located, the format of IBE public parameters, and how
to obtain them. The URI from which users obtain IBE public parameters
MUST be authenticated in some way as defined in [IBEPPS], for
example, by using the SSL 3.0 protocol [SSL3]. [IBEPPS] also
describes the way in which identity formats are defined and a minimum
Martin, Schertler Expires December 2006 [Page 3]
Internet-Draft IBE Architecture June 2006
interoperable format that all PPSs and PKGs MUST support. This step
is shown below in Figure 1.
The sender of an IBE-encrypted message selects the PPS and
corresponding PKG based on his local security policy. Different PPSs
may provide public parameters that specify different IBE algorithms
or different key strengths, for example, or different PKGs may
require different levels of authentication before granting IBE
private keys.
IBE Public Parameter Request
----------------------------->
Sender Public Parameter Server
<-----------------------------
IBE Public Parameters
Figure 1 Requesting IBE Public Parameters
2.2.2. Sender IBE-encrypts message
To IBE-encrypt a message, the sender chooses a content encryption key
(CEK) and uses it to encrypt his message and then encrypts the CEK
with the recipient’s IBE public key as described in [CMS]. This
operation is shown below in Figure 2. [IBCS] describes the algorithms
needed to implement two forms of IBE and [IBECMS] describes how to
use the Cryptographic Message Syntax (CMS) to encapsulate the
encrypted message along with the IBE information that the recipient
needs to decrypt the message, including the URI of the PPS and PKG.
CEK ----> Sender ----> IBE-encrypted CEK
^
|
|
Recipient’s Identity
and IBE Public Parameters
Figure 2 Using an IBE Public-key Algorithm to Encrypt
2.3. Receiving and viewing an IBE-encrypted message
The recipient of an IBE-encrypted message parses the message as
described in [IBECMS]. This gives him the URI where he can obtain the
IBE public parameters required to perform IBE calculations as well as
Martin, Schertler Expires December 2006 [Page 4]
Internet-Draft IBE Architecture June 2006
the identity that was used to encrypt the messsage. The PPS also
gives the URI of the PKG where the recipient of an IBE-encrypted
message can obtain the IBE private keys. After successfully
authenticating to this PKG the recipient, will receive the IBE
private key.
The PKG may allow users other than the intended recipient to receive
some IBE private keys. Giving a mail filtering appliance permission
to obtain IBE private keys on behalf of users, for example, can allow
the appliance to decrypt and scan encrypted messages for viruses or
other malicious features.
2.3.1. Recipient obtains IBE public parameters from PPS
Before he can perform any IBE calculations related to the message
that he has received, the recipient of an IBE-encrypted message needs
to obtain the IBE public parameters that were used in the encryption
operation. This operation is shown below in Figure 3. The comments in
Section 2.2.1 also apply to this operation.
IBE Public Parameter Request
----------------------------->
Recipient Public Parameter Server
<-----------------------------
IBE Public Parameters
Figure 3 Requesting IBE Public Parameters
2.3.2. Recipient obtains IBE private key from PKG
To obtain an IBE private key, the recipient of an IBE-encrypted
message provides an identity that was used to calculate an IBE public
key to a PKG and requests the private key that corresponds to the IBE
public key. After providing the identity for which a private key is
being requested, a user MUST authenticate to the PKG. [IBEPKG]
defines the protocol for communicating with a PKG as well as a
minimum interoperable way to authenticate to a PKG that all IBE
implementations MUST support. Because the security of IBE private
keys is vital to the overall security of an IBE system, IBE private
keys MUST be transported to recipients over a secure protocol. PKGs
MUST support the SSL v 3.0 [SSL3] protocol and SHOULD support the TLS
v 1.1 [TLS] protocol for transport of IBE private keys. This
operation is shown below in Figure 4.
Martin, Schertler Expires December 2006 [Page 5]
Internet-Draft IBE Architecture June 2006
IBE Private Key Request
---------------------------->
Recipient PKG
<----------------------------
IBE Private Key
Figure 4 Obtaining an IBE Private Key
2.3.3. Recipient decrypts IBE-encrypted message
After obtaining the necessary IBE private key, the recipient uses
that IBE private key and the corresponding IBE public parameters to
decrypt the CEK. This operation is shown below in Figure 5. He then
uses the CEK to decrypt the encrypted message content.
IBE-encrypted CEK ----> Recipient ----> CEK
^
|
|
IBE Private Key
and IBE Public Parameters
Figure 5 Using an IBE Public-key Algorithm to Decrypt
3. Security Considerations
This entire document relates to security considerations.
4. IANA Considerations
No further action by the IANA is necessary for the protocols
described in this document.
5. References
5.1. Normative References
[CMS] R. Housley, “Cryptographic Message Syntax,” RFC 3369, August
2002.
[IBEPPS] G. Appenzeller, “Identity-based Encryption Parameter and
Policy Lookup,” draft-ietf-smime-ibepps-00.txt, June 2006.
Martin, Schertler Expires December 2006 [Page 6]
Internet-Draft IBE Architecture June 2006
[IBCS] X. Boyen, L. Martin, “Identity-Based Cryptography Standard
(IBCS) #1: Supersingular Curve Implementations of the BF and
BB1 Cryptosystems,” draft-ietf-smime-ibcs-00.txt, June 2006.
[IBECMS] M. Schertler, L. Martin, “Using the Boneh-Franklin identity-
based encryption algorithm with the Cryptographic Message
Syntax (CMS),” draft-ietf-smime-bfibecms-01.txt, June 2006.
[IBEPKG] G. Appenzeller, Identity-based Encryption Private Key
Request Protocol, draft-ietf-smime-ibepkg-00.txt, June 2006.
[KEY] S. Brander, “Key Words for Use in RFCs to Indicate Requirement
Levels,” BCP 14, RFC 2119, March 1997.
[P1363] IEEE P1363.3, “Standards Specifications for Public-Key
Cryptography,” 2001.
[SSL3] A. Frier, P. Karlton, P. Kocher, "The SSL 3.0 Protocol,"
Netscape Communications Corp., Nov 18, 1996.
[TLS] T. Dierks, E. Rescorla, “The Transport Layer Security Protocol
Version 1.1,” RFC 4346, April 2006.
Authors’ Addresses
Luther Martin
Voltage Security
1070 Arastradero Rd Suite 100
Palo Alto CA 94304
Phone: +1 650 543 1280
Email: martin@voltage.com
Mark Schertler
Voltage Security
1070 Arastradero Rd Suite 100
Palo Alto CA 94304
Phone: +1 650 543 1280
Email: mark@voltage.com
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
Martin, Schertler Expires December 2006 [Page 7]
Internet-Draft IBE Architecture June 2006
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Martin, Schertler Expires December 2006 [Page 8]
| PAFTECH AB 2003-2026 | 2026-04-23 20:32:50 |