Internet DRAFT - draft-yusef-acme-3rd-party-device-attestation
draft-yusef-acme-3rd-party-device-attestation
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
Abstract
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.
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 July 20, 2019.
Copyright Notice
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.
Shekh-Yusef Expires July 20, 2019 [Page 1]
Internet-Draft 3rd-Party Device Attestation for ACME January 2019
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Entities . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Use Case . . . . . . . . . . . . . . . . . . . . . . . . 3
2.3. Initial Trust . . . . . . . . . . . . . . . . . . . . . . 4
2.4. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 5
3. Identifier Type . . . . . . . . . . . . . . . . . . . . . . . 7
4. Applying for a Certificate . . . . . . . . . . . . . . . . . 7
5. ACME Challenge . . . . . . . . . . . . . . . . . . . . . . . 7
6. Complete Authorization . . . . . . . . . . . . . . . . . . . 8
7. Device Access Token . . . . . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
11. Normative References . . . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
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.
Shekh-Yusef Expires July 20, 2019 [Page 2]
Internet-Draft 3rd-Party Device Attestation for ACME January 2019
1.1. Terminology
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].
2. Overview
2.1. Entities
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.
2.2. Use Case
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,
Shekh-Yusef Expires July 20, 2019 [Page 3]
Internet-Draft 3rd-Party Device Attestation for ACME January 2019
based on attestation from vendor.com, and with the customer.com
identifier based on an existing Client account with the ACME server.
2.3. Initial Trust
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.
Shekh-Yusef Expires July 20, 2019 [Page 4]
Internet-Draft 3rd-Party Device Attestation for ACME January 2019
2.4. Protocol Flow
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] |
|<------------------------------------------------------------------------|
| | |
Shekh-Yusef Expires July 20, 2019 [Page 5]
Internet-Draft 3rd-Party Device Attestation for ACME January 2019
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].
Shekh-Yusef Expires July 20, 2019 [Page 6]
Internet-Draft 3rd-Party Device Attestation for ACME January 2019
3. Identifier Type
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" }
4. Applying for a Certificate
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.
5. ACME Challenge
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.
Shekh-Yusef Expires July 20, 2019 [Page 7]
Internet-Draft 3rd-Party Device Attestation for ACME January 2019
6. Complete Authorization
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.
7. Device Access Token
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"]
}
8. Security Considerations
TODO
Shekh-Yusef Expires July 20, 2019 [Page 8]
Internet-Draft 3rd-Party Device Attestation for ACME January 2019
9. IANA Considerations
TODO
10. Acknowledgments
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.
11. Normative References
[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.
Author's Address
Rifaat Shekh-Yusef
Avaya
250 Sidney Street
Belleville, Ontario
Canada
Phone: +1-613-967-5176
EMail: rifaat.ietf@gmail.com
Shekh-Yusef Expires July 20, 2019 [Page 9]
