G. Appenzeller
                                                        L. Martin
     S/MIME Working Group                        Voltage Security
     Internet Draft                                  M. Schertler
     Expires: March 2008                Tumbleweed Communications
                                                   September 2007
     
                 Identity-based Encryption Architecture
     
     
                    <draft-ietf-smime-ibearch-05.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 March 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 Parameters5
              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 PPS7
              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
           7.2. Informative References.........................22
        Authors' Addresses.....................................24
        Intellectual Property Statement........................24
        Disclaimer of Validity.................................25
        Copyright Statement....................................25
        Acknowledgment.........................................25
     
     
     
     
     
     
     
     Appenzeller, et al.       Expires March 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 March 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 RFC 2822 address [TEXTMSG]).
     
        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
     
     
     Appenzeller, et al.       Expires March 2008        [Page 4]


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


     Internet-Draft             IBE Architecture        July 2007
     
     
              an IBE-encrypted message if he has both the IBE
              public parameters and the necessary IBE private
              key. The PPS can also provide the 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 March 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 March 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 March 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
        [MIME].
     
     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
     
     
     
     Appenzeller, et al.       Expires March 2008       [Page 10]


     Internet-Draft             IBE Architecture        July 2007
     
     
        are published for a district, it MUST be increased to a
        number greater than the previously-used serial number.
     
        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-
     
     
     
     Appenzeller, et al.       Expires March 2008       [Page 11]


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


     Internet-Draft             IBE Architecture        July 2007
     
     
        supported by both the client and the PKG. When requesting
        the URI the client MUST verify the server certificate
        [HTTPTLS], and MUST abort the key request if the server
        certificate verification of the TLS 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 [XHTML]:
     
        <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].
     
     
     
     Appenzeller, et al.       Expires March 2008       [Page 14]


     Internet-Draft             IBE Architecture        July 2007
     
     
        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 that MUST be encoded
        as an application/xhtml+xml MIME type [XHTML]:
     
        <ibe:response xmlns:ibe="urn:ietf:params:xml:ns:ibe">
           <ibe:responseType value="responseCode"/>
           <ibe:body>
              bodyTags
           </ibe:body>
        </ibe:response>
     
     
     
     
     
     Appenzeller, et al.       Expires March 2008       [Page 15]


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


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


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


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


     Internet-Draft             IBE Architecture        July 2007
     
     
        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 [DOS, BGPDOS] that their use of IBE
        requires.
     
        The IBE user authentication method selected by an IBE PKG
        SHOULD be of sufficient strength to prevent attackers
        from easily guessing the IBE user's authentication
        credentials through trial and error.
     
     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 March 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
              3852, July 2004.
     
        [DOM] P. Mockapetris, "Domain Names - Implementation and
              Specification," RFC 1035, November 1987.
     
        [DOS] 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.
     
     
     
     Appenzeller, et al.       Expires March 2008       [Page 21]


     Internet-Draft             IBE Architecture        July 2007
     
     
     
     
        [HTTP] R. Fielding, et al., "Hypertext Transfer Protocol
              -- HTTP/1.1", RFC 2616, June 1999.
     
        [HTTPTLS] E. Rescorla, "HTTP over TLS," RFC 2818, May
              2000.
     
        [KEY] S. Brander, "Key Words for Use in RFCs to Indicate
              Requirement Levels," BCP 14, RFC 2119, March 1997.
     
        [MIME] N. Freed and N. Borenstein, "Multipurpose Internet
              Mail Extensions (MIME) Part Two: Media Types," RFC
              2046, November 1996.
     
        [TEXTMSG] D. Crocker, "Standard for the format of ARPA
                  internet text messages," RFC 2822, April 2001.
     
        [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 3986, January 2005.
     
     7.2. Informative References
     
        [BGPDOS] D. Turk, "Configuring BGP to Block Denial-of-
              Service Attacks," RFC 3882, September 2004.
     
        [DER] ITU-T Recommendation X.680: Information Technology
                  - Abstract Syntax Notation One, 1997.
     
     
     
     
     Appenzeller, et al.       Expires March 2008       [Page 22]


     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-martin-ibcs-06.txt, September
              2007.
     
        [IBECMS] L. Martin and M. Schertler, "Using the Boneh-
              Franklin identity-based encryption algorithm with
              the Cryptographic Message Syntax (CMS)," draft-
              ietf-smime-bfibecms-06.txt, September 2007.
     
        [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.
     
        [XER] ITU-T Recommendation X.693 - Information Technology
              - ASN.1 Encoding Rules - XML Encoding Rules (XER),
              December 2001.
     
        [XHTML] M. Baker and P. Stark, "The
              'application/xhtml+xml' Media Type," RFC 3236,
              January 2002.
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     Appenzeller, et al.       Expires March 2008       [Page 23]


     Internet-Draft             IBE Architecture        July 2007
     
     
     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 this specification can be
        obtained from the IETF on-line IPR repository at
        http://www.ietf.org/ipr.
     
     
     
     Appenzeller, et al.       Expires March 2008       [Page 24]


     Internet-Draft             IBE Architecture        July 2007
     
     
        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 March 2008       [Page 25]