G. Appenzeller
                                                             L. Martin
     S/MIME Working Group                             Voltage Security
     Internet Draft                                       M. Schertler
     Expires: January 2008                   Tumbleweed Communications
                                                             July 2007
     
                    Identity-based Encryption Architecture
     
     
                      <draft-ietf-smime-ibearch-04.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 to generate their public
     key.
     
     
     
     
     
     
     
     
     Appenzeller, et al.      Expires January 2008            [Page 1]


     Internet-Draft             IBE Architecture             July 2007
     
     
     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 Public Parameters    5
              2.2.2. Construct and Send IBE-encrypts Message         6
           2.3. Receiving and Viewing an IBE-encrypted Message       6
              2.3.1. Recipient Obtains Public Parameters from PPS    7
              2.3.2. Recipient Obtains IBE Private Key from PKG      8
              2.3.3. Recipient Decrypts IBE-encrypted Message        8
        3. Public Parameter Lookup                                   9
           3.1. Request Method                                      10
           3.2. Parameter and Policy Format                         10
        4. Private Key Request Protocol                             13
           4.1. Overview                                            13
           4.2. Private Key Request                                 13
           4.3. Request Structure                                   14
           4.4. Authentication                                      15
           4.5. Server Response Format                              15
           4.6. Response Containing a Private Key                   16
           4.7. Responses Containing a Redirect                     17
           4.8. Responses Indicating an Error                       17
        5. Security Considerations                                  18
           5.1. Attacks that are outside the scope of this document 18
           5.2. Attacks that are within the scope of this document  19
              5.2.1. Attacks to which the protocols defined in this
              document are susceptible                              19
        6. IANA Considerations                                      20
        7. References                                               21
           7.1. Normative References                                21
        Authors' Addresses                                          23
        Intellectual Property Statement                             23
        Disclaimer of Validity                                      24
        Copyright Statement                                         24
        Acknowledgment                                              24
     
     
     
     
     
     
     
     
     
     
     Appenzeller, et al.      Expires January 2008            [Page 2]


     Internet-Draft             IBE Architecture             July 2007
     
     
     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 a public key to be calculated from an
        identity and the corresponding private key to be calculated
        from the public key. A public key can be calculated by anyone
        who has the necessary mathematical parameters that are needed
        for the calculation; a cryptographic secret is needed to
        calculate a private key, and the calculation can only be
        performed by a trusted server which has this secret.
     
        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 and distributed
        prior to secure communication commencing. The ability to
        calculate a recipient's public key, in particular, eliminates
        the need for the sender and receiver in an IBE-based messaging
        system to interact with each other, either directly or through
        a proxy such as a directory server, before sending secure
        messages.
     
        This document describes an IBE-based messaging system and how
        the components of the system work together. The components
        required for a complete IBE messaging system are the
        following:
     
     
     
     
     
     
     
     
     Appenzeller, et al.      Expires January 2008            [Page 3]


     Internet-Draft             IBE Architecture             July 2007
     
     
              o  A Private-key Generator (PKG). The PKG contains the
                 cryptographic material, known as a master secret, for
                 generating an individual's IBE private key. A PKG
                 accepts an IBE user's private key request and after
                 successfully authenticating them in some way returns
                 the IBE private key.
     
              o  A Public Parameter Server (PPS). IBE System
                 Parameters include publicly sharable cryptographic
                 material, known as IBE public parameters, and policy
                 information for the PKG. A PPS provides a well-known
                 location for secure distribution of IBE public
                 parameters and policy information for the IBE PKG.
     
        A logical architecture would be to have a PKG/PPS per a name
        space, such as a DNS zone. The organization that controls the
        DNS zone would also control the PKG/PPS and thus the
        determination of which PKG/PSS to use when creating public and
        private keys for the organization's members. In this case the
        PPS URI can be uniquely created by the form of the identity
        that it supports. This architecture would make it clear which
        set of public parameters to use and where to retrieve them for
        a given identity (i.e. an RFC822 address).
     
        IBE encrypted messages can use standard message formats, such
        as the Cryptographic Message Syntax [CMS]. How to use IBE with
        CMS is defined in [IBECMS]. Unless explicitly noted otherwise,
        all ASN.1 [DER] structures in this document are defined in the
        ASN.1 module of [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 Message that is Encrypted Using IBE
     
        In order to send an encrypted message, an IBE user must
        perform the following steps:
     
           1. Obtain the recipient's public parameters
     
              The recipient's IBE public parameters allow the creation
              of unique public and private keys. A user of an IBE
              system is capable of calculating the public key of a
              recipient after he obtains the public parameters for
              their IBE system. Once the public parameters are
              obtained, IBE-encrypted messages can be sent.
     
     
     Appenzeller, et al.      Expires January 2008            [Page 4]


     Internet-Draft             IBE Architecture             July 2007
     
     
           2. Construct and Send IBE-encrypted Message
     
              All that is needed, in addition to the IBE public
              parameters, is the recipient's identity in order to
              generate their public key for use in encrypting messages
              to them. When this identity is the same as the identity
              that a message would be addressed to, then no more
              information is needed from a user to send someone a
              secure message then is 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 Public Parameters
     
        The sender of a message obtains the IBE public parameters that
        he needs for calculating the IBE public key of the 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 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] 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                                PPS
                    <-----------------------------
                         IBE Public Parameters
     
                  Figure 1 Requesting IBE Public Parameters
     
     
     
     
     
     
     
     
     
     
     Appenzeller, et al.      Expires January 2008            [Page 5]


     Internet-Draft             IBE Architecture             July 2007
     
     
        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.
     
     2.2.2. Construct and Send IBE-encrypts Message
     
        To IBE-encrypt a message, the sender chooses a content-
        encryption key 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
     
        In order to read an encrypted message, a recipient of an IBE-
        encrypted message parses the message as described in [IBECMS].
        This gives him the URI he 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 provide the
     
     
     
     Appenzeller, et al.      Expires January 2008            [Page 6]


     Internet-Draft             IBE Architecture             July 2007
     
     
              URI of the PKG where the recipient of an IBE-encrypted
              message can obtain the IBE private keys.
     
           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 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 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                                PPS
                       <-----------------------------
                            IBE Public Parameters
     
                  Figure 3 Requesting IBE Public Parameters
     
     
     
     
     
     
     Appenzeller, et al.      Expires January 2008            [Page 7]


     Internet-Draft             IBE Architecture             July 2007
     
     
     2.3.2. Recipient Obtains IBE Private Key from PKG
     
        To obtain an IBE private key, the recipient of an IBE-
        encrypted message provides 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. 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] or its successors, using the latest
        version supported by both parties, 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
     
     
     
     
     
     
     Appenzeller, et al.      Expires January 2008            [Page 8]


     Internet-Draft             IBE Architecture             July 2007
     
     
     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.
     
     
     
     
     
     Appenzeller, et al.      Expires January 2008            [Page 9]


     Internet-Draft             IBE Architecture             July 2007
     
     
     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.pp
     
        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] or its successors and SHOULD use the
        latest version supported by both parties. When requesting the
        URI the client MUST only accept the system parameter block if
        the server identity was verified successfully by TLS 1.1 [TLS]
        or its successors.
     
        A successful GET request returns in its body the Base64
        encoding of the DER-encoded [DER] IBESysParams structure that
        is described in the next section. This structure MUST be
        served as an application/octet-stream MIME type [RFC2046].
     
     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             ValidityPeriod,
           ibePublicParameters  IBEPublicParameters,
           ibeIdentitySchema    OBJECT IDENTIFIER,
           ibeParamExtensions   IBEParamExtensions OPTIONAL
        }
     
        The version specifies the version of the IBESysParams format.
        For the format described in this document it MUST be set to 2.
        The district name is 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.
     
     
     Appenzeller, et al.      Expires January 2008           [Page 10]


     Internet-Draft             IBE Architecture             July 2007
     
     
        The validity 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 falls between the notBefore time and the
        notAfter times of the IBE system parameters and SHOULD not use
        the parameters if they 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 (1..MAX) OF
        IBEPublicParameter
     
        IBEPublicParameter  ::= SEQUENCE {
          ibeAlgorithm          OBJECT IDENTIFIER,
          publicParameterData   OCTET STRING
        }
     
        The ibeAlgorithm OID specifies an IBE algorithm. The
        publicParameterData is a DER-encoded [DER] 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].
     
     
     
     
     Appenzeller, et al.      Expires January 2008           [Page 11]


     Internet-Draft             IBE Architecture             July 2007
     
     
        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-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.
     
     
     
     
     
     
     
     
     
     
     
     
     
     Appenzeller, et al.      Expires January 2008           [Page 12]


     Internet-Draft             IBE Architecture             July 2007
     
     
        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] or
        its successors, using the latest version supported by both the
        client and the PKG. 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
     
     
     Appenzeller, et al.      Expires January 2008           [Page 13]


     Internet-Draft             IBE Architecture             July 2007
     
     
        connection fails. Doing so is critical to protect the
        authentication credentials and the private key against 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 that MUST be encoded as an application/xhtml+xml
        MIME type [RFC3236]:
     
        <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, an
        ASCII string 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 [DER] of the ASN.1 structure
        IBEIdentityInfo as defined in [IBECMS].
     
        A key request MUST contain a <ibe:algorithmOID> element that
        contains a XER [XER] encoded ASN.1 OBJECT IDENTIFIER [DER]
        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.
     
     
     
     
     
     Appenzeller, et al.      Expires January 2008           [Page 14]


     Internet-Draft             IBE Architecture             July 2007
     
     
     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 that MUST be encoded as an
        application/xhtml+xml MIME type [RFC3236]:
     
        <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:
     
     
     
     
     
     
     Appenzeller, et al.      Expires January 2008           [Page 15]


     Internet-Draft             IBE Architecture             July 2007
     
     
         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 [DER] 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 [DER] structure that contains the
        actual private key. Private-key formats for the BB and BF
        algorithms are defined in [IBCS].
     
     
     
     
     Appenzeller, et al.      Expires January 2008           [Page 16]


     Internet-Draft             IBE Architecture             July 2007
     
     
        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. Such a response MUST be encoded as
        an application/xhtml+xml MIME type [RFC3236]. An example of
        such a response 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,
     
     
     
     Appenzeller, et al.      Expires January 2008           [Page 17]


     Internet-Draft             IBE Architecture             July 2007
     
     
        could not be verified, or do not allow access to keys for this
        identity.
     
     5. Security Considerations
     
     5.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
        give 80-bit, 112-bit and 128-bit encryption strength. We
        assume that capable administrators of an IBE system will
        select parameters that provide a sufficient resistance to
        cryptanalytic attacks by adversaries.
     
        Attacks that give an adversary the ability to access or change
        the information on a PPS or PKG, especially the cryptographic
        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, it is
        highly RECOMMENDED that best practices for physical and
        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 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.
     
     
     
     
     
     
     Appenzeller, et al.      Expires January 2008           [Page 18]


     Internet-Draft             IBE Architecture             July 2007
     
     
     5.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
     
              o  masquerade as a PPS or PKG
     
              o  perform a DOS attack on a PPS or PKG
     
              o  easily guess an IBE users authentication credential
     
     5.2.1. Attacks to which the protocols defined in this document
        are susceptible
     
        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. 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 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.
     
     
     
     Appenzeller, et al.      Expires January 2008           [Page 19]


     Internet-Draft             IBE Architecture             July 2007
     
     
        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.
     
     6. 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:
     
           Luther Martin
           Voltage Security
           1070 Arastradero Rd Suite 100
           Palo Alto CA 94304
     
           Phone: +1 650 543 1280
           Email: martin@voltage.com
     
        XML:
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     Appenzeller, et al.      Expires January 2008           [Page 20]


     Internet-Draft             IBE Architecture             July 2007
     
     
        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
     
     7. References
     
     7.1. Normative References
     
        [AUTH] J. Franks, et al., "HTTP Authentication: Basic and
              Digest Access Authentication", RFC 2617, June 1999.
     
        [B64] N. Freed and 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] R. Fielding, et al., "Hypertext Transfer Protocol --
              HTTP/1.1", RFC 2616, June 1999.
     
     
     Appenzeller, et al.      Expires January 2008           [Page 21]


     Internet-Draft             IBE Architecture             July 2007
     
     
        [IBCS] X. Boyen and 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 and 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 and 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.
     
        [RFC2046] N. Freed and N. Borenstein, "Multipurpose Internet
              Mail Extensions (MIME) Part Two: Media Types," RFC 2046,
              November 1996.
     
        [RFC2818] E. Rescorla, "HTTP over TLS," RFC 2818, May 2000.
     
        [RFC2827] P. Ferguson and D. Senie, "Network Ingress
              Filtering: Defeating Denial of Service Attacks which
              employ IP Source Address Spoofing," RFC 2827, BCP 38,
              May 2000.
     
        [RFC3236] M. Baker and P. Stark, "The 'application/xhtml+xml'
              Media Type," RFC 3236, January 2002.
     
        [RFC3882] D. Turk, "Configuring BGP to Block Denial-of-Service
              Attacks," RFC 3882, September 2004.
     
        [TLS] T. Dierks and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.1," RFC 4346, April 2006.
     
        [URI] T. Berners-Lee, R. Fielding, and L. Masinter, "Uniform
              Resource Identifiers (URI): Generic Syntax", RFC 2396,
              August 1998.
     
     
     
     
     
     Appenzeller, et al.      Expires January 2008           [Page 22]


     Internet-Draft             IBE Architecture             July 2007
     
     
        [XER] ITU-T Recommendation X.693 - Information Technology -
              ASN.1 Encoding Rules - XML Encoding Rules (XER),
              December 2001.
     
     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
        Tumbleweed Communications
        700 Saginaw Dr
        Redwood City CA 94063
     
        Phone: +1 650 216 2039
        Email: mark.schertler@tumbleweed.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
     
     
     Appenzeller, et al.      Expires January 2008           [Page 23]


     Internet-Draft             IBE Architecture             July 2007
     
     
        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, 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 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.
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     Appenzeller, et al.      Expires January 2008           [Page 24]