Let me write this up, since I've been through a few iterations of explaining this. I would welcome edits and clarifications, but note that there are definitely details that I have omitted for purposes of clarity.
The documents I know about:
1. draft-ietf-lamps-csr-attestation. (in LAMPS)
2. draft-acme-device-attest (adopted in ACME, despite wrong name)
3. draft-liu-acme-rats-latest (yet to be adopted in ACME)
4. draft-ietf-acme-client (adopted in ACME)
TL;DR> no overlap between them. Reasonable to mix and match.
To understand things best, consider a system that has a TCG TPM 2.0 device
attached.
There are some places that a private key can be stored: in the TPM, or in a
file on the system disk.
(Note that private keys can be "sealed" by the TPM, which means that
the private key is symmetrically encrypted by a key that only the TPM knows.
Such a key is effectively in the TPM, since they can never be used when
outside)
**draft-ietf-lamps-csr-attestation**
This document is about providing Evidence/Attestation Result about the
location of the private key. A CA wants proof as to where the private key is.
The certificate signing policy of the CA to sign certain kinds of keys
requires that the key be stored in a place with particular security
properties.
Evidence: The Evidence is included *within* the Certificate Signing Request,
and then
via background check, Verified, producing Attestation Results.
This mechanism can be used with any enrollment protocol: ACME,
SCEP, EST, CMP... anything that uses CSR.
Certificate: The Attestation Results will not typically affect anything that
goes into the resulting certificate.
**draft-acme-device-attest**
This document is about authorizing an identity relating to a TPM, or
equivalent TEE, such as Android Keystore or ChromeBook. The identity in
question is the
permanent-identifyer/hardware-module, and includes hwType and hwSerialNum.
This allows authorization by leveraging keys built in the TPM during
manufacturing time.
Evidence: A challenge nonce is provided, and the client uses the
credential in their hardware to sign a WebAuthn statement.
This credential is used as the AccountKey, and this can connect
to an Enterprise based directory.
Certificate: The hwType/hwSerialNum can be included into resulting
certificate as an otherName SAN.
Note that the private key associated with the certificate has no
set relationship to the TPM/TEE. It could be the same,
it could be entirely different, and *this* extension says
nothing about that key.
**draft-liu-acme-rats**
This document is about authorizing issuing of a certificate based upon an
evaluation of the trustworthiness of the system making the request.
While it now uses (I-D not yet updated) a pseudo-identity with ACME,
the resulting Certificate never has a related identity in it.
Evidence: A challenge nonce is provided, a passport mechanism is used to
get fresh Attestation Results, which are then returned to the
ACME server in the Authorization Response.
Certificate: No identity that goes into the certificate is defended.
**draft-ietf-acme-client**
This document offers OTP (HOTP, TOTP, OTP), public key and WebauthN
authorizations. While the document presents these as challenges, it is not
clear to me how that is correct. It seems to me that this is an account
authentication in the guise of an account.
Evidence: The HOTP and TOTP mechanisms are not challenge/response systems.
A new password is generated every 30s (TOTP), or when a key is
pressed (HOTP). Validation of the result value requires
that the ACME Server has access to the per-user secret. Or
to a validation service that has access to it. RADIUS
(User-Password) or DIAMETER or another service could be used.
Cerificate: No identity that goes into the certificate is defended.
-------------
Could one use all four at the same time? Yes.
Assume a new-hire to an Enterprise. The new employee has been issued with a
corporate device (phone or laptop), and a TOTP physical device (which might
be the phone, or a token with biometric activation)
1. draft-ietf-acme-client could be used to authenticate the ACME account (if
rewritten), or an ephermal account used with the challenge mechanism described
used.
This authenticates the new employee.
2. draft-lui-acme-rats is used to provide evidence that the device itself is
running appropriate ("golden") versions of software; that it's malware free.
3. draft-acme-device-attest is used to connect the certificate is going to be
issued to the device itself. This provides evidence that the credential is
on the device that the Enterprise expected to deploy to. Alternatively, in a
BYOD situation, a TOFU step results. Certificate renew then can be locked to
that device. This could mitigate physical attacks/threats on the *person*
itself ("gun to the head") where they are compelled to load a credential into
an attackers device.
4. draft-ietf-lamps-csr-attestation provides assurance that the generated
private key is held in a secure enclave, from which it can not be exported.
5. RFC8823. An email-reply-00 challenge provides proof of control of an email
account, and results in a certificate with a SubjectAltName rfc822Name for
that email address.
ps: I think that draft-ietf-acme-client needs significant revision.
I don't think it's about client-certificates, in the same sense that DANCE
thinks about them. It's about authenticating human-shaped things.
pps: I would not use the word "attest" with draft-acme-device-attest.
To me, this is a form of device authentication, with optional authentication
of the HardwareModule otherName contents.
--
Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
