Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 7030

Enrollment over Secure Transport

Pages: 53
Proposed Standard
Errata
Updated by:  89518996
Part 3 of 4 – Pages 25 to 41
First   Prev   Next

Top   ToC   RFC7030 - Page 25   prevText

4. Protocol Exchange Details

Before processing a request, an EST server determines if the client is authorized to receive the requested services. Likewise, the client determines if it will make requests to the EST server. These authorization decisions are described in the next two sections. Assuming that both sides of the exchange are authorized, then the actual operations are as described in subsequent sections.

4.1. Distribution of CA Certificates

The EST client can request a copy of the current CA certificates. This function is generally performed before other EST functions.

4.1.1. Bootstrap Distribution of CA Certificates

It is possible that the client was not configured with an Implicit TA database that allows a bootstrap installation of the Explicit TA database as described in 4.1.3. This section describes an alternate method by which minimally configured EST clients can populate their Explicit TA database. If the EST client application does not specify either an Explicit TA database or an Implicit TA database, then the initial TLS server authentication and authorization will fail. The client MAY provisionally continue the TLS handshake to completion for the purposes of accessing the /cacerts or /fullcmc method. If the EST client continues with an unauthenticated connection, the client MUST extract the HTTP content data from the response (Sections 4.1.3 or 4.3.2) and engage a human user to authorize the CA certificate using out-of-band data such as a CA certificate "fingerprint" (e.g., a SHA-256 or SHA-512 [SHS] hash on the whole CA certificate). In a /fullcmc response, it is the Publish Trust Anchors control (CMC [RFC5272], Section 6.15) within the Full PKI Response that must be accepted manually. It is incumbent on the user to properly verify the TA information, or to provide the "fingerprint" data during configuration that is necessary to verify the TA information. HTTP authentication requests MUST NOT be responded to if the server has not been authenticated as specified in Section 3.3.1 or if the optional certificate-less authentication is used as specified in Section 3.3.3. The EST client uses the /cacerts response to establish an Explicit Trust Anchor database for subsequent TLS authentication of the EST server. EST clients MUST NOT engage in any other protocol exchange
Top   ToC   RFC7030 - Page 26
   until after the /cacerts response has been accepted and a new TLS
   session has been established (using TLS certificate-based
   authentication).

4.1.2. CA Certificates Request

EST clients request the EST CA TA database information of the CA (in the form of certificates) with an HTTPS GET message using an operation path of "/cacerts". EST clients and servers MUST support the /cacerts function. Clients SHOULD request an up-to-date response before stored information has expired in order to ensure the EST CA TA database is up to date. The EST server SHOULD NOT require client authentication or authorization to reply to this request. The client MUST authenticate the EST server, as specified in Section 3.3.1 if certificate-based authentication is used or Section 3.3.3 if the optional certificate-less authentication is used, and check the server's authorization as given in Section 3.6, or follow the procedure outlined in Section 4.1.1.

4.1.3. CA Certificates Response

