Internet DRAFT - draft-tschofenig-lamps-nonce-for-cmp
draft-tschofenig-lamps-nonce-for-cmp
LAMPS H. Tschofenig
Internet-Draft H. Brockhaus
Intended status: Standards Track Siemens
Expires: 2 February 2024 1 August 2023
Nonce-based Freshness for Attestation in Certification Requests for use
with the Certification Management Protocol
draft-tschofenig-lamps-nonce-for-cmp-01
Abstract
Certificate Management Protocol (CMP) defines protocol messages for
X.509v3 certificate creation and management. CMP provides
interactions between client systems and PKI components, such as a
Registration Authority (RA) and a Certification Authority (CA).
CMP allows an RA/CA to inform an end entity about the information it
has to provide in a certification request. When an end entity places
attestation information in form of evidence in a certification
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 2 February 2024.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
Tschofenig & Brockhaus Expires 2 February 2024 [Page 1]
Internet-Draft Nonce-based Freshness in CMP August 2023
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 . . . . . . . . . . . . 3
3. Certificate Request Template Extension . . . . . . . . . . . 4
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 5
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5
7. Compilable ASN.1 Definitions . . . . . . . . . . . . . . . . 5
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
Certificate Management Protocol (CMP) [I-D.ietf-lamps-rfc4210bis]
defines protocol messages for X.509v3 certificate creation and
management. CMP provides interactions between client systems and PKI
components, such as a Registration Authority (RA) and a Certification
Authority (CA).
CMP allows an RA/CA to inform an end entity about the information it
has to provide in a certification request. When an end entity places
attestation information in form of evidence in a certification
signing request (CSR) it may need to demonstrate freshness of the
provided evidence. Such an attestation extension to a CSR is
described in [I-D.ounsworth-csr-attestation]. Attestation technology
today, such as [TPM20] and [I-D.tschofenig-rats-psa-token], often
accomplishes this task via the help of nonces. A discussion of
freshness approaches for evidence is found in Section 10 of
[RFC9334].
For an end entity to include a nonce in the evidence (by the
attester) it is necessary to obtain this nonce from the relying
party, i.e. RA/CA in our use case, first. Since the CSR itself is a
'one-shot' message the CMP protocol is used to obtain the nonce from
the RA/CA. CMP already offers a mechanism to request information
from the RA/CA prior to a certification request. This document uses
Tschofenig & Brockhaus Expires 2 February 2024 [Page 2]
Internet-Draft Nonce-based Freshness in CMP August 2023
the CertReqTemplate described in Section 5.3.19.16 of
[I-D.ietf-lamps-rfc4210bis]. 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.
This exchange is shown graphically below.
End entity RA/CA
========== =============
-->>-- CertReqTemplate request -->>--
Verify request
Generate nonce*
Create response
--<<-- CertReqTemplate response --<<--
(nonce)
Generate key pair
Fetch Evidence (with nonce) from attester
Evidence Response from attestation
Creation of certification request
Protect request
-->>-- certification request -->>--
(evidence including nonce)
Verify request
Verify evidence*
Check replay*
Issue certificate
Create response
--<<-- certification response --<<--
Handle response
Store certificate
*: These steps require interactions with a verifier.
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].
We use the terms certification signing request (CSR) and
certification request interchangeably.
Tschofenig & Brockhaus Expires 2 February 2024 [Page 3]
Internet-Draft Nonce-based Freshness in CMP August 2023
3. Certificate Request Template Extension
The following structure defines the attestation nonce provided by the
CA/RA via a CertReqTemplate response message. This leads to an extra
roundtrip to convey the nonce to the end entity (and ultimately to
the attester functionality inside the device).
id-pe-attestionNonce OBJECT IDENTIFIER ::= { id-pe TBD1 }
AttestationNonce ::= OCTET STRING
The end entity MUST construct a CertReqTemplate request message to
trigger the RA/CA to transmit a nonce.
When the RA/CA receive the CertReqTemplate request message the
profile information is used to determine that the end entity supports
attestation functionality. If the end-entity supports attestation
and the policy requires attestation information in a CSR to be
provided, the RA/CA issues a CertReqTemplate response containing a
nonce in in the template. The AttestationNonce MUST contain a random
value that depends on the used attestation technology. 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 technology used by the end entity.
When the end entity receives the CertReqTemplate response it SHOULD
use this nonce as input to an attestation API call made to the
attester functionality on the device. The rational behind this
design is that the client may support an attestation technology but
configuration or policies make it unavailable. Hence, 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 attestation
functionality 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 semantic 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.ounsworth-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
either implictily or explicitly in the evidence and it MUST NOT be
conveyed in elements of the CSR.
Tschofenig & Brockhaus Expires 2 February 2024 [Page 4]
Internet-Draft Nonce-based Freshness in CMP August 2023
The processing of the CSR containing attestation information is
described in [I-D.ounsworth-csr-attestation]. Note that the CA MUST
NOT issue a certificate that contains the extension provided in the
CertReqTemplate containing the nonce. Instead the nonce is typically
embedded in the evidence and used as a way to provide freshness of
the evidence signed by the attester.
[Editor's Note: It may be useful to augment the CertReqTemplate
request with information about the type of attestation technology/
technologies available on the end entity. This is a topic for
further discussion.]
4. IANA Considerations
[Editor's Note: The ASN.1 module OID (TBD2) and the new private
extension (TBD1) must be registered.]
5. Security Considerations
This specification adds a nonce to the Certificate Request Template
for use with attestation information in a CSR. This specification
assumes that the nonce does not require confidentiality protection
without impacting the security property of the attestation protocol.
[RFC9334] defining the IETF remote attestation architecture discusses
this and other aspects in more detail.
For the use of attestation in the CSR the security considerations of
[I-D.ounsworth-csr-attestation] are relevant to this document.
6. Acknowledgments
We would like to thank Russ Housley and Carl Wallace for their review
comments.
7. Compilable ASN.1 Definitions
PKIX-CMP-KeyAttestationNonceExtn-2023 { iso(1) identified-
organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-mod-cmpKeyAttestationNonce(TBD2) }
DEFINITIONS IMPLICIT TAGS ::= BEGIN
IMPORTS
id-pe FROM PKIX1Explicit-2009 -- from [RFC5912] { iso(1) identified-
organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-mod-pkix1-explicit-02(51) } ;
Tschofenig & Brockhaus Expires 2 February 2024 [Page 5]
Internet-Draft Nonce-based Freshness in CMP August 2023
id-pe-attestionNonce OBJECT IDENTIFIER ::= { id-pe TBD1 }
AttestationNonce ::= OCTET STRING
END
8. References
8.1. Normative References
[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-07, 19 June 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
rfc4210bis-07>.
[I-D.ounsworth-csr-attestation]
Ounsworth, M. and H. Tschofenig, "Use of Attestation with
Certification Signing Requests", Work in Progress,
Internet-Draft, draft-ounsworth-csr-attestation-00, 8 July
2023, <https://datatracker.ietf.org/doc/html/draft-
ounsworth-csr-attestation-00>.
[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>.
8.2. Informative References
[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-12, 5 July 2023,
<https://datatracker.ietf.org/doc/html/draft-tschofenig-
rats-psa-token-12>.
[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>.
Tschofenig & Brockhaus Expires 2 February 2024 [Page 6]
Internet-Draft Nonce-based Freshness in CMP August 2023
[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/>.
Authors' Addresses
Hannes Tschofenig
Siemens
Email: hannes.tschofenig@siemens.com
Hendrik Brockhaus
Siemens
Email: hendrik.brockhaus@siemens.com
Tschofenig & Brockhaus Expires 2 February 2024 [Page 7]
