Authentication and Authorization for Constrained Environments Using the OAuth 2.0 Framework (ACE-OAuth)
RFC 9200

quot;, a value that the temperature
       sensor identifies itself with.  The AS evaluates the request and
       authorizes the client to access the resource.

   B:  The AS responds with a 2.05 (Content) response containing the
       Access Information, including the access token.  The PoP access
       token contains the public key of the client, and the Access
       Information contains the public key of the RS.  For communication
       security, this example uses DTLS RawPublicKey between the client
       and the RS.  The issued token will have a short validity time,
       i.e., exp close to iat, in order to mitigate attacks using stolen
       client credentials.  The token includes claims, such as scope,
       with the authorized access that an owner of the temperature
       device can enjoy.  In this example, the scope claim issued by the
       AS informs the RS that the owner of the token that can prove the
       possession of a key is authorized to make a GET request against
       the /temperature resource and a POST request on the /firmware
       resource.  Note that the syntax and semantics of the scope claim
       are application specific.

       Note: In this example, it is assumed that the client knows what
       resource it wants to access and is therefore able to request
       specific audience and scope claims for the access token.

            Authorization
     Client    Server
       |         |
       |<=======>| DTLS Connection Establishment
       |         |   and mutual authentication
       |         |
   A:  +-------->| Header: POST (Code=0.02)
       |  POST   | Uri-Path:"token"
       |         | Content-Format: application/ace+cbor
       |         | Payload: <Request-Payload>
       |         |
   B:  |<--------+ Header: 2.05 Content
       |  2.05   | Content-Format: application/ace+cbor
       |         | Payload: <Response-Payload>
       |         |

       Figure 11: Token Request and Response Using Client Credentials

   The information contained in the Request-Payload and the Response-
   Payload is shown in Figure 12.  Note that the parameter rs_cnf from
   [RFC9201] is used to inform the client about the resource server's
   public key.

   Request-Payload :
   {
     / audience / 5 : "tempSensorInLivingRoom",
     / client_id / 24 : "myclient",
     / req_cnf / 4 : {
     / COSE_Key / 1 : {
         / kid / 2 : b64'1Bg8vub9tLe1gHMzV76e',
         / kty / 1 : 2 / EC2 /,
         / crv / -1 : 1 / P-256 /,
         / x / -2 : b64'f83OJ3D2xF1Bg8vub9tLe1gHMzV76e8Tus9uPHvRVEU',
         / y / -3 : b64'x_FEzRu9m36HLN_tue659LNpXW6pCyStikYjKIWI5a0'
       }
     }
   }

   Response-Payload :
   {
     / access_token / 1 : b64'0INDoQEKoQVNKkXfb7xaWqMT'/ .../,
     / rs_cnf / 41 : {
       / COSE_Key / 1 : {
         / kid / 2 : b64'c29tZSBwdWJsaWMga2V5IGlk',
         / kty / 1 : 2 / EC2 /,
         / crv / -1 : 1 / P-256 /,
         / x / -2   : b64'MKBCTNIcKUSDii11ySs3526iDZ8AiTo7Tu6KPAqv7D4',
         / y / -3   : b64'4Etl6SRW2YiLUrN5vfvVHuhp7x8PxltmWWlbbM4IFyM'
       }
     }
   }

              Figure 12: Request and Response Payload Details

   The content of the access token is shown in Figure 13.

   {
     / aud / 3 : "tempSensorInLivingRoom",
     / iat / 6 : 1563451500,
     / exp / 4 : 1563453000,
     / scope / 9 :  "temperature_g firmware_p",
     / cnf / 8 : {
       / COSE_Key / 1 : {
         / kid / 2 : b64'1Bg8vub9tLe1gHMzV76e',
         / kty / 1 : 2 / EC2 /,
         / crv / -1 : 1 / P-256 /,
         / x / -2 : b64'f83OJ3D2xF1Bg8vub9tLe1gHMzV76e8Tus9uPHvRVEU',
         / y / -3 : b64'x_FEzRu9m36HLN_tue659LNpXW6pCyStikYjKIWI5a0'
       }
     }
   }

         Figure 13: Access Token Including Public Key of the Client

   Messages C and F are shown in Figures 14 and 15.

   C:  The client then sends the PoP access token to the authz-info
       endpoint at the RS.  This is a plain CoAP POST request, i.e., no
       transport or application-layer security is used between the
       client and RS since the token is integrity protected between the
       AS and RS.  The RS verifies that the PoP access token was created
       by a known and trusted AS, which it applies to this RS, and that
       it is valid.  The RS caches the security context together with
       authorization information about this client contained in the PoP
       access token.

              Resource
    Client     Server
       |         |
   C:  +-------->| Header: POST (Code=0.02)
       |  POST   | Uri-Path:"authz-info"
       |         | Payload: 0INDoQEKoQVN ...
       |         |
       |<--------+ Header: 2.04 Changed
       |  2.04   |
       |         |

               Figure 14: Access Token Provisioning to the RS

   The client and the RS runs the DTLS handshake using the raw public
   keys established in steps B and C.

   The client sends a CoAP GET request to /temperature on the RS over
   DTLS.  The RS verifies that the request is authorized based on
   previously established security context.

   F:  The RS responds over the same DTLS channel with a CoAP 2.05
      Content response containing a resource representation as payload.

              Resource
    Client     Server
       |         |
       |<=======>| DTLS Connection Establishment
       |         |   using Raw Public Keys
       |         |
       +-------->| Header: GET (Code=0.01)
       | GET     | Uri-Path: "temperature"
       |         |
       |         |
       |         |
   F:  |<--------+ Header: 2.05 Content
       | 2.05    | Payload: <sensor value>
       |         |

         Figure 15: Resource Request and Response Protected by DTLS

