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]