G. Appenzeller
                                                                    L. Martin
     S/MIME Working Group                                       M. Schertler
     Internet Draft                                         Voltage Security
     Expires: June 2007                                        December 2006
                       Identity-based Encryption Architecture

                            <draft-ietf-smime-ibearch-02.txt>

                          <draft-ietf-smime-ibearch-03.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 made obsolete 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 user's identity as a to generate their public key.

     Table of Contents

        1. Introduction...................................................3
           1.1. Terminology...............................................3
        2. Identity-based Encryption......................................3
           2.1. Overview..................................................3
           2.2. Sending a Message that is Encrypted Using IBE.............4
              2.2.1. Sender Obtains Recipient's IBE Public Parameters.................4 Parameters.....5
              2.2.2. Sender Construct and Send IBE-encrypts Message..........................5 Message..............5
           2.3. Receiving and Viewing an IBE-encrypted Message............5 Message............6
              2.3.1. Recipient Obtains IBE Public Parameters from PPS.....5 PPS.....7
              2.3.2. Recipient Obtains IBE Private Key from PKG...........6 PKG...........7
              2.3.3. Recipient Decrypts IBE-encrypted Message.............6 Message.............7
        3. Public Parameter Lookup........................................7 Lookup........................................8
           3.1. Request Method............................................8 Method............................................9
           3.2. Parameter and Policy Format...............................8 Format...............................9
        4. Private Key Request Protocol..................................10 Protocol..................................12
           4.1. Overview.................................................10 Overview.................................................12
           4.2. Private Key Request......................................11 Request......................................12
           4.3. Request Structure........................................11 Structure........................................13
           4.4. Authentication...........................................12 Authentication...........................................13
           4.5. Server Response Format...................................13 Format...................................14
           4.6. Response Containing a Private Key........................13 Key........................14
           4.7. Responses Containing a Redirect..........................14 Redirect..........................15
           4.8. Responses Indicating an Error............................15 Error............................16
        5. ASN.1 Module..................................................16 Module..................................................17
        6. Security Considerations.......................................18 Considerations.......................................19
           6.1. Attacks that are outside the scope of this document......18 document......19
           6.2. Attacks that are within the scope of this document.......19
           6.3. document.......20
              6.2.1. Attacks that to which the protocols defined in this document
              are
           susceptible to................................................19
           6.4. Attacks that the protocols defined in this document protect
           against.......................................................19 susceptible............................................20
        7. IANA Considerations...........................................19 Considerations...........................................21
        8. References....................................................21 References....................................................22
           8.1. Normative References.....................................21
        Authors` Addresses...............................................23 References.....................................22
        Authors' Addresses...............................................24
        Intellectual Property Statement..................................23 Statement..................................24
        Disclaimer of Validity...........................................24 Validity...........................................25
        Copyright Statement..............................................24
        Acknowledgment...................................................24 Statement..............................................25
        Acknowledgment...................................................25
     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 [KEY].

     2. Identity-based Encryption

     2.1. Overview

        Identity-based encryption (IBE) is a public-key encryption technology
        that allows keys a public key to be calculated from an identity. identity and the
        corresponding private key to be calculated from the public key.
        Calculation of both the public and private keys in an IBE-based
        system can occur as needed, resulting in just-in-time key material.
        This contrasts with other public-key systems [P1363], in which keys
        are generated
        randomly. IBE systems have public parameters that define their
        operation, randomly and distributed prior to secure communication
        commencing. The ability to calculate a user of recipient's public key, in
        particular, eliminates the need for the sender and receiver in an IBE
        IBE-based messaging system needs to obtain these public
        parameters interact with each other, either
        directly or through a proxy such as a directory server, before he can do any IBE operations. A user of
        sending secure messages.

        This document describes an IBE IBE-based messaging system is capable of calculating and how the public key
        components of a recipient after
        he obtains the public parameters system work together. The components required for the a
        complete IBE messaging system and are the recipient
        of following:

              o  A Private-key Generator (PKG). The PKG contains the
                 cryptographic material, known as a master secret, for
                 generating an IBE-encrypted message can decrypt individual's IBE private key. A PKG accepts an IBE-encrypted message if
        he has both the
                 IBE public parameters user's private key request and after successfully
                 authenticating them in some way returns the necessary IBE private key.

        With an

              o  A Public Parameter Server (PPS). IBE System Parameters
                 include publicly sharable cryptographic material, known as
                 IBE public key, a user can encrypt messages to a recipient
        using the conventions of the Cryptographic Message Syntax [CMS].
        Within the framework of parameters, and policy information for the CMS, PKG. A
                 PPS provides a recipient also needs one
        additional element well-known location for secure distribution
                 of IBE public parameters and policy information to decrypt a message: for the URI of
        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
                 PKG.

        A logical architecture would be to
        the public key have a PKG/PPS per a name space,
        such as a DNS zone. The organization that controls the sender used. A recipient of an IBE-encrypted
        message obtains the IBE public parameters DNS zone would
        also control the same way that PKG/PPS and thus the
        sender did. The IBE private key is obtained after authenticating determination of which PKG/PSS
        to a
        private key generator (PKG), a trusted third party that calculates use when creating public and private keys for users.

        This document describes the overall architecture that organization's
        members. In this case the PPS URI can be used to
        implement IBE, and how uniquely created by the components form
        of this the identity that it supports. This architecture work
        together would make it
        clear which set of public parameters to provide use and where to retrieve
        them for a functioning given identity (i.e. an RFC822 address).

        IBE system. The components required encrypted messages can use standard message formats, such as the
        Cryptographic Message Syntax [CMS]. How to use IBE with CMS is
        defined in [IBECMS].

        Note that IBE algorithms are used only for encryption, so if digital
        signatures are required they will need to be provided by an
        additional mechanism.

     2.2. Sending a complete Message that is Encrypted Using IBE system include

        In order to send an encrypted message, an IBE user must perform the following:

              o  A Public Parameter Server (PPS). A PPS provides
        following steps:

           1. Obtain the recipient's public parameters

              The recipient's IBE public parameters allow the creation of
              unique public and policy information private keys for the recipient's domain. A
              user of an IBE Private-key
                 Generator. Its URI system is uniquely identified by capable of calculating the form public key
              of an
                 identity that it supports.

              o  A Private-key Generator (PKG) where users can get IBE
                 private keys a recipient after authenticating he obtains the public parameters for their identity in some
                 way.

        Diagrams
              IBE system. Once the public parameters for a recipient's domain
              are obtained, IBE-encrypted messages can be sent to all members
              of these components that domain.

           2. Construct and their interactions are shown Send IBE-encrypted Message

              All that is needed, in addition to the
        following sections. Note that IBE algorithms are used only public parameters,
              is the recipient's identity in order to generate their public
              key for
        encryption, so that any digital signatures use in encrypting messages to them. When this identity
              is the same as the identity that are required will
        need to a message would be provided by an additional mechanism.

          2.2. Sending addressed
              to, then no more information is needed from a Message that user to send
              someone a secure message then is Encrypted Using IBE needed to send them an
              unsecured message. This is one of the major benefits of an IBE-
              based secure messaging system. Examples of identities can be an
              individual, group, or role identifiers.

     2.2.1. Sender Obtains Recipient's IBE Public Parameters

        The first step is for the sender of a message to obtain obtains the IBE public parameters that he
        needs for calculating the IBE public key of the recipient. He obtains this information recipient 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 IBE-
        encrypted message except for the identity of the recipient. Section 3
        of this document 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;
        PPS servers MUST support TLS 1.1 [TLS] and MAY support SSL 3.0 [SSL] to satisfy this requirement.
        Section 3 also describes the way in which identity formats are
        defined and a minimum interoperable format that all PPSs and PKGs
        MUST support. This step is shown below in Figure 1.

                     IBE Public Parameter Request
                    ----------------------------->
             Sender                                Public Parameter Server
                    <-----------------------------
                         IBE Public Parameters

                      Figure 1 Requesting IBE Public Parameters

        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 require the use of PKGs
        that 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 Construct and Send 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.

                      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

        In order to read an encrypted message, a recipient of an IBE-encrypted IBE-
        encrypted message parses the message as described in [IBECMS]. This
        gives him the URI where he can needs to obtain the IBE public parameters
        required to perform IBE calculations as well as the identity that was
        used to encrypt the message. Next the recipient must carry out the
        following steps:

           1. Obtain the recipient's public parameters

              An IBE system's public parameters allow it to uniquely create
              public and private keys. The recipient of an IBE-encrypted
              message can decrypt an IBE-encrypted message if he has both the
              IBE public parameters and the necessary IBE private key. The
              PPS can also gives provide the URI of the PKG where the recipient of
              an IBE-encrypted message can obtain the IBE private keys. After

           2. Obtain the IBE private key from the PKG

              To decrypt an IBE-encrypted message, in addition to the IBE
              public parameters the recipient needs to obtain the private key
              that corresponds to the public key that the sender used. The
              IBE private key is obtained after successfully authenticating
              to
        this PKG the a private key generator (PKG), a trusted third party that
              calculates private keys for users. The recipient receives the
              IBE private key over an HTTPS connection.

           3. Decrypt IBE-encrypted message

              The IBE private key decrypts the CEK (see section 2.2.2). The
              CEK is then used to decrypt encrypted message.

        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 the IBE public key used to encrypt the message and
        their authentication credentials 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. Section 4 of this
        document 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 TLS 1.1 [TLS] and MAY support SSL 3.0 [SSL] for transport of IBE private keys. This
        operation is shown below in Figure 4.

                          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 as specified in
        [IBECMS].

        IBE-encrypted CEK ----> Recipient ----> CEK

                                    ^
                                    |
                                    |

                            IBE Private Key
                        and IBE Public Parameters

                Figure 5 Using an IBE Public-key Algorithm to Decrypt

     3. Public Parameter Lookup

        For an identity-based encryption (IBE) system to operate, the sender,
        receiver and the private key generator (PKG) must agree on a number
        of parameters, specifically:

          1. The Public Parameters of the PKG. The public parameters are part
             of the encryption (and in some cases decryption) operation of
             the IBE system. Generation of public parameters and the master
             secret, as well as the mathematical structure of the public
             parameters for the BF and BB1 algorithms are described in
             [IBCS].

          2. The URI of the PKG. Knowledge of this URI allows recipients to
             request a private key as described in Section 4 of this
             document.

          3. The schema to format the identity strings. When issuing a
             private key, the PKG often wants to limit who can obtain private
             keys. For example for an identity string that contains
             "bob@example.com", only the owner of the identity string should
             be able to request the private key. To ensure that the PKG can
             interpret the identity string for which a private key is
             requested, the encryption engine and the PKG have to use the
             same schema for identity strings. Identity schemas are described
             in [IBECMS]

        This section specifies how a component of an IBE system can retrieve
        these parameters. A sending or receiving client MUST allow
        configuration of these parameters manually, e.g. through editing a
        configuration file. However for simplified configuration a client MAY
        also implement the PP URI request method described in this document
        to fetch the system parameters based on a configured URI. This is
        especially useful for federating between IBE systems. By specifying a
        single URI a client can be configured to fetch all the relevant
        parameters for a remote PKG. These public parameters can then be used
        to encrypt messages to recipients who authenticate to and retrieve
        private keys from that PKG.

        The following section outlines the URI request method to retrieve a
        parameter block and describes the structure of the parameter block
        itself.

     3.1. Request Method

        The configuration URI SHOULD be an HTTPS URI [HTTP] of the format:

          http_URI = "https:" "//" host [ ":" port ] [ abs_path ]

        An example URI for ibe system parameters is

          https://ibe-0000.example.com/example.com.pem

        To retrieve the IBE system parameters, the client SHOULD use the HTTP
        GET method as defined in [HTTP]. The request MUST happen over a
        secure protocol. The requesting client MUST support TLS 1.1 [TLS] and
        MAY support SSL 3.0 [SSL]. [TLS].
        When requesting the URI the client MUST only accept the system
        parameter block if the server identity was verified successfully by
        TLS 1.1 or SSL 3.0. 1.1.

        A successful GET request returns in its body the Base64 encoding of
        the DER-encoded [DER] ASN.1 structure that is described in the next
        section.

     3.2. Parameter and Policy Format

        The IBE System parameters are a set of

        IBESysParams ::= SEQUENCE {
           version              INTEGER { v2(2) },
           districtName         UTF8String,
           districtSerial       INTEGER,
           validity             Validity,
           ibePublicParameters  IBEPublicParameters,
           ibeIdentitySchema    OBJECT IDENTIFIER,
           ibeParamExtensions   IBEParamExtensions
        }
        The version specifies the version of the parameter IBESysParams format. For the
        format described in this document it MUST be set to 2. The district
        name is a an UTF8String that MUST be a valid domain name as defined by
        [DOM]. The districtSerial is a serial number that represents a unique
        set of IBE public parameters. If new parameters are published for a
        district, it MUST be increased to a number greater than the
        previously-used serial number.

        The validity for IBE public parameters are period or lifetime of a specific instance of the
        IBESysParams is defined as follows:

        ValidityPeriod ::= SEQUENCE {
          notBefore     GeneralizedTime,
          notAfter      GeneralizedTime
        }

        A client MUST verify that the date on which it utilizes the IBE
        system parameters that it obtains
        are currently within falls between the validity period notBefore time and the notAfter
        times of the IBE system parameters and SHOULD not use these the parameters
        if they are do not.

        IBE system parameters MUST be regenerated and republished whenever
        the ibePublicParameters, ibeIdentitySchema, or ibeParamExtensions
        change for a district. A client SHOULD refetch the IBE system
        parameters at an application configurable interval to ensure that it
        has the most current version on the IBE system parameters.

        It is possible to create identities for use in IBE that have a time
        component, as described in [IBECMS]. If such an identity is used, the
        time component of the identity MUST fall between the notBefore time
        and the notAfter times of the IBE system parameters.

        IBEPublicParameters is a set of public parameters that correspond to
        IBE algorithms that the PKG associated with this district
        understands.

        IBEPublicParameters ::= SEQUENCE OF IBEPublicParameter

        IBEPublicParameter  ::= SEQUENCE {
          ibeAlgorithm          OBJECT IDENTIFIER,
          publicParameterData   OCTET STRING
        }

        The ibeAlgorithm OID specifies an IBE algorithm. The
        publicParameterData is a DER encoded ASN.1 structure that contains
        the actual cryptographic parameters. Its specific structure depends
        on the algorithm. The OIDs for two IBE algorithms, the Boneh-Franklin
        and Boneh-Boyen algorithms and their publicParameterData structures
        are defined in [IBCS].

        The IBESysParams of a district MUST contain at least one algorithm
        and MAY contain several algorithms. It MUST NOT contain two or more
        IBEPublicParameter entries with the same algorithm. A client that
        wants to use IBESysParams can chose any of the algorithms specified
        in the publicParameterData structure. A client MUST implement at
        least the Boneh-Franklin algorithm and MAY implement the Boneh-Boyens Boneh-Boyen
        and other algorithms. If a client does not support any of the
        supported algorithms it MUST generate an error message and fail.

        ibeIdentitySchema is an OID that defines the type of identities that
        are used with this district. The OIDs and the required and optional
        fields for each OID are described in [IBECMS].

        IBEParamExtensions is a set of extensions that can be used to define
        additional parameters that particular implementations may require.

        IBEParamExtensions ::= SEQUENCE OF IBEParamExtension

        IBEParamExtension ::= SEQUENCE {
          ibeParamExtensionOID     OBJECT IDENTIFIER,
          ibeParamExtensionValue   OCTET STRING
        }

        The contents of the octet string are defined by the specific
        extension type. The System Parameters of a district MAY have any
        number of extensions, including zero.

        The IBEParamExtension pkgURI defines the URI of the Private Key
        Generator of the district. If the PKG is publicly accessible, this
        extension SHOULD be present to allow the automatic retrieval of
        private keys for recipients of encrypted messages. For this extension
        the OCTET STRING contains a UTF8String with the URI of the key
        server.

        ibeParamExt OBJECT IDENTIFIER ::= {
          ibcs ibcs3(3) parameter-extensions(2)
        }

        pkgURI OBJECT IDENTIFIER ::= { ibeParamExt pkgURI(1) }

     4. Private Key Request Protocol

     4.1.  Overview

        In an identity-based encryption (IBE) system messages are encrypted
        using a public key that is locally calculated from public parameters
        and a user`s identity and decrypted using a private key that
        corresponds to the user`s public key. These private keys are
        generated by a private key generator (PKG) based on a global secret
        called a master secret.

        When requesting a private key, a client has to transmit two
        parameters:

           1. The identity for which it is requesting a key

           2. Authentication credentials for the individual requesting the
              key

        These two are often not the same as a single user may have access to
        multiple aliases. For example an email user may have access to the
        keys that correspond to two different email addresses, e.g.
        bob@example.com and bob.smith@example.com.

        This section defines the protocol to request private keys, a minimum
        user authentication method for interoperability, and how to pass
        authentication credentials to the server. It assumes that a client
        has already determined the URI of the PKG. This can be done from
        hints included in the IBE message format [IBECMS] and the system
        parameters of the IBE system.

     4.2. Private Key Request

        To request a private key, a client performs a HTTP POST method as
        defined in [HTTP]. The request MUST happen over a secure protocol.
        The requesting client MUST support TLS 1.1 [TLS] and MAY support SSL
        3.0 [SSL]. [TLS]. When requesting the
        URI the client MUST verify the server certificate [RFC2818], and MUST
        abort the key request if the server certificate verification of the
        TLS or SSL connection fails. Doing so is critical to protect the
        authentication credentials and the private key against man-in-the-middle man-in-the-
        middle attacks when it is transmitted from the key server to the
        client.

     4.3. Request Structure

        The POST method contains in its body the following XML structure:

        <ibe:request xmlns:ibe="urn:ietf:params:xml:ns:ibe">
           <ibe:header>
              <ibe:client version="clientID"/>
           </ibe:header>
           <ibe:body>
           <ibe:keyRequest>
              <ibe:algorithm>
                <oid> algorithmOID </oid>
              </ibe:algorithm>
              <ibe:id>
              ibeIdentityInfo
              </ibe:id>
           </ibe:keyRequest>
           </ibe:body>
        </ibe:request>

        A <ibe:request> SHOULD include a <ibe:clientID> element that
        identifies the client type and client version.

        A key request MUST contain a valid ibeIdentityInfo that the private
        key is requested for. This identity is the base64 encoding of the DER
        encoding of the ASN.1 structure IBEIdentityInfo as defined in
        [IBECMS].

        A key request MUST contain a <ibe:algorithm> element that contains a
        XER encoded ASN.1 OBJECT IDENTIFIER that identifies the algorithm for
        which a key is requested. OIDs for the BB1 and BF algorithms are
        listed in [IBCS].

        A client MAY include optional additional XML elements in the
        <ibe:body> part of the key request.

     4.4. Authentication

        When a client requests a key from a PKG, the PKG SHOULD authenticate
        the client before issuing the key. Authentication may either be done
        through the key request structure or as part of the secure transport
        protocol.

        A client or server implementing the request protocol MUST support
        HTTP Basic Auth as described in [AUTH]. A client and server SHOULD
        also support HTTP Digest Auth as defined in [AUTH].

        For authentication methods that are not done by the transport
        protocol, a client MAY include additional authentication information
        in xml elements in the body part of the key request. If a client does
        not know how to authenticate to a server, the client MAY send a key
        request without authentication information. If the key server
        requires the client to authenticate externally, it MAY reply with a
        201 response code as defined below to redirect the client to the
        correct authentication mechanism.

     4.5. Server Response Format

        The key server replies to the HTTP request with an HTTP response. If
        the response contains a client error or server error status code, the
        client MUST abort the key request and fail.

        If the PKG replies with a HTTP response that has a status code
        indicating success, the body of the reply MUST contain the following
        XML structure:

        <ibe:response xmlns:ibe="urn:ietf:params:xml:ns:ibe">
           <ibe:responseType value="responseCode"/>
           <ibe:body>
              bodyTags
           </ibe:body>
        </ibe:response>

        The responseCode describes the type of response from the key server.
        The list of currently defined response codes is:

         100  KEY_FOLLOWS
         101  RESERVED
         201  FOLLOW_ENROLL_URI
         300  SYSTEM_ERROR
         301  INVALID_REQUEST
         303  CLIENT_OBSOLETE
         304  AUTHORIZATION DENIED

     4.6. Response Containing a Private Key

        If the key request was successful, the key server responds with KEY
        FOLLOWS, and the <ibe:body> must contain a <ibe:privateKey> tag with
        a valid private key. An example of this is shown below.

          <ibe:response xmlns:ibe="urn:ietf:params:xml:ns:ibe">
             <ibe:responseType value="100"/>
             <ibe:body>
                <ibe:privateKey>
                  privateKey
                </ibe:privateKey>
             </ibe:body>
          </ibe:response>

        The privateKey is the Base64 [B64] encoding of the DER encoding of
        the following ASN.1 structure:

        IBEPrivateKeyReply ::= SEQUENCE {
           pkgIdentity    IBEIdentityInfo,
           pgkAlgorithm   OBJECT IDENTIFIER
           pkgKeyData     OCTET STRING
           pkgOptions     SEQUENCE OF Extensions
        }

        The pkgIdentity is an IBEIdentityInfo structure as defined in
        [IBECMS]. It MUST be identical to the IBEIdentityInfo structure that
        was sent in the key request.

        The pkgAlgorithm is an OID that identifies the algorithm of the
        returned private key. The OIDs for the BB and BF algorithms are
        defined in [IBCS].

        The pkgKeyData is an ASN.1 structure that contains the actual private
        key. Private-key formats for the BB and BF algorithms are defined in
        [IBCS].

        A server MAY pass back additional information to a client in the
        pkgOptions structure. The contents of the structure are defined in
        the ASN.1 module below.

     4.7. Responses Containing a Redirect

        A Key Server MAY support authenticating user to external
        authentication mechanism. If this is the case, the server replies to
        the client with response code 201 and the body MUST contain a
        <ibe:location> element that specifies the URI of the authentication
        mechanism. An example is shown below.

        <ibe:response xmlns:ibe="urn:ietf:params:xml:ns:ibe">
           <ibe:responseType value="201"/>
           <ibe:body>
              <ibe:location URI="http://www.example.com/enroll.asp"/>
           </ibe:body>
        </ibe:response>

        The client can now contact the authentication mechanism to obtain
        authentication credentials. Once the client has obtained the
        credential, it sends a new key request to the PKG with the correct
        authentication credentials contained in the request.

     4.8. Responses Indicating an Error

        If the server replies with a 3xx error code, the client MUST abort
        the request and discard any data that is part of the response.

        The meaning of the response codes for errors is as follows:

        300 - This indicates an internal server error of the PKG.

        301 - The request to the server is invalid or the server is not able
        to fulfill this type of request.

        303 - The server is not able to serve key requests for this type of
        client. A client with a newer version of the protocol is required.

        304 - The key request was processed correctly, but the authentication
        credentials provided by the user were invalid, could not be verified,
        or do not allow access to keys for this identity.

     5. ASN.1 Module

        IBE1-module { joint-iso-itu(2) country(16) us(840) organization(1)
          identicrypt(114334) ibcs(1) cms(4) module(5) version(1)
        }

        DEFINITIONS IMPLICIT TAGS ::= BEGIN

        IBEOtherRecipientInfo ::= SEQUENCE {
          oriType  OBJECT IDENTIFIER,
          oriValue IBERecipientInfo
        }

        ibeORIType OBJECT IDENTIFIER ::= { joint-iso-itu(2) country(16)
          us(840) organization(1) identicrypt(114334) ibcs(1)
          cms(4) ori-oid(1)
        }

        IBERecipientInfo ::= SEQUENCE {
          cmsVersion         INTEGER { v0(0) },
          keyFetchMethod     OBJECT IDENTIFIER,
          recipientIdentity  IBEIdentityInfo,
          serverInfo         SEQUENCE OF OIDValuePairs OPTIONAL,
          encryptedKey       EncryptedKey
        }

        IBEIdentityInfo ::= SEQUENCE {
          District        UTF8STRING,
          Serial          INTEGER,
          identitySchema  OBJECT IDENTIFIER,
          identityData    OCTET STRING
        }

        OIDValuePairs ::= SEQUENCE {
          fieldID      OBJECT IDENTIFIER,
          fieldData    OCTET STRING
        }

        EmailIdentitySchema ::= SEQUENCE {
          rfc822Email  UTF8STRING,
          time         GeneralizedTime
        }

        cmsIdentityOID OBJECT IDENTIFIER ::= { joint-iso-itu(2) country(16)
          us(840) organization(1) identicrypt(114334) keyschemas(2)
          icschemas(1) rfc822email(1)
        }
        cmsPPSOID OBJECT IDENTIFIER ::= { joint-iso-itu(2) country(16)
          us(840) organization(1) identicrypt(114334) pps-schemas(3)
          ic-schemas(1) pps-uri(1)
        }

        ibcs OBJECT IDENTIFIER ::= {
          joint-iso-itu(2) country(16) us(840) organization(1)
          identicrypt(114334) ibcs(1)
        }

        -- The IBE System parameters consist of a set of public parameters
        -- for the encryption algorithms supported by the district,
        -- the identity schema, the URI of the PKG and further optional
        -- parameters

        IBESysParams ::= SEQUENCE {
          Version              INTEGER { v2(2) },
          districtName         UTF8String,
          districtSerial       INTEGER,
          validity             Validity,
          ibePublicParameters  IBEPublicParameters,
          ibeIdentitySchema    OBJECT IDENTIFIER,
          ibeParamExtensions   IBEParamExtensions
        }

        -- Validity designates the time interval for which these parameters
        -- are valid.

        Validity ::= SEQUENCE {
          notBefore     GeneralizedTime,
          notAfter      GeneralizedTime
        }

        -- Public Parameters for the IBE Algorithm
        --   ibeAlgorithm is the algorithm OID from IBCS, e.g. "bb" or "bf"
        --   publicParameterData is a DER encoded ASN.1 public parameter
        --   block, e.g. BFPublicParamaters, BBPublicParamaters

        IBEPublicParameters ::= SEQUENCE OF IBEPublicParameter

        IBEPublicParameter  ::= SEQUENCE {
          ibeAlgorithm         OBJECT IDENTIFIER,
          publicParameterData  OCTET STRING
        }

        IBEParamExtensions ::= SEQUENCE OF IBEParamExtension
        IBEParamExtension ::= SEQUENCE {
          ibeParamExtensionOID     OBJECT IDENTIFIER,
          ibeParamExtensionValue   OCTET STRING
        }

        ibeParamExt OBJECT IDENTIFIER ::= {
          ibcs ibcs3(3) parameter-extensions(2)
        }

        -- Defined Extensions:
        -- pkgURI: URI of the PKG, value is a UTF8String

        pkgURI OBJECT IDENTIFIER ::= { ibeParamExt pkgURI(1) }

        -- Private Key Format

        IBEPrivateKeyReply ::= SEQUENCE {
          pkgIdentity    IBEIdentityInfo,
          pgkKeyType     OBJECT IDENTIFIER,
          pkgKeyData     OCTET STRING,
          pkgOptions     IBEParamExtensions
        }

        END

     6. Security Considerations

     6.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, 80-bit, 112-bit security and
        128-bit security. encryption strength. We assume that competent capable 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 adversary the ability to access or change the
        information on a PPS or PKG, especially the cryptographic material, material
        (referred to in this document as the master secret), will defeat the
        security of an IBE system. In particular, if the cryptographic
        material is compromised the adversary will have the ability to
        recreate any user's private key and therefore decrypt all messages
        protected with the corresponding public key. To address this concern, the
        it is highly RECOMMENDED that best practices for physical and
        operational security for PPS and PKG servers SHOULD be followed and that
        these servers be configured (sometimes known as hardened) in
        accordance with best current practices [NIST]. An IBE system should SHOULD
        be operated in an environment where such 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
        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.

     6.2. Attacks that are within the scope of this document

        Attacks within the scope of this document are those that allow an
        adversary to:

              o  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

              o  masquerade as a PPS or PKG are also within the scope of this document.

          6.3.

              o  perform a DOS attack on a PPS or PKG

              o  easily guess an IBE users authentication credential

     6.2.1. Attacks that to which the protocols defined in this document are
        susceptible to

        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
        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 protocols defined in this document do not explicitly defend
        against an attacker masquerading as a legitimate IBE PPS or PKG. To The
        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, client software that
        implements the protocols defined in this document SHOULD have a possibility by providing
        user interface capabilities that allows users to view the details of connections visually determine
        that a connection to PPS and PKG servers so 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.

          6.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 TLS 1.1 [TLS] or SSL 3.0 [SSL], which should
        provide an adequate level of protection for such communications.

        The IBE user authentication method used selected by an IBE PKG should also SHOULD be
        sufficiently strong
        of sufficient strength to prevent attackers from easily guessing them the
        IBE user's authentication credentials through trial and error.

     7. IANA Considerations

        The XML defined in this document will be registered with the IANA per
        the instructions in RFC 3688, The IETF XML Registry.

        URI:

        urn:ietf:params:xml:ns:ibe

        Registrant Contact:

           Mark Schertler
           Voltage Security
           1070 Arastradero Rd Suite 100
           Palo Alto CA 94304

           Phone: +1 650 543 1280
           Email: mark@voltage.com

        XML:

        BEGIN
        <ibe:request xmlns:ibe="urn:ietf:params:xml:ns:ibe">
           <ibe:header>
              <ibe:client version="clientID"/>
           </ibe:header>
           <ibe:body>
           <ibe:keyRequest>
              <ibe:algorithm>
                <oid> algorithmOID </oid>
              </ibe:algorithm>
              <ibe:id>
              ibeIdentityInfo
              </ibe:id>
           </ibe:keyRequest>
           </ibe:body>
        </ibe:request>

        <ibe:response xmlns:ibe="urn:ietf:params:xml:ns:ibe">
           <ibe:responseType value="responseCode"/>
           <ibe:body>
              bodyTags
           </ibe:body>
        </ibe:response>
        END

     8. References

     8.1. Normative References

        [AUTH] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
              Leach, P., Luotonen, A., Sink, E. and L. Stewart, "HTTP
              Authentication: Basic and Digest Access Authentication", RFC
              2617, June 1999.

        [B64] N. Freed, N. Borenstein, Multipurpose Internet Mail
              Extensions(MIME) Part One: Format of Internet Message Bodies,"
              RFC 2045, November 1996.

        [CMS] R. Housley, "Cryptographic Message Syntax," RFC 3369, August
              2002.

        [DER] ITU-T Recommendation X.680: Information Technology - Abstract
              Syntax Notation One, 1997.

        [DOM] P. Mockapetris, "Domain Names - Implementation and
              Specification," RFC 1035, November 1987.

        [HTTP] Fielding, R., Gettys, J., Mogul, J., Frysyk, H., Masinter, L.,
              Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
              HTTP/1.1", RFC 2616, June 1999.

        [IBCS] X. Boyen, L. Martin, "Identity-Based Cryptography Standard
              (IBCS) #1: Supersingular Curve Implementations of the BF and
              BB1 Cryptosystems," draft-ietf-martin-ibcs-00.txt, September
              2006.

        [IBECMS] L. Martin, M. Schertler, "Using the Boneh-Franklin identity-
              based encryption algorithm with the Cryptographic Message
              Syntax (CMS)," draft-ietf-smime-bfibecms-01.txt, September
              2006.

        [KEY] S. Brander, "Key Words for Use in RFCs to Indicate 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.

        [P1363] IEEE P1363, "Standards Specifications for Public-Key
              Cryptography," 2001.

        [RFC2818] E. Rescorla, "HTTP over TLS," RFC 2818, May 2000.

        [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.

        [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 (TLS)
              Protocol Version 1.1," RFC 4346, April 2006.

        [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifiers (URI): Generic Syntax", RFC 2396, August
              1998.

     Authors' Addresses

        Guido Appenzeller
        Voltage Security
        1070 Arastradero Rd Suite 100
        Palo Alto CA 94304

        Phone: +1 650 543 1280
        Email: guido@voltage.com

        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
        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 SOCIETY, THE IETF TRUST 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). The IETF Trust (2007).

        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.