If successful, the server response MUST have an HTTP 200 response code. Any other response code indicates an error and the client MUST abort the protocol. A successful response MUST be a certs-only CMC Simple PKI Response, as defined in [RFC5272], containing the certificates described in the following paragraph. The HTTP content-type of "application/pkcs7-mime" is used. The Simple PKI Response is sent with a Content-Transfer-Encoding of "base64" [RFC2045]. The EST server MUST include the current root CA certificate in the response. The EST server MUST include any additional certificates the client would need to build a chain from an EST CA-issued certificate to the current EST CA TA. For example, if the EST CA is a subordinate CA, then all the appropriate subordinate CA certificates necessary to build a chain to the root EST CA are included in the response. The EST server SHOULD include the three "Root CA Key Update" certificates OldWithOld, OldWithNew, and NewWithOld in the response chain. These are defined in Section 4.4 of CMP [RFC4210]. The EST client MUST be able to handle these certificates in the response. The EST CA's most recent self-signed certificate (e.g., NewWithNew certificate) is self-signed and has the latest NotAfter date. If the
Top   ToC   RFC7030 - Page 27
   EST server does not include these in the response, then after the
   current EST CA certificate expires, the EST clients will need to be
   reinitialized with the PKI using the Bootstrap Distribution of CA
   certificates (Section 4.1.1) method, which involves user interaction.

   After out-of-band validation occurs, all the other certificates MUST
   be validated using normal [RFC5280] certificate path validation
   (using the most recent CA certificate as the TA) before they can be
   used to build certificate paths during certificate validation.

   The EST client MUST store the extracted EST CA certificate as an
   Explicit TA database entry for subsequent EST server authentication.
   The EST client SHOULD disable use of Implicit TA database entries for
   this EST server now that an Explicit TA database entry is available.
   If the client disables the Implicit TA database, and if the EST
   server certificate was verified using an Implicit TA database entry,
   then the client MUST include the "Trusted CA Indication" extension in
   future TLS sessions [RFC6066].  This indicates to the server that
   only an EST server certificate authenticatable by the Explicit TA
   database entry is now acceptable (otherwise, the EST server might
   continue to use a server certificate that is only verifiable by a now
   disabled Implicit TA).

   The EST client SHOULD also make the CA Certificate response
   information available to the end-entity software for use when
   validating peer certificates.

4.2. Client Certificate Request Functions

EST clients request a certificate from the EST server with an HTTPS POST using the operation path value of "/simpleenroll". EST clients request a renew/rekey of existing certificates with an HTTP POST using the operation path value of "/simplereenroll". EST servers MUST support the /simpleenroll and /simplereenroll functions. It is RECOMMENDED that a client obtain the current CA certificates, as described in Section 4.1, before performing certificate request functions. This ensures that the client will be able to validate the EST server certificate. The client MUST authenticate the EST server as specified in Section 3.3.1 if certificate-based authentication is used or Section 3.3.3 if the optional certificate-less authentication is used. The client MUST verify the authorization of the EST server as specified in Section 3.6. The server MUST authenticate the client as specified in Section 3.3.2 if certificate-based authentication is used or Section 3.3.3 if the optional certificate-less authentication is used. The server MUST verify client authorization as specified in Section 3.7. The EST
Top   ToC   RFC7030 - Page 28
   server MUST check the tls-unique value, as described in Section 3.5,
   if one is submitted by the client.

   The server MAY accept a certificate request for manual authorization
   checking by an administrator.  (Section 4.2.3 describes the use of an
   HTTP 202 response to the EST client if this occurs.)

4.2.1. Simple Enrollment of Clients