F.2.  Introspection Aided Token Validation

   In this deployment scenario, it is assumed that a client is not able
   to access the AS at the time of the access request, whereas the RS is
   assumed to be connected to the back-end infrastructure.  Thus, the RS
   can make use of token introspection.  This access procedure involves
   steps (A)-(F) of Figure 1 but assumes steps (A) and (B) have been
   carried out during a phase when the client had connectivity to the
   AS.

   Since the client is assumed to be offline, at least for a certain
   period of time, a preprovisioned access token has to be long lived.
   Since the client is constrained, the token will not be self-contained
   (i.e., not a CWT) but instead just a reference.  The resource server
   uses its connectivity to learn about the claims associated to the
   access token by using introspection, which is shown in the example
   below.

   In the example, interactions between an offline client (key fob), an
   RS (online lock), and an AS is shown.  It is assumed that there is a
   provisioning step where the client has access to the AS.  This
   corresponds to message exchanges A and B, which are shown in
   Figure 16.

   Authorization consent from the resource owner can be preconfigured,
   but it can also be provided via an interactive flow with the resource
   owner.  An example of this for the key fob case could be that the
   resource owner has a connected car and buys a generic key to use with
   the car.  To authorize the key fob, the owner connects it to a
   computer that then provides the UI for the device.  After that, OAuth
   2.0 implicit flow can be used to authorize the key for the car at the
   car manufacturer's AS.

   Note: In this example, the client does not know the exact door it
   will be used to access since the token request is not sent at the
   time of access.  So the scope and audience parameters are set quite
   wide to start with, while tailored values narrowing down the claims
   to the specific RS being accessed can be provided to that RS during
   an introspection step.

   A:  The client sends a CoAP POST request to the token endpoint at the
       AS.  The request contains the audience parameter set to
       "PACS1337" (Physical Access System (PACS)), a value that
       identifies the physical access control system to which the
       individual doors are connected.  The AS generates an access token
       as an opaque string, which it can match to the specific client
       and the targeted audience.  It furthermore generates a symmetric
       proof-of-possession key.  The communication security and
       authentication between the client and AS is assumed to have been
       provided at the transport layer (e.g., via DTLS) using a pre-
       shared security context (pre-shared key (PSK), RPK, or
       certificate).

   B:  The AS responds with a CoAP 2.05 Content response, containing as
       payload the Access Information, including the access token and
       the symmetric proof-of-possession key.  Communication security
       between the C and RS will be DTLS and PreSharedKey.  The PoP key
       is used as the PreSharedKey.

   Note: In this example, we are using a symmetric key for a multi-RS
   audience, which is not recommended normally (see Section 6.9).
   However, in this case, the risk is deemed to be acceptable, since all
   the doors are part of the same physical access control system;
   therefore, the risk of a malicious RS impersonating the client
   towards another RS is low.

            Authorization
    Client     Server
       |         |
       |<=======>| DTLS Connection Establishment
       |         |   and mutual authentication
       |         |
   A:  +-------->| Header: POST (Code=0.02)
       |  POST   | Uri-Path:"token"
       |         | Content-Format: application/ace+cbor
       |         | Payload: <Request-Payload>
       |         |
   B:  |<--------+ Header: 2.05 Content
       |         | Content-Format: application/ace+cbor
       |  2.05   | Payload: <Response-Payload>
       |         |

       Figure 16: Token Request and Response Using Client Credentials

   The information contained in the Request-Payload and the Response-
   Payload is shown in Figure 17.

   Request-Payload:
   {
     / client_id / 24 : "keyfob",
     / audience / 5   : "PACS1337"
   }

   Response-Payload:
   {
     / access_token / 1 : b64'VGVzdCB0b2tlbg',
     / cnf / 8 : {
       / COSE_Key / 1 : {
         / kid / 2 : b64'c29tZSBwdWJsaWMga2V5IGlk',
         / kty / 1 : 4 / Symmetric /,
         / k / -1  : b64'ZoRSOrFzN_FzUA5XKMYoVHyzff5oRJxl-IXRtztJ6uE'
       }
     }
   }

         Figure 17: Request and Response Payload for the C Offline

   In this case, the access token is just an opaque byte string
   referencing the authorization information at the AS.

   C:  Next, the client POSTs the access token to the authz-info
       endpoint in the RS.  This is a plain CoAP request, i.e., no DTLS
       between the client and RS.  Since the token is an opaque string,
       the RS cannot verify it on its own, and thus defers to respond to
       the client with a status code until after step E.

   D:  The RS sends the token to the introspection endpoint on the AS
       using a CoAP POST request.  In this example, the RS and AS are
       assumed to have performed mutual authentication using a pre-
       shared security context (PSK, RPK, or certificate) with the RS
       acting as the DTLS client.

   E:  The AS provides the introspection response (2.05 Content)
       containing parameters about the token.  This includes the
       confirmation key (cnf) parameter that allows the RS to verify the
       client's proof of possession in step F.  Note that our example in
       Figure 19 assumes a preestablished key (e.g., one used by the
       client and the RS for a previous token) that is now only
       referenced by its key identifier kid.

       After receiving message E, the RS responds to the client's POST
       in step C with the CoAP response code 2.01 (Created).

              Resource
     Client    Server
       |         |
   C:  +-------->| Header: POST (T=CON, Code=0.02)
       |  POST   | Uri-Path:"authz-info"
       |         | Payload: b64'VGVzdCB0b2tlbg'
       |         |
       |         |     Authorization
       |         |       Server
       |         |          |
       |      D: +--------->| Header: POST (Code=0.02)
       |         |  POST    | Uri-Path: "introspect"
       |         |          | Content-Format: application/ace+cbor
       |         |          | Payload: <Request-Payload>
       |         |          |
       |      E: |<---------+ Header: 2.05 Content
       |         |  2.05    | Content-Format: application/ace+cbor
       |         |          | Payload: <Response-Payload>
       |         |          |
       |         |
       |<--------+ Header: 2.01 Created
       |  2.01   |
       |         |

              Figure 18: Token Introspection for the C Offline

   The information contained in the Request-Payload and the Response-
   Payload is shown in Figure 19.

   Request-Payload:
   {
     / token /     11 : b64'VGVzdCB0b2tlbg',
     / client_id / 24 : "FrontDoor"
   }

   Response-Payload:
   {
     / active / 10 : true,
     / aud /     3 : "lockOfDoor4711",
     / scope /   9 : "open close",
     / iat /     6 : 1563454000,
     / cnf /     8 : {
            / kid / 3 : b64'c29tZSBwdWJsaWMga2V5IGlk'
     }
   }

         Figure 19: Request and Response Payload for Introspection

   The client uses the symmetric PoP key to establish a DTLS
   PreSharedKey secure connection to the RS.  The CoAP request PUT is
   sent to the uri-path /state on the RS, changing the state of the door
   to locked.

   F:  The RS responds with an appropriate response over the secure DTLS
       channel.

              Resource
     Client    Server
       |         |
       |<=======>| DTLS Connection Establishment
       |         |   using Pre Shared Key
       |         |
       +-------->| Header: PUT (Code=0.03)
       | PUT     | Uri-Path: "state"
       |         | Payload: <new state for the lock>
       |         |
   F:  |<--------+ Header: 2.04 Changed
       | 2.04    | Payload: <new state for the lock>
       |         |

        Figure 20: Resource Request and Response Protected by OSCORE

