Nonce-based Freshness for Remote Attestation in Certificate Signing Requests (CSRs) for the Certification Management Protocol (CMP) and for Enrollment over Secure Transport (EST)
draft-tschofenig-lamps-nonce-cmp-est-01

LAMPS                                                      H. Tschofenig
Internet-Draft                                              H. Brockhaus
Intended status: Standards Track                                 Siemens
Expires: 3 September 2024                                   2 March 2024

  Nonce-based Freshness for Remote Attestation in Certificate Signing
Requests (CSRs) for the Certification Management Protocol (CMP) and for
                 Enrollment over Secure Transport (EST)
                draft-tschofenig-lamps-nonce-cmp-est-01

Abstract

   Certificate Management Protocol (CMP) and Enrollment over Secure
   Transport (EST) define protocol messages for X.509v3 certificate
   creation and management.  Both protocol provide interactions between
   client systems and PKI management entities, such as a Registration
   Authority (RA) and a Certification Authority (CA).

   CMP and EST allow an RA/CA to request additional information it has
   to provide in a certification request.  When an end entity places
   attestation Evidence in a Certificate Signing Request (CSR) it may
   need to demonstrate freshness of the provided Evidence.  Attestation
   technology today often accomplishes this task via the help of nonces.

   This document specifies how nonces are provided by an RA/CA to the
   end entity for inclusion in Evidence.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on 3 September 2024.

Tschofenig & Brockhaus  Expires 3 September 2024                [Page 1]
Internet-Draft         Nonce Extension for CMP/EST            March 2024

Copyright Notice

   Copyright (c) 2024 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology and Requirements Language . . . . . . . . . . . .   4
   3.  Conveying a Nonce in CMP  . . . . . . . . . . . . . . . . . .   5
   4.  Conveying a Nonce in EST  . . . . . . . . . . . . . . . . . .   6
   5.  Nonce Processing Guidelines . . . . . . . . . . . . . . . . .   8
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  11
   Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   Several protocols have been standardized to automate the management
   of certificates, such as certificate issuance, CA certificate
   provisioning, certificate renewal and certificate revocation.

   The Certificate Management Protocol (CMP) [I-D.ietf-lamps-rfc4210bis]
   defines protocol messages for X.509v3 certificate creation and
   management.  CMP provides interactions between end entities and PKI
   components, such as a Registration Authority (RA) and a Certification
   Authority (CA).

   Enrollment over Secure Transport (EST) [RFC7030][RFC8295] is another
   certificate management protocol, which provides a sub-set of the
   features offered by CMP.

   An end entity requesting a certificate from a Certification Authority
   (CA) may wish to offer believable claims about the protections
   afforded to the corresponding private key, such as whether the

Tschofenig & Brockhaus  Expires 3 September 2024                [Page 2]
Internet-Draft         Nonce Extension for CMP/EST            March 2024

   private key resides on a hardware security module or the protection
   capabilities provided by the hardware, and claims about the platform
   itself.

   To convey these claims in Evidence, as part of remote attestation,
   the remote attestation extension [I-D.ietf-lamps-csr-attestation] has
   been defined.  It describes how to encode Evidence produced by an
   Attester for inclusion in Certificate Signing Requests (CSRs), and
   any certificates necessary for validating it.

   A Verifier or Relying Party might need to learn the point in time an
   Evidence has been produced.  This is essential in deciding whether
   the included Claims can be considered fresh, meaning they still
   reflect the latest state of the Attester.

   Attestation technology available today, such as [TPM20] and
   [I-D.tschofenig-rats-psa-token], often accomplish freshness with the
   help of nonces.  More details about ensuring freshness of Evidence
   can be found in Section 10 of [RFC9334].

   Since an end entity needs to obtain a nonce from the Verifier via the
   Relying Party, this leads to an additional roundtrip.  The CSR is,
   however, a one-shot message.  For this reason CMP and EST are used by
   the end entity to obtain the nonce from the RA/CA.

   CMP and EST conveniently offer a mechanism to request information
   from the RA/CA prior to a certification request.

   Once the nonce is obtained the end entity can issue an API call to
   the Attester to request Evidence and passes the nonce as an input
   parameter into the API call.  The returned Evidence is then embedded
   into a CSR and returned to the RA/CA in a certification request
   message.

   Figure 1 shows this interaction graphically.  The nonce is obtained
   in step (1) using the extension to CMP/EST defined in this document.
   The CSR extension of [I-D.ietf-lamps-csr-attestation] is used to
   convey Evidence to the RA/CA in step (2).  The Verifier processes the
   received information and returns an Attestation Result to the Relying
   Party in step (3).