When HTTPS POSTing to /simpleenroll, the client MUST include a Simple PKI Request as specified in CMC [RFC5272], Section 3.1 (i.e., a PKCS #10 Certification Request [RFC2986]). The Certification Signing Request (CSR) signature provides proof-of-possession of the client-possessed private key to the EST server. If the CSR KeyUsage extension indicates that the private key can be used to generate digital signatures, then the client MUST generate the CSR signature using the private key. If the key can be used to generate digital signatures but the requested CSR KeyUsage extension prohibits generation of digital signatures, then the CSR signature MAY still be generated using the private key, but the key MUST NOT be used for any other signature operations (this is consistent with the recommendations concerning submission of proof-of-possession to an RA or CA as described in [SP-800-57-Part-1]). The use of /fullcmc operations provides access to more advanced proof-of-possession methods that are used when the key pair cannot be used for digital signature generation (see Section 4.3). The HTTP content-type of "application/pkcs10" is used here. The format of the message is as specified in [RFC5967] with a Content- Transfer-Encoding of "base64" [RFC2045]. If the EST client authenticated using a previously installed certificate issued by a third-party CA (see Section 2.2.1), the client MAY include the ChangeSubjectName attribute, as defined in [RFC6402], in the CSR to request that the subjectName and SubjectAltName be changed in the new certificate. The EST client MAY request additional certificates even when using an existing certificate in the TLS client authentication. For example, the client can use an existing certificate for TLS client authentication when requesting a certificate that cannot be used for TLS client authentication.
Top   ToC   RFC7030 - Page 29

4.2.2. Simple Re-enrollment of Clients

EST clients renew/rekey certificates with an HTTPS POST using the operation path value of "/simplereenroll". A certificate request employs the same format as the "simpleenroll" request, using the same HTTP content-type. The request Subject field and SubjectAltName extension MUST be identical to the corresponding fields in the certificate being renewed/rekeyed. The ChangeSubjectName attribute, as defined in [RFC6402], MAY be included in the CSR to request that these fields be changed in the new certificate. If the Subject Public Key Info in the certification request is the same as the current client certificate, then the EST server renews the client certificate. If the public key information in the certification request is different than the current client certificate, then the EST server rekeys the client certificate.

4.2.3. Simple Enroll and Re-enroll Response

If the enrollment is successful, the server response MUST contain an HTTP 200 response code with a content-type of "application/pkcs7-mime". A successful response MUST be a certs-only CMC Simple PKI Response, as defined in [RFC5272], containing only the certificate that was issued. The HTTP content-type of "application/pkcs7-mime" with an smime-type parameter "certs-only" is used, as specified in [RFC5273]. The server MUST answer with a suitable 4xx or 5xx HTTP [RFC2616] error code when a problem occurs. A Simple PKI Response with an HTTP content-type of "application/pkcs7-mime" (see Section 4.3.2) MAY be included in the response data to convey an error response. If the content-type is not set, the response data MUST be a plaintext human- readable error message containing explanatory information describing why the request was rejected (for example, indicating that CSR attributes are incomplete). If the server responds with an HTTP [RFC2616] 202, this indicates that the request has been accepted for processing but that a response is not yet available. The server MUST include a Retry-After header as defined for HTTP 503 responses. The server also MAY include informative human-readable content. The client MUST wait at least the specified "retry-after" time before repeating the same request. The client repeats the initial enrollment request after the appropriate "retry-after" interval has expired. The client SHOULD log or inform the end-user of this event. The server is responsible
Top   ToC   RFC7030 - Page 30
   for maintaining all states necessary to recognize and handle retry
   operations as the client is stateless in this regard; it simply sends
   the same request repeatedly until it receives a different response
   code.  All other return codes are handled as specified in HTTP
   [RFC2616].

   If the client closes the TLS connections while waiting for the Retry-
   After time to expire, then the client initiates a new TLS connection
   and performs all applicable security checks.  If the client has
   already generated a CSR that includes linking identity and POP
   information (Section 3.5), then the CSR will need to be recreated to
   incorporate the tls-unique from the new, redirected session.  Note:
   the key pair need not be regenerated.  These are processing and
   interface burdens on the client.  EST server administrators are
   advised to take this into consideration.

   The EST client MAY also make the certificate response, and associated
   private key, available to end-entity software for use as an
   end-entity certificate.

4.3. Full CMC

An EST client can request a certificate from an EST server with an HTTPS POST using the operation path value of "/fullcmc". Support for the /fullcmc function is OPTIONAL for both clients and servers.

4.3.1. Full CMC Request

If the HTTP POST to /fullcmc is not a valid Full PKI Request, the server MUST reject the message. The HTTP content-type used is "application/pkcs7-mime" with an smime-type parameter "CMC-request", as specified in [RFC5273]. The body of the message is the binary value of the encoding of the PKI Request with a Content-Transfer-Encoding of "base64" [RFC2045].

4.3.2. Full CMC Response

If the enrollment is successful, the server response MUST include an HTTP 200 response code with a content-type of "application/pkcs7-mime" as specified in [RFC5273]. The response data includes either the Simple PKI Response with an smime-type parameter of "certs-only" or the Full PKI Response with an smime-type parameter "CMC-response", as specified in Section 3.2.1 of [RFC5751]. The body of the message is the binary value of the encoding of the PKI Response with a Content-Transfer-Encoding of "base64" [RFC2045].
Top   ToC   RFC7030 - Page 31
   When rejecting a request, the server MUST specify either an HTTP 4xx
   error or an HTTP 5xx error.  A CMC response with the content-type of
   "application/pkcs7-mime" MUST be included in the response data for
   any CMC error response.

   All other return codes are handled as specified in Section 4.2.3 or
   HTTP [RFC2616].  For example, a client interprets an HTTP 404 or 501
   response to indicate that this service is not implemented.

4.4. Server-Side Key Generation

An EST client may request a private key and associated certificate from an EST server using an HTTPS POST with an operation path value of "/serverkeygen". Support for the /serverkeygen function is OPTIONAL. A client MUST authenticate an EST server, as specified in Section 3.3.1 if certificate-based authentication is used or Section 3.3.3 if the optional certificate-less authentication is used, and check the server's authorization as given in Section 3.6. The EST server MUST authenticate the client, as specified in Section 3.3.2 if certificate-based authenticated is used or Section 3.3.3 if the optional certificate-less authentication is used, and check the client's authorization as given in Section 3.7. The EST server applies whatever authorization or logic it chooses to determine if the private key and certificate should be provided. Cipher suites that have a NULL confidentiality algorithm MUST NOT be used as they will disclose the contents of an unprotected private key. Proper random number and key generation [RFC4086] is a server implementation responsibility, and server archiving of generated keys is determined by CA policy. The key pair and certificate are transferred over the TLS session. The cipher suite used to return the private key and certificate MUST offer confidentiality commensurate with the private key being delivered to the client. The EST client MAY request additional certificates even when using an existing certificate in the TLS client authentication. For example, the client can use an existing certificate for TLS client authentication when requesting a certificate that cannot be used for TLS client authentication.
Top   ToC   RFC7030 - Page 32

4.4.1. Server-Side Key Generation Request

The certificate request is HTTPS POSTed and is the same format as for the "/simpleenroll" and "/simplereenroll" path extensions with the same content-type and transfer encoding. In all respects, the server SHOULD treat the CSR as it would any enroll or re-enroll CSR; the only distinction here is that the server MUST ignore the public key values and signature in the CSR. These are included in the request only to allow re-use of existing codebases for generating and parsing such requests. If the client desires to receive the private key with encryption that exists outside of and in addition to that of the TLS transport used by EST or if server policy requires that the key be delivered in such a form, the client MUST include an attribute in the CSR indicating the encryption key to be used. Both symmetric and asymmetric encryption are supported as described in the following subsections. The client MUST also include an SMIMECapabilities attribute ([RFC2633], Section 2.5) in the CSR to indicate the key encipherment algorithms the client is willing to use. It is strongly RECOMMENDED that the clients request that the returned private key be afforded the additional security of the Cryptographic Message Syntax (CMS) EnvelopedData in addition to the TLS-provided security to protect against unauthorized disclosure.
4.4.1.1. Requests for Symmetric Key Encryption of the Private Key
To specify a symmetric encryption key to be used to encrypt the server-generated private key, the client MUST include a DecryptKeyIdentifier attribute (as defined in Section 2.2.5 of [RFC4108]) specifying the identifier of the secret key to be used by the server to encrypt the private key. While that attribute was originally designated for specifying a firmware encryption key, it exactly mirrors the requirements for specifying a secret key to encrypt a private key. If the server does not have a secret key matching the identifier specified by the client, the request MUST be terminated and an error returned to the client. Distribution of the key specified by the DecryptKeyIdentifier to the key generator and the client is outside the scope of this document.
Top   ToC   RFC7030 - Page 33
4.4.1.2. Requests for Asymmetric Encryption of the Private Key
To specify an asymmetric encryption key to be used to encrypt the server-generated private key, the client MUST include an AsymmetricDecryptKeyIdentifier attribute. The AsymmetricDecryptKeyIdentifier attribute is defined as: id-aa-asymmDecryptKeyID OBJECT IDENTIFIER ::= { id-aa 54 } The asymmetric-decrypt-key-identifier attribute values have ASN.1 type AsymmetricDecryptKeyIdentifier (where ASN.1 is defined in [X.680]):: AsymmetricDecryptKeyIdentifier ::= OCTET STRING If the server does not have a public key matching the identifier specified by the client, the request MUST be terminated and an error returned to the client. Distribution of the key specified by the AsymmetricDecryptKeyIdentifier to the key generator and the client is outside the scope of this document. If the key identified is bound to an X.509 certificate, then the key MUST either explicitly support keyTransport or keyAgreement or its use MUST be unrestricted.

4.4.2. Server-Side Key Generation Response

If the request is successful, the server response MUST have an HTTP 200 response code with a content-type of "multipart/mixed" consisting of two parts: one part is the private key data and the other part is the certificate data. The format in which the private key data part is returned is dependent on whether the private key is being returned with additional encryption on top of that provided by TLS. If additional encryption is not being employed, the private key data MUST be placed in an "application/pkcs8". An "application/pkcs8" part consists of the base64-encoded DER-encoded [X.690] PrivateKeyInfo with a Content-Transfer-Encoding of "base64" [RFC2045]. If additional encryption is being employed, the private key is placed inside of a CMS SignedData. The SignedData is signed by the party that generated the private key, which may or may not be the EST server or the EST CA. The SignedData is further protected by placing it inside of a CMS EnvelopedData, as described in Section 4 of [RFC5958]. The following list shows how the EncryptedData is used, depending on the type of protection key specified by the client.
Top   ToC   RFC7030 - Page 34
   o  If the client specified a symmetric encryption key to protect the
      server-generated private key, the EnvelopedData content is
      encrypted using the secret key identified in the request.  The
      EnvelopedData RecipientInfo field MUST indicate the key-encryption
      kekri key management technique.  The values are as follows:
      version is set to 4, key-encryption key identifier (kekid) is set
      to the value of the DecryptKeyIdentifier from Section 4.4.1.1;
      keyEncryptionAlgorithm is set to one of the key wrap algorithms
      that the client included in the SMIMECapabilities accompanying the
      request; and encryptedKey is the encrypted key.

   o  If the client specified an asymmetric encryption key suitable for
      key transport operations to protect the server-generated private
      key, the EnvelopedData content is encrypted using a randomly
      generated symmetric encryption key.  The cryptographic strength of
      the symmetric encryption key SHOULD be equivalent to the client-
      specified asymmetric key.  The EnvelopedData RecipientInfo field
      MUST indicate the KeyTransRecipientInfo (ktri) key management
      technique.  In KeyTransRecipientInfo, the RecipientIdentifier
      (rid) is either the subjectKeyIdentifier copied from the attribute
      defined in Section 4.4.1.2 or the server determines an associated
      issuerAndSerialNumber from the attribute; version is derived from
      the choice of rid [RFC5652], keyEncryptionAlgorithm is set to one
      of the key wrap algorithms that the client included in the
      SMIMECapabilities accompanying the request, and encryptedKey is
      the encrypted key.

   o  If the client specified an asymmetric encryption key suitable for
      key agreement operations to protect the server-generated private
      key, the EnvelopedData content is encrypted using a randomly
      generated symmetric encryption key.  The cryptographic strength of
      the symmetric encryption key SHOULD be equivalent to the client-
      specified asymmetric key.  The EnvelopedData RecipientInfo field
      MUST indicate the KeyAgreeRecipientInfo (kari) key management
      technique.  In the KeyAgreeRecipientInfo type, version,
      originator, and user keying material (ukm) are as in [RFC5652],
      and keyEncryptionAlgorithm is set to one of the key wrap
      algorithms that the client included in the SMIMECapabilities
      accompanying the request.  The recipient's key identifier is
      either copied from the attribute defined in Section 4.4.1.2 to
      subjectKeyIdentifier or the server determines an
      IssuerAndSerialNumber that corresponds to the value provided in
      the attribute.

   In all three additional encryption cases, the EnvelopedData is
   returned in the response as an "application/pkcs7-mime" part with an
   smime-type parameter of "server-generated-key" and a Content-
   Transfer-Encoding of "base64".
Top   ToC   RFC7030 - Page 35
   The certificate data part is an "application/pkcs7-mime" and exactly
   matches the certificate response to /simpleenroll.

   When rejecting a request, the server MUST specify either an HTTP 4xx
   error or an HTTP 5xx error.  If the content-type is not set, the
   response data MUST be a plaintext human-readable error message.

4.5. CSR Attributes

CA policy may allow inclusion of client-provided attributes in certificates that it issues, and some of these attributes may describe information that is not available to the CA. In addition, a CA may desire to certify a certain type of public key and a client may not have a priori knowledge of that fact. Therefore, clients SHOULD request a list of expected attributes that are required, or desired, by the CA in an enrollment request or if dictated by local policy. The EST server SHOULD NOT require client authentication or authorization to reply to this request. Requesting CSR attributes is optional, but clients are advised that CAs may refuse enrollment requests that are not encoded according to the CA's policy.

4.5.1. CSR Attributes Request

The EST client requests a list of CA-desired CSR attributes from the CA by sending an HTTPS GET message to the EST server with an operations path of "/csrattrs".

4.5.2. CSR Attributes Response

If locally configured policy for an authenticated EST client indicates a CSR Attributes Response is to be provided, the server response MUST include an HTTP 200 response code. An HTTP response code of 204 or 404 indicates that a CSR Attributes Response is not available. Regardless of the response code, the EST server and CA MAY reject any subsequent enrollment requests for any reason, e.g., incomplete CSR attributes in the request.
Top   ToC   RFC7030 - Page 36
   Responses to attribute request messages MUST be encoded as the
   content-type of "application/csrattrs" with a
   Content-Transfer-Encoding of "base64" [RFC2045].  The syntax for
   application/csrattrs body is as follows:

   CsrAttrs ::= SEQUENCE SIZE (0..MAX) OF AttrOrOID

   AttrOrOID ::= CHOICE (oid OBJECT IDENTIFIER, attribute Attribute }

   Attribute { ATTRIBUTE:IOSet } ::= SEQUENCE {
        type   ATTRIBUTE.&id({IOSet}),
        values SET SIZE(1..MAX) OF ATTRIBUTE.&Type({IOSet}{@type}) }

   An EST server includes zero or more OIDs or attributes [RFC2986] that
   it requests the client to use in the certification request.  The
   client MUST ignore any OID or attribute it does not recognize.  When
   the server encodes CSR Attributes as an empty SEQUENCE, it means that
   the server has no specific additional information it desires in a
   client certification request (this is functionally equivalent to an
   HTTP response code of 204 or 404).

   If the CA requires a particular crypto system or use of a particular
   signature scheme (e.g., certification of a public key based on a
   certain elliptic curve, or signing using a certain hash algorithm) it
   MUST provide that information in the CSR Attribute Response.  If an
   EST server requires the linking of identity and POP information (see
   Section 3.5), it MUST include the challengePassword OID in the CSR
   Attributes Response.

   The structure of the CSR Attributes Response SHOULD, to the greatest
   extent possible, reflect the structure of the CSR it is requesting.
   Requests to use a particular signature scheme (e.g. using a
   particular hash function) are represented as an OID to be reflected
   in the SignatureAlgorithm of the CSR.  Requests to use a particular
   crypto system (e.g., certification of a public key based on a certain
   elliptic curve) are represented as an attribute, to be reflected as
   the AlgorithmIdentifier of the SubjectPublicKeyInfo, with a type
   indicating the algorithm and the values indicating the particular
   parameters specific to the algorithm.  Requests for descriptive
   information from the client are made by an attribute, to be
   represented as Attributes of the CSR, with a type indicating the
   [RFC2985] extensionRequest and the values indicating the particular
   attributes desired to be included in the resulting certificate's
   extensions.

   The sequence is Distinguished Encoding Rules (DER) encoded [X.690]
   and then base64 encoded (Section 4 of [RFC4648]).  The resulting text
   forms the application/csrattr body, without headers.
Top   ToC   RFC7030 - Page 37
   For example, if a CA requests a client to submit a certification
   request containing the challengePassword (indicating that linking of
   identity and POP information is requested; see Section 3.5), an
   extensionRequest with the Media Access Control (MAC) address
   ([RFC2307]) of the client, and to use the secp384r1 elliptic curve
   and to sign with the SHA384 hash function.  Then, it takes the
   following:

         OID:        challengePassword (1.2.840.113549.1.9.7)

         Attribute:  type = extensionRequest (1.2.840.113549.1.9.14)
                     value = macAddress (1.3.6.1.1.1.1.22)

         Attribute:  type = id-ecPublicKey (1.2.840.10045.2.1)
                     value = secp384r1 (1.3.132.0.34)

         OID:        ecdsaWithSHA384 (1.2.840.10045.4.3.3)

   and encodes them into an ASN.1 SEQUENCE to produce:

       30 41 06 09 2a 86 48 86 f7 0d 01 09 07 30 12 06 07 2a 86 48 ce 3d
       02 01 31 07 06 05 2b 81 04 00 22 30 16 06 09 2a 86 48 86 f7 0d 01
       09 0e 31 09 06 07 2b 06 01 01 01 01 16 06 08 2a 86 48 ce 3d 04 03
       03

   and then base64 encodes the resulting ASN.1 SEQUENCE to produce:

       MEEGCSqGSIb3DQEJBzASBgcqhkjOPQIBMQcGBSuBBAAiMBYGCSqGSIb3DQEJDjEJ
       BgcrBgEBAQEWBggqhkjOPQQDAw==

5. IANA Considerations

Section 4.4.1.2 defines an OID that has been registered in an arc delegated by the IANA to the PKIX working group. IANA has registered the following: IANA updated the well-known URI registry with the following filled-in template from [RFC5785]. URI suffix: est Change controller: IETF
Top   ToC   RFC7030 - Page 38
   IANA has updated the "Application Media Types" registry with the
   following filled-in templates from [RFC6838].

   The media subtype for CSR attributes in a CSR Attributes Response is
   application/csrattrs.

       Type name: application

       Subtype name: csrattrs

       Required parameters: None

       Optional parameters: None

       Encoding considerations: binary;

       Security Considerations:

         Clients request a list of attributes that servers wish to be in
         certification requests.  The request/response is normally done
         in a TLS-protected tunnel.

       Interoperability considerations: None

       Published specification: This memo.

       Applications which use this media type: Enrollment over Secure
       Transport (EST)

       Additional information:

         Magic number(s): None

         File extension: .csrattrs

       Person & email address to contact for further information:

         Dan Harkins <dharkins@arubanetworks.com>

       Restrictions on usage: None

       Author: Dan Harkins <dharkins@arubanetworks.com>

       Intended usage: COMMON

       Change controller: The IESG <iesg@ietf.org>
Top   ToC   RFC7030 - Page 39
   The application/pkcs7-mime content-type defines the optional
   "smime-type" parameter [RFC5751] with a set of specific values.  This
   document adds another value, "server-generated-key", as the parameter
   value for Server-side Key Generation Response.

6. Security Considerations

Support for Basic authentication, as specified in HTTP [RFC2617], allows the server access to a client's cleartext password. This provides support for legacy username/password databases but requires exposing the plaintext password to the EST server. Use of a PIN or one-time password can help mitigate such exposure, but it is RECOMMENDED that EST clients use such credentials only once to obtain a client certificate (that will be used during future interactions with the EST server). When a client uses the Implicit TA database for certificate validation (see Section 3), then authorization proceeds as specified in Section 3.6.2. In this situation, the client has validated the server as being a responder that is certified by a third party for the URI configured, but it cannot verify that the responder is authorized to act as an RA for the PKI in which the client is trying to enroll. Clients using an Implicit Trust Anchor database are RECOMMENDED to use only TLS-based client authentication (to prevent exposing HTTP-based client authentication information). It is RECOMMENDED that such clients include "Linking Identity and POP Information" (Section 3.5) in requests (to prevent such requests from being forwarded to a real EST server by a man in the middle). It is RECOMMENDED that the Implicit Trust Anchor database used for EST server authentication be carefully managed to reduce the chance of a third-party CA with poor certification practices from being trusted. Disabling the Implicit Trust Anchor database after successfully receiving the Distribution of CA certificates response (Section 4.1.3) limits any vulnerability to the first TLS exchange. Certificate-less TLS cipher suites that maintain security and perform the mutual authentication necessary for enrollment have the following properties: o the only information leaked by an active attack is whether or not a single guess of the secret is correct. o any advantage an adversary gains is through interaction and not computation. o it is possible to perform countermeasures, such as exponential backoff after a certain number of failed attempts, to frustrate repeated active attacks.
Top   ToC   RFC7030 - Page 40
   Using a certificate-less cipher suite that does not have the
   properties listed above would render the results of enrollment void
   and potentially result in certificates being issued to
   unauthenticated and/or unauthorized entities.

   When using a certificate-less TLS cipher suite, the shared secret
   used for authentication and authorization cannot be shared with an
   entity that is not a party to the exchange: someone other than the
   client and the server.  Any additional sharing of secrets voids the
   security afforded by a certificate-less cipher suite.  Exposure of a
   shared secret used by a certificate-less cipher suite to a third
   party enables client impersonation that can result in corruption of a
   client's trust anchor database.

   TLS cipher suites that include "_EXPORT_" and "_DES_" in their names
   MUST NOT be used.  These ciphers do not offer a sufficient level of
   protection; 40-bit crypto in 2013 doesn't offer acceptable
   protection, and the use of DES is deprecated.

   As described in CMC, Section 6.7 of [RFC5272], "For keys that can be
   used as signature keys, signing the certification request with the
   private key serves as a POP on that key pair".  The inclusion of tls-
   unique within the certification request links the proof-of-possession
   to the TLS proof-of-identity by enforcing that the POP operation
   occurred while the TLS session was active.  This implies to the
   server that the authenticated client currently has access to the
   private key.  If the authenticated client is known to have specific
   capabilities, such as hardware protection for authentication
   credentials and key storage, this implication is strengthened but not
   proven.

   The server-side key generation method allows keys to be transported
   over the TLS connection to the client without any application-layer
   protection.  The distribution of private key material is inherently
   risky.  Private key distribution uses the encryption mode of the
   negotiated TLS cipher suite.  Keys are not protected by preferred key
   wrapping methods such as AES Key Wrap [RFC3394] or as specified in
   [RFC5958] as encryption of the private key beyond that provided by
   TLS is optional.  It is RECOMMENDED that EST servers not support this
   operation by default.  It is RECOMMENDED that clients not request
   this service unless there is a compelling operational benefit.  Use
   of an Implicit Trust Anchor database is NOT RECOMMENDED when
   server-side key generation is employed.  The use of an encrypted CMS
   Server-Side Key Generation Response is RECOMMENDED.

   Regarding the CSR attributes that the CA may list for inclusion in an
   enrollment request, there are no real inherent security issues with
   the content being conveyed, but an adversary who is able to interpose
Top   ToC   RFC7030 - Page 41
   herself into the conversation could exclude attributes that a server
   may want, include attributes that a server may not want, and render
   meaningless other attributes that a server may want.

   ASN.1 encoding rules (e.g., DER and BER) have a type-length-value
   structure, and it is easy to construct malicious content with invalid
   length fields that can cause buffer overrun conditions.  ASN.1
   encoding rules allow for arbitrary levels of nesting, which may make
   it possible to construct malicious content that will cause a stack
   overflow.  Interpreters of ASN.1 structures should be aware of these
   issues and should take appropriate measures to guard against buffer
   overflows and stack overruns in particular, and malicious content in
   general.



(page 41 continued on part 4)

Next Section