Automated Certificate Management Environment (ACME) rats Identifier and Challenge Type

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

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

• [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:¶

  {
    "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):¶

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

keyAuthorization = token || '.' || base64url(attestationResult)

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

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

Acknowledgments

TODO acknowledge.¶

Author's Address