Tschofenig & Brockhaus  Expires 3 September 2024                [Page 3]
Internet-Draft         Nonce Extension for CMP/EST            March 2024

                                 .---------------.
                                 |               |
                                 |   Verifier    |
                                 |               |
                                 '---------------'
                                      |    ^  |    (3)
                                      |    |  | Attestation
                                      |    |  |   Result
                       (1)            |    |  v
    .------------.   Nonce in    .----|----|-----.
    |            |   CMP or EST  |    |    |     |
    |  End       |<-------------------+    |     |
    |  Entity    |               |         |     |
    |    ^       |-------------->|---------'     |
    |    |       |   Evidence    | Relying       |
    |    v       |   in CSR      | Party (RA/CA) |
    |  Attester  |     (2)       |               |
    |            |               |               |
    '------------'               '---------------'

            Figure 1: Architecture with Background Check Model.

   The functionality of this document is described in two sections,
   namely:

   *  Section 3 describes how to convey the nonce CMP, and

   *  Section 4 offers the equivalent functionality for EST.

2.  Terminology and Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

   The terms Attester, Relying Party, Verifier and Evidence are defined
   in [RFC9334].  The terms end entity, certification authority (CA),
   and registration authority (RA) are defined in [RFC5280].

   We use the terms Certificate Signing Request (CSR) and certification
   request interchangeably.

Tschofenig & Brockhaus  Expires 3 September 2024                [Page 4]
Internet-Draft         Nonce Extension for CMP/EST            March 2024

3.  Conveying a Nonce in CMP

   Section 5.3.19.16 of [I-D.ietf-lamps-rfc4210bis] defines the general
   request message (genm) and general response (genp).  The NonceRequest
   payload of the genm message, which is send by the end entity to
   request a nonce, contains optional details on the length of nonce the
   Attester requires.  The NonceResponse payload of the genp message,
   which is sent by the CA/RA in response to a request message by the
   end entity, contains the nonce.

    GenMsg:    {id-it TBD1}, NonceRequestValue
    GenRep:    {id-it TBD2}, NonceResponseValue | < absent >

    id-it-NonceRequest OBJECT IDENTIFIER ::= { id-it TBD1 }
    NonceRequestValue ::= SEQUENCE {
       len INTEGER OPTIONAL,
       -- indicates the required length of the requested nonce
       hint EvidenceHint OPTIONAL
       -- indicates which Verifier to request a nonce from
    }

    id-it-NonceResponse OBJECT IDENTIFIER ::= { id-it TBD2 }
    NonceResponseValue ::= SEQUENCE {
       nonce OCTET STRING
       -- contains the nonce of length len
       -- provided by the Verifier indicated with hint
       expiry Time OPTIONAL
       -- indicates how long the Verifier considers the
       -- nonce valid
    }

   Note: The EvidenceHint structure is defined in
   [I-D.ietf-lamps-csr-attestation].  The hint is intended for an
   Attester to indicate to the EST server which Verifier should be
   invoked to request a nonce.

   The use of the general request/response message exchange leads to an
   extra roundtrip to convey the nonce from the CA/RA to the end entity
   (and ultimately to the Attester inside the end entity).

   The end entity MUST construct a NonceRequest request message to
   trigger the RA/CA to transmit a nonce in the response.

   [Open Issue: Should request message indicate the remote attestation
   capability of the end entity rather than relying on "policy
   information"?  This may also allow to inform the CA/RA about the type
   of attestation technology/technologies available to the end entity.]

