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]