Automated Certificate Management Environment (ACME) rats Identifier and Challenge Type
draft-liu-acme-rats-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Peter Chunchi Liu | ||
| Last updated | 2024-10-20 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-liu-acme-rats-00
Automated Certificate Management Environment C. P. Liu
Internet-Draft Huawei
Intended status: Standards Track 21 October 2024
Expires: 24 April 2025
Automated Certificate Management Environment (ACME) rats Identifier and
Challenge Type
draft-liu-acme-rats-00
Abstract
This document describes an approach where ACME Client can prove
possession of a Remote Attestation Result to an ACME Server.
About This Document
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at
https://liuchunchi.github.io/draft-liu-acme-rats/draft-liu-acme-
rats.html. Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-liu-acme-rats/.
Discussion of this document takes place on the Automated Certificate
Management Environment Working Group mailing list
(mailto:acme@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/acme/. Subscribe at
https://www.ietf.org/mailman/listinfo/acme/.
Source for this draft and an issue tracker can be found at
https://github.com/liuchunchi/draft-liu-acme-rats.
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."
Liu Expires 24 April 2025 [Page 1]
Internet-Draft acme-rats October 2024
This Internet-Draft will expire on 24 April 2025.
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. Extensions -- rats identifier . . . . . . . . . . . . . . . . 3
3. Extensions -- rats challenge type . . . . . . . . . . . . . . 5
3.1. RATS-01 Challenge . . . . . . . . . . . . . . . . . . . . 5
3.2. RATS-02 Challenge . . . . . . . . . . . . . . . . . . . . 6
4. Reusing HTTP challenge type . . . . . . . . . . . . . . . . . 6
5. Example use case -- enterprise access . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . 7
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
ACME [RFC8555] is a standard protocol for issuing and renewing
certificates automatically, widely used in the Internet scenario,
help an ACME Client prove its ownership to an identifier like domain
name or email address.
In order to prevent issuing certificates to malicious devices, a few
works are ongoing in the LAMPS and RATS WG.
* [I-D.ietf-lamps-csr-attestation] define trustworthy claims about
device's platform generating the certification signing requests
(CSR) and the private key resides on this platform.
Liu Expires 24 April 2025 [Page 2]
Internet-Draft acme-rats October 2024
* [I-D.draft-moriarty-rats-posture-assessment] define a summary of a
local assessment of posture for managed systems and across various
layers.
In this document, we propose an approach where ACME Server checks if
the ACME Clients possess a valid remote attestation result, for
instance, EAT (entity attestation token). We define a new ACME
"rats" identifier and "rats" challenge type for ACME Clients to prove
their possession of EAT. In this way, we (as network administators)
issue certificates only to devices that have a fresh attestation
result, indicating such device has passed the most up-to-date
security checks. By repeating this process and issue only short-
lived certificates to qualified devices, we also fulfill the
continuous monitoring/validation requirement of Zero-Trust principle.
The example use case include an enterprise scenario where Network
Operations Center (NOC) issue certificates to devices that are
freshly appraised by the Security Operations Center (SOC), in order
to help them work together.
For ease of denotion, we omit the "ACME" adjective from now on, where
Server means ACME Server and Client means ACME Client.
2. Extensions -- rats identifier
An rats identifier type represents a unique identifier to an
attestation result. It extends a "rats" identifier type and a string
value.
type (required, string): The string "rats".
value (required, string): The identifier itself.
The following steps are the ones that will be affected:
1. newOrder Request Object - identifiers: During the certificate
order creation step, the Client sends a /newOrder JWS request
(Section 7.4 of [RFC8555]) whose payload contains an array of
identifiers. The Client adds an rats identifier to the array.
An example extended newOrder JWS request:
Liu Expires 24 April 2025 [Page 3]
Internet-Draft acme-rats October 2024
{
"protected": base64url({
"alg": "ES256",
}),
"payload": base64url({
"identifiers": [
{ "type": "rats", "value": "0123456789abcdef" },
],
}),
"signature": "H6ZXtGjTZyUnPeKn...wEA4TklBdh3e454g"
}
2. Order Object - identifiers: After a newOrder request is sent to
the Server, the Account Object creates an Order Object (Section 7.1.3
of [RFC8555]) with "rats" identifiers and values from Step 1.
An example extended Order Object:
{
"status": "pending",
"identifiers": [
{ "type": "rats", "value": "0123456789abcdef" },
],
"authorizations": [
"https://example.com/acme/authz/PAniVnsZcis",
],
"finalize": "https://example.com/acme/order/T..fgo/finalize",
}
3. Authorization Object - identifier: The Server creates an
Authorization Object that has rats identifier (Section 7.1.4 of
[RFC8555])
4. Challenge Object - identifier: The Server creates a Challenge
Object that has rats challenge type.
An example extended Authorization Object (that contains a Challenge
Object):
Liu Expires 24 April 2025 [Page 4]
Internet-Draft acme-rats October 2024
{
"status": "pending",
"identifier": {
"type": "rats",
"value": "0123456789abcdef"
},
"challenges": [
{
"type": "rats",
"url": "https://example.com/acme/chall/prV_B7yEyA4",
"status": "pending",
"token": "DGyRejmCefe7v4NfDGDKfA",
},
{
"type": "http-01",
"url": "https://example.com/acme/chall/prV_B7yEyA4",
"status": "pending",
"token": "DGyRejmCefe7v4NfDGDKfA",
}
],
}
3. Extensions -- rats challenge type
A rats challenge type help the Client prove ownership to its
attestation result identifier. This section describes the challenge/
response extensions and procedures to use them.
3.1. RATS-01 Challenge
RATS-01 Challenge simply works with Passport Model of RATS. The
corresponding Challenge Object is:
type (required, string): The string "rats-01".
url (required, string): The URL that the Client post its response
to.
token (required, string): Same as Section 8.3 of RFC8555.
The response sent to the url is:
keyAuthorization = token || '.' || base64url(attestationResult)
Liu Expires 24 April 2025 [Page 5]
Internet-Draft acme-rats October 2024
where the attestationResult is the entire EAT (in JWT format). The
ACME Server verifies the attestationResult. If pass, set Order
Object and Authorization Object's "status" Object to "valid",
otherwise "invalid".
3.2. RATS-02 Challenge
RATS-02 Challenge works with the Background Check Model of RATS.
TODO: After the Client gets the "token", it include "token" as part
of its RATS Evidence, appraise again. The new attestationResult now
has a "token" claim. The retrival process is same.
4. Reusing HTTP challenge type
We can also reuse http-01 challenge type in Section 8.3 of [RFC8555].
This changes steps used in {#rats01}.
1. The Client creates the keyAuthorization string defined in
{#rats01}.
2. The Client provisions the keyAuthorization string in the resource
path defined in the original http-01 challenge -- "/.well-known/
acme-challenge/", followed by the "token".
3. The Client sends an empty object ({}) to the url, notifying the
Server it is ready to fetch.
4. The Server fetches the keyAuthorization string from the resource
path. Verifies the "token", retrive the attestationResult.
5. Example use case -- enterprise access
In an enterprise network scenario, it is hard to coordinate Security
Operations Center (SOC) and Network Operations Center (NOC) to work
together due to various of reasons:
1. Integration/compatibility difficulty: Integrating SOC and NOC
requires plenty of customized, case-by-case developing work.
Especially considering differrnt system vendors, system versions,
different data models and formats due to different client
needs... Let alone possible updates.
2. Conflict of duties: NOC people do not want SOC people to
interfere with their daily work, and so do SOC people. Also, NOC
people may have limited security knowledge, and SOC people vice
versa. Where to draw the line and what is the best tool to help
them collaborate is a question.
Liu Expires 24 April 2025 [Page 6]
Internet-Draft acme-rats October 2024
This work proposes a way to help SOC and NOC work together, with
separated duties (to avoid conflict) and ease of working together
(proper abstraction).
An Endpoint Detection and Response (EDR) software and Security
Operations Center (SOC) is responsible for checking the security
status of an accessing end device. If the device passed latest
security checks, EDR/SOC should issue fresh attestation results
(consider as a security clearance). Otherwise, EDR/SOC should refuse
to issue (new) attestation results. A Network Operations Center
(NOC) could use ACME to issue short-lived certificates to only
devices with fresh attestation results. In this way, the NOC can
follow a Zero-Trust philosophy and issue network access to only
devices that are continuously monitored and have no known security
risks up-to-date. SOC can also have flexible security policies and
decide what to check.
6. Security Considerations
TODO Security
7. IANA Considerations
This document has no IANA actions.
8. References
8.1. Normative References
[RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
Kasten, "Automatic Certificate Management Environment
(ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019,
<https://www.rfc-editor.org/rfc/rfc8555>.
8.2. Informative References
[I-D.draft-moriarty-rats-posture-assessment]
Moriarty, K., Wiseman, M., and A. Stein, "Remote Posture
Assessment for Systems, Containers, and Applications",
Work in Progress, Internet-Draft, draft-moriarty-rats-
posture-assessment-01, 2 July 2024,
<https://datatracker.ietf.org/doc/html/draft-moriarty-
rats-posture-assessment-01>.
[I-D.ietf-lamps-csr-attestation]
Ounsworth, M., Tschofenig, H., Birkholz, H., Wiseman, M.,
and N. Smith, "Use of Remote Attestation with
Certification Signing Requests", Work in Progress,
Liu Expires 24 April 2025 [Page 7]
Internet-Draft acme-rats October 2024
Internet-Draft, draft-ietf-lamps-csr-attestation-13, 20
October 2024, <https://datatracker.ietf.org/doc/html/
draft-ietf-lamps-csr-attestation-13>.
Acknowledgments
TODO acknowledge.
Author's Address
Chunchi Peter Liu
Huawei
Email: liuchunchi@huawei.com
Liu Expires 24 April 2025 [Page 8]