Tschofenig & Brockhaus  Expires 3 September 2024                [Page 5]
Internet-Draft         Nonce Extension for CMP/EST            March 2024

   If the end entity supports remote attestation and the policy requires
   Evidence in a CSR to be provided, the RA/CA issues an NonceResponse
   response message containing a nonce.

   Figure 2 showns the interaction graphically.

   End Entity                                          RA/CA
   ==========                                      =============

                 -->>-- NonceRequest -->>--
                                                   Verify request
                                                   Generate nonce*
                                                   Create response
                 --<<-- NonceResponse --<<--
                         (nonce, expiry)

   Generate key pair
   Generate Evidence*
   Generate certification request message
                 -->>-- certification request -->>--
                       (+Evidence including nonce)
                                                  Verify request
                                                  Verify Evidence*
                                                  Check for replay*
                                                  Issue certificate
                                                  Create response
                 --<<-- certification response --<<--
   Handle response
   Store certificate

   *: These steps require interactions with the Attester
   (on the EE side) and with the Verifier (on the RA/CA side).

              Figure 2: CMP Exchange with Nonce and Evidence.

4.  Conveying a Nonce in EST

   The EST client can request a nonce for its Attester.  This function
   is generally performed after requesting CA certificates and before
   other EST functions.

   The EST server MUST support the use of the path-prefix of "/.well-
   known/" as defined in [RFC5785] and the registered name of "est".
   Thus, a valid EST server URI path begins with
   "https://www.example.com/.well-known/est".  Each EST operation is
   indicated by a path-suffix that indicates the intended operation.

   The following operation is defined by this specificaion:

Tschofenig & Brockhaus  Expires 3 September 2024                [Page 6]
Internet-Draft         Nonce Extension for CMP/EST            March 2024

    +------------------------+-----------------+-------------------+
    | Operation              |Operation path   | Details           |
    +========================+=================+===================+
    | Retrieval of a nonce   | /nonce          | This section      |
    +------------------------+-----------------+-------------------+

   The operation path is appended to the path-prefix to form the URI
   used with HTTP GET or POST to perform the desired EST operation.  An
   example valid URI absolute path for the "/nonce" operation is
   "/.well-known/est/nonce".

   An EST client uses a GET or a POST depending on whether parameters
   are included:

   *  A GET request MUST be used when the EST client does not want to
      convey extra parameters.

   *  A POST request MUST be used when parameters, like nonce length or
      a hint about the verification service, are included in the
      request.

 +-------------------+---------------------------------+---------------+
 | Message type      | Media type(s)                   | Reference     |
 | (per operation)   |                                 |               |
 +===================+=================================+===============+
 | Nonce Request     | N/A (for GET) or                | This section  |
 |                   | application/json (for POST)     |               |
 +===================+=================================+===============+
 | Nonce Response    | application/json                | This section  |
 |                   |                                 |               |
 +===================+=================================+===============+

   To retrieve a nonce using a GET, the EST client would use the
   following HTTP request-line:

   GET /.well-known/est/nonce HTTP/1.1

   To retrieve a nonce by specifying the size of the requested nonce
   (and/or by including a hint about the Verification service) a POST
   message is used, as shown below:

   POST /.well-known/est/nonce HTTP/1.1
   Content-Type: application/json
   {
     "len": 8,
     "hint": "https://example.com"
   }