Acknowledgments

   This document is a product of the ACE Working Group of the IETF.

   Thanks to Eve Maler for her contributions to the use of OAuth 2.0 and
   Unlicensed Mobile Access (UMA) in IoT scenarios, Robert Taylor for
   his discussion input, and Mališa Vučinić for his input on the
   predecessors of this proposal.

   Thanks to the authors of "[POP-KEY-DIST]OAuth 2.0
   Proof-of-Possession: Authorization Server to Client Key Distribution"
   [POP-KEY-DIST], from where parts of the security considerations where
   copied.

   Thanks to Stefanie Gerdes, Olaf Bergmann, and Carsten Bormann for
   contributing their work on AS discovery from "Delegated CoAP
   Authentication and Authorization Framework (DCAF)" [DCAF] (see
   Section 5.1) and the considerations on multiple access tokens.

   Thanks to Jim Schaad and Mike Jones for their comprehensive reviews.

   Thanks to Benjamin Kaduk for his input on various questions related
   to this work.

   Thanks to Cigdem Sengul for some very useful review comments.

   Thanks to Carsten Bormann for contributing the text for the CoRE
   Resource Type registry.

   Thanks to Roman Danyliw for suggesting Appendix E (including its
   contents).

   Ludwig Seitz and Göran Selander worked on this document as part of
   the CelticPlus project CyberWI, with funding from Vinnova.  Ludwig
   Seitz has also received further funding for this work by Vinnova in
   the context of the CelticNext project CRITISEC.

Authors' Addresses

   Ludwig Seitz
   Combitech
   Djäknegatan 31
   SE-211 35 Malmö
   Sweden
   Email: ludwig.seitz@combitech.com

   Göran Selander
   Ericsson
   SE-164 80 Kista
   Sweden
   Email: goran.selander@ericsson.com

   Erik Wahlstroem
   Sweden
   Email: erik@wahlstromstekniska.se

   Samuel Erdtman
   Spotify AB
   Birger Jarlsgatan 61, 4tr
   SE-113 56 Stockholm
   Sweden
   Email: erdtman@spotify.com

   Hannes Tschofenig
   Arm Ltd.
   6067 Absam
   Austria
   Email: Hannes.Tschofenig@arm.com