| ACME Working Group | R. Shekh-Yusef |
| Internet-Draft | Avaya |
| Intended status: Standards Track | January 16, 2019 |
| Expires: July 20, 2019 |
Third-Party Device Attestation for ACME
draft-yusef-acme-3rd-party-device-attestation-01
This document defines a Third-Party Device Attestation for ACME mechanism to allow the ACME CA to delegate some of its authentication and authorization functions to a separate trusted entity, to automate the issuance of certificates to devices.
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 July 20, 2019.
Copyright (c) 2019 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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
ACME [I-D.ietf-acme-acme] is a mechanism for automating certificate management on the Internet. It enables administrative entities to prove effective control over resources like domain names, and automates the process of generating and issuing certificates.
Proving effective control over a device requires an attestation from a third-party who has authority over the device.
This document defines a Third-Party Device Attestation for ACME mechanism to allow the ACME CA to delegate some of its authentication and authorization functions to a separate trusted entity, to automate the issuance of certificates to devices.
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 [RFC2119].
Device: this is an IP device, e.g. SIP phone, that is manufactured by a Device Authority.
Device Authority: this is the Third-Party Device manufacturer that has authority over the Device.
Client: this is a server that has authority over a domain and deploys a Device and automatically obtains a certificate for it from ACME CA with the Client's domain as an identifier.
ACME CA: this is the Certificate Authority (CA), e.g. Let's Encrypt, that has a trust relationship with the above Device Authority, that issues the certificate.
Some devices come from the factory with a self-signed certificate with the MAC of the device as the certificate identifier, and the details of the certificates stored in a server in the cloud that acts as the authority for these devices.
These self-signed certificates are used to authenticate the device during a bootstrapping process, but are generally not useful to allow the device to authenticate to other services the device interacts with.
The use case is that the Client wants to deploy a Device manufactured by a Device Authority and wants to be able to automatically obtain a certificate for the Device from ACME CA with an identifier controlled by the Client.
For example, if vendor.com is configured as a trusted entity on ACME server, and if a device from vendor.com is being deployed by customer.com, and customer.com requires the device to obtain an ACME certificate, this mechanism allows the automatic issuance of certificate to the device with a non-domain identifier, e.g. MAC, based on attestation from vendor.com, and with the customer.com identifier based on an existing Client account with the ACME server.
This architecture assumes a trust relationship between the ACME CA and the Third-Party Device Authority, which means that the ACME CA is willing to accept the attestation of the Third-Party Device Authority for particular types of identifiers as sufficient proof to issue a certificate to a device with a non-domain identifier.
The following figure describes the various elements, the relationship between these elements, and the OAuth role of each element.
OAuth AS OAuth RS
+-----------+ +-----------+
| Device | | |
+------------>| Authority |<------------------------->| ACME CA |
| | | | |
| +-----------+ +-----------+
| ^
| |
| |
| |
+------+ |
|Device| |
+------+ |
|
|
|
|
+-----------+
| |
| Client |
| |
+-----------+
OAuth Client
The Device trusts the Device Authority.
The Device Authority and ACME CA trust each other.
The Client has an account with the Device Authority and is able to claim devices manufactured by the Device Authority. The Client has an account with ACME CA and able to request certificates for its domain.
The following figure provides an overview of the interaction between the ACME Client and ACME Server, as defined in [I-D.ietf-acme-acme], with few changes to allow the Client to obtain an end entity certificate for a Device based on an attestation from a Device Authority:
Client Device Authority ACME CA
(customer.com) (as.vendor.com) (acme.com)
| | |
| [01] POST /new-order [kid=customer.com, url=vendor.com, identifier={mac}]
|------------------------------------------------------------------------>|
| | |
| [02] 201 |
| [authorizations=vendor.com/acme/authz/1234, |
| finalize=customer.com/acme/order/asdf/finalize] |
|<------------------------------------------------------------------------|
| | |
| [03] POST /vendor.com/acme/authz/1234 |
|------------------------------------------------------------------------>|
| | |
| [04] 401 Unauthorized [Link: as.vendor.com] |
|<------------------------------------------------------------------------|
| | |
| [05] Use OAuth to obtain a device JWT |
|<==================================>| |
| | |
| [06] POST /vendor.com/acme/authz/1234 [JWT] |
|------------------------------------------------------------------------>|
| | |
| | [07] 200 [status=valid] |
|<------------------------------------------------------------------------|
| | |
| [08] POST /customer.com/acme/order/asdf/finalize [CSR] |
|------------------------------------------------------------------------>|
| | |
| [09] 200 [certificate=customer.com/acme/cert/asdf] |
|<------------------------------------------------------------------------|
| | |
| [10] GET /customer.com/acme/cert/asdf |
|------------------------------------------------------------------------>|
| | |
| [11] 200 [certificate] |
|<------------------------------------------------------------------------|
| | |
In Step [01] the Client starts the process with a POST request, as per [I-D.ietf-acme-acme], but the header contains a "kid" with the Client domain and "url" with the AS URL.
In Step [2] the server replies with the authorization URL, as per [I-D.ietf-acme-acme], but the authorization url contains the AS, and the finalize URL points to the Client.
In Step [3] the Client starts the authorization process with an empty payload, as per [I-D.ietf-acme-acme].
In Step [04] the server indicates to the Client that it needs to redirect the device to the AS to authenticate, and obtain an access token.
Step [05] is out of scope for this document, which covers the interaction between the Client, the Device, and the AS, to obtain an access token for a device.
In Steps [06] and [07] the Client completes the authorization process using the JWT obtained from the AS.
In Steps [08] and [09] the Client finalizes the process by sending the CSR request to the server, as per [I-D.ietf-acme-acme].
In Steps [10] and [11] the client downloads the certificate from the server, as per [I-D.ietf-acme-acme].
This document introduces the new identifier type that will be used to identify the device applying for a certificate with the ACME server, e.g. { "type": "mac", "value": "112233445566" }
The process starts, step [01], when the Client sends a POST request to the "/acme/new-order" resource on the ACME server.
The request object carries a protected header that contains a "kid" with the Client domain and "url" with the Device Authority URL. The request object carries a payload with the MAC identifier, as defined above, that identifies the device that will be issued a certificate.
The signature carried in the request object is issued using the Client account with the ACME server.
The ACME server responds with a 201, step [02] with an authorization url that contains the Device Authority URL, and finalize ulr that contains the Client URL.
In step [03] the Client starts the authorization process by sending a POST request to the authorization URL with an empty body. In response, the server replies with a 401 Unauthorized as defined in [I-D.ietf-oauth-distributed]:
401 Unauthorized
WWW-Authenticate: Bearer error="invalid_token"
Link: <https://as.vendor.com/.well-known/oauth-authorization-server>
;rel="oauth_server_metadata_uri"
;requested_token_type="urn:ietf:params:oauth:token-type:jwt"
The WWW-Authenticate header includes an error parameter with the value of "invalid_token" to indicate that a token is needed to complete this request.
The Link header provides the details of the AS server and the type of the token that the client must obtain for this request to be processed by the server.
After obtaining the access token, the client completes the authorization process by sending a POST request to the authorization URL with the access token in the payload of the JWS object.
The Device Authority must issue a device access token, in the form of a JWT, to allow the Client to request the ACME CA to issue an end entity certificate.
The payload of the JWT must include the following claims:
iss: contains the device authority url, e.g. as.vendor.com
sub: contains the device mac address.
aud: contains the Client domain, e.g. customer.com, and ACME CA url, e.g. acme.com
The following is an example of a device access token:
Header:
{
"alg": "ES256",
"typ": "JWT"
}
Body:
{
"iss" : "as.vendor.com",
"sub": "112233445566", // Device MAC address
"aud" : ["custmer.com", "acme.com"]
}
TODO
TODO
The author would like to thank Dick Hardt for his reviews and valuable feedback on the pre-published version of this draft.
The author would like to thank Ilari Liusvaara and Ryan Sleevi for their careful review and feedback.
| [I-D.ietf-acme-acme] | Barnes, R., Hoffman-Andrews, J., McCarney, D. and J. Kasten, "Automatic Certificate Management Environment (ACME)", https://datatracker.ietf.org/doc/draft-ietf-acme-acme/, April 2018. |
| [I-D.ietf-oauth-distributed] | Hardt, D., Campbell, B. and N. Sakimura, "Distributed OAuth", https://datatracker.ietf.org/doc/draft-ietf-oauth-distributed/, October 2018. |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. |
| [RFC6749] | Hardt, D., "The OAuth 2.0 Authorization Framework", RFC 6749, October 2012. |