Tschofenig & Brockhaus  Expires 3 September 2024                [Page 7]
Internet-Draft         Nonce Extension for CMP/EST            March 2024

   The payload in a POST request MUST be of content-type of
   "application/json" and MUST contain a JSON object [RFC7159] with the
   member "len" and/or "hint".  The value of the "len" member indicates
   the length of the requested nonce value in bytes.  The "hint" member
   contains either be a rfc822Name, a dNSName, a uri, or a test value
   (based on the definition in the EvidenceHint structure from
   [I-D.ietf-lamps-csr-attestation]).

   The EST server MAY request HTTP-based client authentication, as
   explained in Section 3.2.3 of [RFC7030].

   If the request is successful, the EST server response MUST contain a
   HTTP 200 response code with a content-type of "application/json" and
   a JSON object [RFC7159] with the member nonce.  The expiry member is
   optional and indicates the time the nonce is considered valid.  After
   the expiry time is expired, the session is likely garbage collected.

   Below is a non-normative example of the response given by the EST
   server:

   HTTP/1.1 200 OK
   Content-Type: application/json

   {
       "nonce": "MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=",
       "expiry": "2031-10-12T07:20:50.52Z"
   }

   [Open Issue: Should we also register a content type for use with EST
   over CoAP where the nonce and the expiry field is encoded in a CBOR
   structure?]

5.  Nonce Processing Guidelines

   When the RA/CA is requested or configured to transmit a nonce to an
   end entity then it interacts with the Verifier.  The Verifier is,
   according to the IETF RATS architecture [RFC9334], "a role performed
   by an entity that appraises the validity of Evidence about an
   Attester and produces Attestation Results to be used by a Relying
   Party."  Since the Verifier validates Evidence it is also the source
   of the nonce to check for replay.

   The nonce value MUST contain a random byte sequence whereby the
   length depends on the used remote attestation technology.  Since the
   nonce is relayed with the RA/CA, it MUST be copied to the respective
   structure, as described in Section 4 and Section 3, for transmission
   to the Attester.

Tschofenig & Brockhaus  Expires 3 September 2024                [Page 8]
Internet-Draft         Nonce Extension for CMP/EST            March 2024

   For example, the PSA attestation token
   [I-D.tschofenig-rats-psa-token] supports nonces of length 32, 48 and
   64 bytes.  Other attestation technologies use nonces of similar
   length.  The assumption in this specification is that the RA/CA have
   out-of-band knowledge about the required nonce length required for
   the attestation technology used by the end entity.  The nonces of
   incorrect length will cause the remote attestation protocol to fail.

   When the end entity receives the nonce it MUST use it, if remote
   attestation is available and supports nonces.  It is better for an
   RA/CA to be aggressive in sending a nonce, at least where there is a
   reasonable chance the client supports remote attestation and the
   client should be allowed to ignore the nonce if it either does not
   support it or cannot use it for policy reasons.

   While the semantics of the attestation API and the software/hardware
   architecture is out-of-scope of this specification, the API will
   return Evidence from the Attester in a format specific to the
   attestation technology utilized.  The encoding of the returned
   evidence varies but will be placed inside the CSR, as specified in
   [I-D.ietf-lamps-csr-attestation].  The software creating the CSR will
   not have to interpret the Evidence format - it is treated as an
   opaque blob.  It is important to note that the nonce is carried in
   the Evidence, either implicitly or explicitly, and it MUST NOT be
   conveyed in CSR structures outside the Evidence payload.

   The processing of the CSR containing Evidence is described in
   [I-D.ietf-lamps-csr-attestation].  Note that the issued certificates
   does not contain the nonce, as explained in
   [I-D.ietf-lamps-csr-attestation].

6.  IANA Considerations

   TBD:

7.  Security Considerations

   This specification defines how to obtain a nonce via CMP and EST and
   assumes that the nonce does not require confidentiality protection
   without impacting the security property of the remote attestation
   protocol.  [RFC9334] defines the IETF remote attestation architecture
   discusses nonce-based freshness in great detail.

   Section 8.4 of [I-D.ietf-rats-eat] places randomness and privacy
   requirement on the generation of the nonce for use with an Entity
   Attestation Token (EAT).  These requirements have been adopted by
   attestation technologies, such as the PSA attestation token
   [I-D.tschofenig-rats-psa-token] and are of general utility:

Tschofenig & Brockhaus  Expires 3 September 2024                [Page 9]
Internet-Draft         Nonce Extension for CMP/EST            March 2024

   *  The nonce MUST have at least 64 bits of entropy.

   *  To avoid the conveyance of privacy-related information in the
      nonce, it should be derived using a salt that originates from a
      true and reliable random number generator or any other source of
      randomness.

   Since each specification of an attestation technology offers guidance
   for replay protection with nonces (and other techniques) this
   document needs to defer specific guidance to the respective
   specifications.

   For the use of Evidence in a CSR the security considerations of
   [I-D.ietf-lamps-csr-attestation] are relevant to this document.

8.  References

8.1.  Normative References

   [I-D.ietf-lamps-csr-attestation]
              Ounsworth, M., Tschofenig, H., and H. Birkholz, "Use of
              Remote Attestation with Certificate Signing Requests",
              Work in Progress, Internet-Draft, draft-ietf-lamps-csr-
              attestation-08, 1 March 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
              csr-attestation-08>.

   [I-D.ietf-lamps-rfc4210bis]
              Brockhaus, H., von Oheimb, D., Ounsworth, M., and J. Gray,
              "Internet X.509 Public Key Infrastructure -- Certificate
              Management Protocol (CMP)", Work in Progress, Internet-
              Draft, draft-ietf-lamps-rfc4210bis-08, 1 March 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
              rfc4210bis-08>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
              <https://www.rfc-editor.org/rfc/rfc5280>.

Tschofenig & Brockhaus  Expires 3 September 2024               [Page 10]
Internet-Draft         Nonce Extension for CMP/EST            March 2024

   [RFC5785]  Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
              Uniform Resource Identifiers (URIs)", RFC 5785,
              DOI 10.17487/RFC5785, April 2010,
              <https://www.rfc-editor.org/rfc/rfc5785>.

   [RFC7030]  Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
              "Enrollment over Secure Transport", RFC 7030,
              DOI 10.17487/RFC7030, October 2013,
              <https://www.rfc-editor.org/rfc/rfc7030>.

   [RFC7159]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
              Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
              2014, <https://www.rfc-editor.org/rfc/rfc7159>.

   [RFC8295]  Turner, S., "EST (Enrollment over Secure Transport)
              Extensions", RFC 8295, DOI 10.17487/RFC8295, January 2018,
              <https://www.rfc-editor.org/rfc/rfc8295>.

8.2.  Informative References

   [I-D.ietf-rats-eat]
              Lundblade, L., Mandyam, G., O'Donoghue, J., and C.
              Wallace, "The Entity Attestation Token (EAT)", Work in
              Progress, Internet-Draft, draft-ietf-rats-eat-25, 15
              January 2024, <https://datatracker.ietf.org/doc/html/
              draft-ietf-rats-eat-25>.

   [I-D.tschofenig-rats-psa-token]
              Tschofenig, H., Frost, S., Brossard, M., Shaw, A. L., and
              T. Fossati, "Arm's Platform Security Architecture (PSA)
              Attestation Token", Work in Progress, Internet-Draft,
              draft-tschofenig-rats-psa-token-22, 21 February 2024,
              <https://datatracker.ietf.org/doc/html/draft-tschofenig-
              rats-psa-token-22>.

   [RFC9334]  Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
              W. Pan, "Remote ATtestation procedureS (RATS)
              Architecture", RFC 9334, DOI 10.17487/RFC9334, January
              2023, <https://www.rfc-editor.org/rfc/rfc9334>.

   [TPM20]    Trusted Computing Group, "Trusted Platform Module Library
              Specification, Family 2.0, Level 00, Revision 01.59",
              November 2019,
              <https://trustedcomputinggroup.org/resource/tpm-library-
              specification/>.

Tschofenig & Brockhaus  Expires 3 September 2024               [Page 11]
Internet-Draft         Nonce Extension for CMP/EST            March 2024

Appendix A.  Acknowledgments

   We would like to thank Russ Housley, Thomas Fossati, Watson Ladd,
   Ionut Mihalcea and Carl Wallace for their review comments.

Authors' Addresses

   Hannes Tschofenig
   Siemens
   Email: hannes.tschofenig@siemens.com

   Hendrik Brockhaus
   Siemens
   Email: hendrik.brockhaus@siemens.com

Tschofenig & Brockhaus  Expires 3 September 2024               [Page 12]