Internet DRAFT - draft-maler-ace-oauth-uma

draft-maler-ace-oauth-uma







Network Working Group                                      H. Tschofenig
Internet-Draft                                               ARM Limited
Intended status: Informational                                  E. Maler
Expires: September 10, 2015                                    Forgerock
                                                           E. Wahlstroem
                                                              S. Erdtman
                                                        Nexus Technology
                                                           March 9, 2015


  Authentication and Authorization for Constrained Environments Using
                             OAuth and UMA
                    draft-maler-ace-oauth-uma-00.txt

Abstract

   Authentication and authorization are fundamental security features
   used in Internet and Web applications.  Providing the same level of
   security functionality to the Internet of Things (IoT) environment as
   well is a logical enhancement and reduces the risk of unauthorized
   access to personal data.

   IoT devices, however, have limitations in terms of processing power,
   memory, user interface, Internet connectivity, etc.  Since many use
   cases span Web and IoT environments and the question of "Web" vs.
   "IoT" can in some cases be considered a continuum, it is required to
   find security solutions that can accommodate the capabilities and
   constraints of both environments without significant compromises.

   Thus, an approach of adapting already standardized and deployed
   authentication and authorization technologies is worth examining.
   This document describes how the Web Authorization Protocol (OAuth) in
   combination with User-Managed Access (UMA) can be used for an IoT
   environment to bring Web-scale authorization services to the IoT
   world.

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 http://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



Tschofenig, et al.     Expires September 10, 2015               [Page 1]

Internet-Draft              OAuth/UMA for ACE                 March 2015


   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 September 10, 2015.

Copyright Notice

   Copyright (c) 2015 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
   (http://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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  Using OAuth with Scales . . . . . . . . . . . . . . . . .   4
     3.2.  Using UMA with Scales . . . . . . . . . . . . . . . . . .   6
     3.3.  Using OAuth and UMA with Cars . . . . . . . . . . . . . .   8
     3.4.  Using OAuth and UMA with Door Locks . . . . . . . . . . .   9
   4.  Protocol Designs for the Web and Beyond . . . . . . . . . . .  10
   5.  Instantiations  . . . . . . . . . . . . . . . . . . . . . . .  11
     5.1.  Car Use Case  . . . . . . . . . . . . . . . . . . . . . .  12
     5.2.  Door Lock Use Case  . . . . . . . . . . . . . . . . . . .  14
   6.  UMA Use Case Mapping Exercise . . . . . . . . . . . . . . . .  16
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  18
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  19
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  19
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  19
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  19
     10.2.  Informative References . . . . . . . . . . . . . . . . .  21
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  21

1.  Introduction

   Deciding when a certain use case falls under the category of IoT and
   when it is not turns out to be a difficult task.  For this reason,
   [RFC7228] made an attempt to describe characteristics of constrained-
   node networks and highlights some of the challenges.  Companies often



Tschofenig, et al.     Expires September 10, 2015               [Page 2]

Internet-Draft              OAuth/UMA for ACE                 March 2015


   have some degree of freedom to make trade-off decisions, for example,
   in terms of cost vs. physically available resources to push the
   boundaries of what can be done with IoT devices.

   Manufacturers must take not only hardware costs into account, but
   also software development costs; reusing existing software,
   standards, practices, and expertise can help to lower the total cost
   of a product.  Hence, the use cases combine the already existing
   identity and access management infrastructure with access control to
   objects in the physical world.

2.  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 "Key words for use in
   RFCs to Indicate Requirement Levels" [RFC2119].

   This document leverages terminology from [RFC6749] and
   [I-D.hardjono-oauth-umacore] . Especially pertinent definitions are
   paraphrased below.

   Resource Owner:  An entity capable of granting access to a protected
      resource.

   Resource Server:  The server hosting the protected resources, capable
      of accepting and responding to protected resource requests using
      access tokens.

   Authorization Server:  The server issuing access tokens to the client
      after successfully authorizing it.

   Requesting Party:  An entity (which may or may not be the same as the
      resource owner) that uses a client to seek access to a protected
      resource.

   Client:  An application making protected resource requests with the
      resource owner's authorization and on the requesting party's
      behalf.

3.  Use Cases

   The sub-sections below illustrate some use cases that start with
   classic OAuth functionality and then extend it to functionality only
   available with UMA-based environments.  The scenarios involve Web,
   smart phone app, and IoT devices.  Unlike the scenarios described in
   [I-D.ietf-ace-usecases] this write-up is not solution agnostic but




Tschofenig, et al.     Expires September 10, 2015               [Page 3]

Internet-Draft              OAuth/UMA for ACE                 March 2015


   instead aims to take the OAuth/UMA solutions into account.  In a
   stepwise refinement we then add even more details in Section 5.

3.1.  Using OAuth with Scales

   In a classic OAuth flow, an end-user (the resource owner) can enable
   a client application to call an API (at the resource server) on his
   or her behalf securely and with authorized consent, without having to
   reveal his or her credentials, such as a username and password, to
   the client.  An app-specific access token (issued by the
   authorization server at which the resource owner is able to
   authenticate), whose operation may be scoped to some subset of the
   API's capabilities, is substituted for the long-term credentials
   instead.

   The basic OAuth architecture is shown in Figure 1 and the
   corresponding message exchange in Figure 2.


                               +-------------+
                               |Authorization|
                               |Server (AS)  |\
                               +-------------+ \
                               ^        /   ^    \
                    Request   /        /     \     \     *Token
                    Access   / Access /       \     \  Introspection
                    Token   /  Token /          \     \
                           /        /            \     \
                          /        /              \      \
                         /        /                 \      \
                        /        /                   \      \
         O             /        v                     \       v
        /|\          +-----------+                  +-----------+
         |    -----> |           |   Access Token   | Resource  |
        / \   <----- |  Client   |----------------->|  Server   |
      Resource       |           |<================>|   (RS)    |
       Owner         +-----------+ Application Data +-----------+

         *: indicates optional exchange.


                       Figure 1: OAuth Architecture.









Tschofenig, et al.     Expires September 10, 2015               [Page 4]

Internet-Draft              OAuth/UMA for ACE                 March 2015


    +--------+                               +---------------+
    |        |--(A)- Authorization Request ->|   Resource    |
    |        |                               |     Owner     |
    |        |<-(B)-- Authorization Grant ---|               |
    |        |                               +---------------+
    |        |
    |        |                               +---------------+
    |        |--(C)-- Authorization Grant -->| Authorization |
    | Client |                               |     Server    |
    |        |<-(D)----- Access Token -------|               |
    |        |                               +---------------+
    |        |                                  ^ |    *Token
    |        |                               (F)| |(G) Introspection
    |        |                                  | v
    |        |                               +---------------+
    |        |--(E)----- Access Token ------>|    Resource   |
    |        |                               |     Server    |
    |        |<-(H)--- Protected Resource ---|               |
    +--------+                               +---------------+


                   Figure 2: OAuth 2.0 Message Exchange.

   We can apply a similar pattern to IoT devices as well.  For example,
   envision an end-user Alice and her new purchase of an Internet-
   connected scale designed for "quantified self" scenarios.  In our
   example, the scale has a micro-controller that was pre-provisioned
   with a certificate during manufacturing enabling the device to
   authenticate itself to the vendor-authorized software update server
   as well as to other parties.  The identifier used for authentication
   of a scale is something as benign as an EUI-64 serial number.

   Once the identifier used by the scale and Alice's account information
   have been provisioned into an online repository, and if Alice can
   demonstrate appropriate control of the device -- for example, by
   entering a confirmable PIN code or serial number that was packaged
   with the shipped device into her online account record, whether
   through a Web or mobile app -- it is possible to treat the device as
   an OAuth client and issue it an OAuth token so that it can act on
   Alice's behalf.

   The value of this association is that any API calls made by the
   scale, for example to report Alice's weight, body mass index (BMI),
   or progress against health goals into her online account, will be
   associated with her alone.  If other household members use the scale
   as well, their unique associations will ensure that their data will
   go to the right place (assuming there is a mechanism at the scale




Tschofenig, et al.     Expires September 10, 2015               [Page 5]

Internet-Draft              OAuth/UMA for ACE                 March 2015


   that allows family members to be differentiated).  Further, each
   token can be revoked and expired exactly like any other OAuth token.

3.2.  Using UMA with Scales

   UMA builds on top of OAuth (and optionally OpenID Connect [OIDC]) to
   let an end-user achieve three main goals:

   1.  authorize other parties to access APIs under his or her control
       using client applications;

   2.  set conditions for access so that those other parties may have to
       provide "claims" and do step-up authentication to get access (in
       a so-called claims gathering process); and

   3.  centralize management of all these conditions for access in one
       cloud service.

   The basic architecture and flow is shown in Figure 3.  A protection
   API token (PAT) is an OAuth token with a scope that gives the
   resource server access to the UMA-standardized protection API at the
   authorization server; an authorization API token (AAT) is an OAuth
   token with a scope that gives the client access to the UMA-
   standardized authorization API; and a requesting party token (RPT) is
   the main access token issued to a requesting party, which does not
   rely on resource owner presence for issuance.

























Tschofenig, et al.     Expires September 10, 2015               [Page 6]

Internet-Draft              OAuth/UMA for ACE                 March 2015


                                              +--------------+
                                              |   resource   |
             +---------manage (A)------------ |     owner    |
             |                                +--------------+
             |         Phase 1:                      |
             |         protect a                control (C)
             |         resource                      |
             v                                       v
      +------------+               +----------+--------------+
      |            |               |protection|              |
      |  resource  |               |   API    | authorization|
      |   server   |<-protect (B)--|  (needs  |    server    |
      |            |               |   PAT)   |              |
      +------------+               +----------+--------------+
      | protected  |                          | authorization|
      | resource   |                          |     API      |
      |(needs RPT) |                          |  (needs AAT) |
      +------------+                          +--------------+
             ^                                       |
             |         Phases 2 and 3:         authorize (D)
             |         get authorization,            |
             |         access a resource             v
             |                                +--------------+
             +---------access (E)-------------|    client    |
                                              +--------------+

                                              requesting party


                 Figure 3: OAuth++: The UMA Architecture.

   UMA can be thought of as "OAuth++", in that it adds two major
   elements: a formal protection API presented by the authorization
   server, so that resource servers running in different domains can be
   "authorization relying parties" to it, and the "requesting party"
   concept distinct from the resource owner (as discussed in Section 2).

   The requesting party may be required to interact with the
   authorization server when the client asks for permission to access a
   resource.  However, if this interaction requires authentication, this
   authentication step may be outsourced to a variety of different
   identity providers, including the client (which may be allowed to
   "push" identity claims to the authorization server), the
   authorization server itself, or any other identity provider, with the
   authorization server functioning as a relying party in this case.

   Similarly to the previous use case in Section 3.1, there is value in
   extending the Web world to the world of devices because the data



Tschofenig, et al.     Expires September 10, 2015               [Page 7]

Internet-Draft              OAuth/UMA for ACE                 March 2015


   originating in a device often travels to the cloud.  Alice may want
   to share her scale data with friends, with her doctor, or in
   anonymized form with a public health service.

   The benefit of using an UMA authorization server, requesting party
   tokens, and so on to manage Alice's control of her doctor's and
   others' access to the data her scale generates is that she:

   1.  does not have to be present when they request access, crafting
       policies prior to access attempts or handling access approval
       requests after attempts;

   2.  can demand that requesting parties present proof of their
       suitability (such as current valid hospital credentials);

   3.  can change the length permission validity, including revoking
       sharing relationships;

   4.  can set policies governing clients used by requesting parties as
       well; and

   5.  can do this from a centralizable authorization point, crossing
       multiple resource servers (and thus devices feeding into them).

3.3.  Using OAuth and UMA with Cars

   A connected car example illustrates other desirable aspects of IoT
   authentication and authorization.

   Alice buys a new car.  At manufacture time, the car was registered at
   the manufacturer's authorization server.  When buying the car, Alice
   can create an account at the manufacturer's website and reuse the
   already configured authorization server.  Alice installs a car
   managing mobile app on her phone to manage her car.  Alice authorizes
   the app to act on her behalf as OAuth client to perform actions, such
   as open car door, which would be similar to authorizing an app to
   send tweets on my behalf to the twitter API but in this case the
   resource server is the car and the API is accessed over Bluetooth
   Smart.

   Since the operation of opening the car is security sensitive, it is
   desirable to require more than a long term access token to open the
   door and to start the car.  So instead of just accepting the access
   token the authorization server may require Alice to supply more
   information and a UMA claims gathering process is started, such as
   requiring a multi-factor authentication using a fingerprint or a PIN
   code on her phone.




Tschofenig, et al.     Expires September 10, 2015               [Page 8]

Internet-Draft              OAuth/UMA for ACE                 March 2015


   Furthermore, Alice wants to share driving rights with her husband
   Ted. Alice is owner of the car and is authorized to add new drivers
   to the car.  To do this Alice can setup the policies at the
   authorization service governing who can do what with the car at what
   time.  Alice configures a rule that allows Ted to request a token for
   the scope of driving the car, but just as Alice, Ted is required to
   download the app, authorize it and go through a claims gathering flow
   to actually get the token to start the car using his smart phone app.

   With this delegation of rights to the car Ted could potentially even
   create a valet key with geo fenced driving range and no access to
   trunk when he leaves the car in a parking garage and thereby create a
   valet key for the physical world.

   The use of standardized protocols allows Alice to use her own
   authorization server.  Alice could choose to unregister the car at
   the manufacturer authorization server and register the car to an
   authorization server of her liking.  The car would register available
   resources and scopes and Alice could configure policies as above
   using her own authorization server.

   Since cars are not always located in areas with Internet connectivity
   it is envisioned that cars need to be able to verify access tokens
   locally (without the need to consult an authorization server in real-
   time).  Once the car is online again it could check whether any new
   revocation information is available and upload information about
   earlier authorization decisions to the audit log.

   A similiar situation may occur when Alice asks her friend Trudy to
   get the groceries from the trunk of her car (which she forgot there
   earlier) while they are at their remote summer cottage.  Without
   Internet connectivity Alice cannot delegate access to her car to
   Trudy using the authorization server located in the cloud.  Instead,
   she transfers an access token to Trudy using Bluetooth.  This access
   token entitles Trudy to open the trunk but not to drive it and grants
   those permissions only for a limited period.  To ensure that the car
   can actually verify the content of the access token the client app of
   Alice again uses the capabilities of the proof-of-possession tokens.

3.4.  Using OAuth and UMA with Door Locks

   Alice, the owner of a small enterprise, buys a door lock system for
   her office.  She would expect to be able to provision policies for
   access herself, in effect acting as "system administrator" for
   herself and for her five employees.  She may also want to choose her
   own authorization server, since she wants to integrate the physical
   access control system with the rest of the resources in her company
   and the enterprise identity management system she already owns.  She



Tschofenig, et al.     Expires September 10, 2015               [Page 9]

Internet-Draft              OAuth/UMA for ACE                 March 2015


   wants to control the cloud-based file system, financial and health
   data, as well as the version control and issue tracking software.

4.  Protocol Designs for the Web and Beyond

   The design of OAuth was intentionally kept flexible to accommodate
   different deployment situations.  For example, authentication of the
   resource owner to the authorization server before granting access is
   not standardized and different authentication technologies can be
   used for that purpose.  The user interface shown to the resource
   owner when asking for access to the protected resource is not
   standardized either.

   Over the years various extensions have been standardized to the core
   OAuth protocol to reduce the need for proprietary extensions that
   offer token revocation, an access token format called JSON Web Token,
   or proof-of-possession tokens that offer an alternative security
   model for bearer tokens [RFC6750].

   Due to the nature of the Web, OAuth protocol interactions have used
   HTTPS as a transport; however, other transports have been
   investigated as well, such as OAuth for use over SASL (for use with
   email) and more recently OAuth over the Constrained Application
   Protocol (CoAP).

   This document provides the reader with information about which OAuth
   extensions will be useful for the IoT context.  In its structure it
   is very similar to the DTLS/TLS IoT profile document that explains
   what TLS extensions and ciphersuites to use for different IoT
   deployment environments.  Interestingly, very little standardization
   effort is necessary to make OAuth and UMA fit for IoT.  To a large
   extend the work is centered around using alternative transports (such
   as CoAP and DTLS instead of HTTP over TLS) to minimize the on-the-
   wire overhead and to lower code-size and to define profiles for
   highly demanded use cases.

   The UMA group, benefiting from observing the OAuth experience and
   from the era in which UMA itself has been developed, has built
   extension points into the protocol, already anticipating a need for
   flexibility in transport bindings.  Thus, UMA has three
   "extensibility profiles" that enable alternate bindings (such as
   CoAP) to be defined for communications between an authorization
   server and resource server, a resource server and client, and an
   authorization server and client respectively.  It also, similarly to
   OAuth, as other extensibility options, such as token profiling and
   the ability to extend JSON formats to suit a variety of deployment
   needs.




Tschofenig, et al.     Expires September 10, 2015              [Page 10]

Internet-Draft              OAuth/UMA for ACE                 March 2015


5.  Instantiations

   In this section we provide additional details about the use of OAuth
   and UMA for solving the use cases outlined in Section 3.  In general,
   the following specifications are utilized:

   o  OAuth 2.0 [RFC6749] for interacting with the authorization server.
      The use of the CoAP-OAuth profile [I-D.tschofenig-ace-oauth-iot]
      maybe used but is not essential for the examples in this section
      since the client is less constrained.

   o  Bearer tokens and proof-of-possession tokens as two different
      security models for obtaining and presenting access tokens.
      Bearer tokens are defined in [RFC6750] and the architecture for
      proof-of-possession (PoP) tokens can be found at
      [I-D.ietf-oauth-pop-architecture].  PoP tokens introduce the
      ability to bind credentials, such as an ephemeral public key, to
      the access token.

   o  UMA [I-D.hardjono-oauth-umacore] for registering the resource
      server with the authorization server provided by Alice and for
      management of policy.

   o  Dynamic Client Registration [I-D.ietf-oauth-dyn-reg] for the
      client app to register at the authorization server.

   o  Token introspection [I-D.ietf-oauth-introspection] for optionally
      allowing the resource server to verify the validity of the access
      token (if this step is not done locally at the resource server).
      The use of token introspection over CoAP
      [I-D.wahlstroem-ace-oauth-introspection] reduces overhead.

   o  JSON Web Token (JWT) [I-D.ietf-oauth-json-web-token] for the
      format of the access token.  JSON Web Signatures (JWT)
      [I-D.ietf-jose-json-web-signature] are used for creating a
      signature over the JWT.  The use of a CBOR encoding of various
      JSON-based security specifications is under discussion to reduce
      the size of JSON-based tokens.

   o  A new Bluetooth Smart service and profile for conveying access
      tokens securely from the client to the resource server.  If CoAP
      runs between the client and a constrained resouce server then
      [I-D.tschofenig-ace-oauth-bt] provides additional overhead
      reduction.







Tschofenig, et al.     Expires September 10, 2015              [Page 11]

Internet-Draft              OAuth/UMA for ACE                 March 2015


5.1.  Car Use Case

   In the car use case, as described in Section 3.3, the car acts as the
   resource server and an application on the smart phone plays the role
   of the client.  Alice is first a delegated administrator then becomes
   a resource owner of the car.

   Alice creates an account, downloads and authorizes the mobile app:

   1.  Alice creates an account on manufacturer's website.

   2.  Alice selects that two factor authentication must be used to be
       able to start controlling car from an app.

   3.  Alice downloads app and starts it.

   4.  App has never been provisioned so a browser is started, user
       selects manufacturer's authorization server from a list.

   5.  Alice authenticates using two factors and authorizes the
       application.

   6.  Access and refresh tokens are provisioned to the app.

   Alice configures policies to add Tim as new driver:

   1.  Alice opens the car-settings page within the app.

   2.  Alice selects to add a new driver by supplying Tims email
       address.

   3.  Alice checks the checkboxes that also makes Tim a delegated
       administrator.

   4.  Alice saves the new policies.

   Alice opens car door over Bluetooth Smart:

   1.   The smartphone detects the advertising packets of the door lock
        and asks Alice whether she wants to open the car door.

   2.   Alice confirms and a request is sent to the authorization server
        together with an ephemeral public key created by the phone.  The
        request indicates information about the car Alice is seeking
        access to.

   3.   The authorization server evaluates the request to open the car
        door on the specific car and verifies it against the access



Tschofenig, et al.     Expires September 10, 2015              [Page 12]

Internet-Draft              OAuth/UMA for ACE                 March 2015


        control policy.  Note that the app authenticated itself to the
        authorization server.

   4.   The authorization server prompts Alice for a PIN code using
        claims gathering.

   5.   Alice enters pin and the application communicates it to the
        authorization server.

   6.   It turns out that the system administrator has granted her
        access to that specific car and she is given access by returning
        an access token.

   7.   The smart phone app then uses the obtained access token to
        create a request (which includes the access token) over
        Bluetooth Smart using on the (not yet existing) Physical Access
        Control Profile, which is a security protocol that utilizes
        public key cryptography where the app demonstrates that it knows
        the private key corresponding to the finger of the public key
        found in the token.

   8.   The car receives the request and verifies it.

   9.   To check whether the permissions are still valid the car sends
        the access token to the introspection endpoint.

   10.  The authorization server validates the access token and returns
        information about the validity of the token to the car.  In this
        case it's a valid token.

   11.  The request is logged.

   12.  The car gets a response and opens the car door.

   Alice changes authorization server:

   1.  Alice wants to connect the car to her own authorization server
       instead of the manufacturers default authorization server.

   2.  Alice makes a request to the current authorization server to
       unbind the device from the authorization server.

   3.  The authorization server validates Alice request to remove the
       authorization server.

   4.  Alice configures a new authorization server in the apps UI.





Tschofenig, et al.     Expires September 10, 2015              [Page 13]

Internet-Draft              OAuth/UMA for ACE                 March 2015


   5.  The app starts an authorization code grant flow with the private
       authorization server of Alice.  Alice logs on and authorizes the
       app to act on her behalf.

   6.  The app sends information about the new authorization server to
       the car using Bluetooth Smart.

   7.  The car registers the resource it offers with the new
       authorization server.

   8.  Alice configures herself as the car owner in the new
       authorization server.

   9.  The car unbinds itself from the old authorization server by
       invalidating the access tokens using the revocation endpoint.

5.2.  Door Lock Use Case

   In the constrained server use case, as described in Section 3.4, the
   door lock acts as the resource server and an application on the smart
   phone plays the role of the client.

   Since the client runs on a powerful smartphone standard OAuth
   according to OAuth Core can be used.  To avoid leakage of the access
   token the use of a proof-of-possession token is utilized instead of a
   bearer token.  This allows the client to demonstrate the possession
   of the private key to the client.  Both symmetric as well as
   asymmetric cryptography can be used.  The use of asymmetric
   cryptography is beneficial since it allows the client to create a
   public / private key pair and to never expose the private key to
   other parties.

   As a setup-step the following steps are taken as part of the
   enterprise IT

   1.  Alice, as the enterprise network administrator and compay owner,
       enables the physical access control rights at the identity
       management server.

   2.  Alice downloads the enterprise physical access control system app
       on her phone.  By downloading the app she agrees to the terms of
       use and she accepts the permissions being asked for by the app.

   3.  Alice associates her smart phone app with her account by login
       into the enterprise management software, which uses OAuth 2.0 for
       delegating access to the app.





Tschofenig, et al.     Expires September 10, 2015              [Page 14]

Internet-Draft              OAuth/UMA for ACE                 March 2015


   4.  Alice, as the enterprise administrator, configures policies at
       the authorization server to give her employees access to the
       office building as well.

   5.  In this use case each door lock is provisioned with an asymmetric
       key pair and the public key of the authorization server.  The
       public key of each door lock is registered with the authorization
       server.  Door locks use these keys when interacting with the
       authorization server (for authentication in case of token
       introspection), for authenticating towards the client, and for
       verifying the signature computed over the access token.

   When Alice uses her smartphone for the first time to access the
   office building the following steps take place:

   1.  The smartphone detects the advertising packets of the door lock
       and asks Alice whether she wants access.

   2.  Alice confirms and a request is sent to the authorization server
       together with an ephemeral public key created by the phone.  The
       request indicates information about the door Alice is seeking
       access to.  The request is protected using TLS.

   3.  The authorization server evaluates the request and verifies it
       against the access control policy.  Since Alice has added herself
       to access control policies already she is given access by
       returning an access token.  This access token includes the
       fingerprint of the public key provided in the request.  The
       access token is digitally signed to avoid any modification of the
       content.

   4.  The smart phone app then uses the obtained information to create
       a request (which includes the access token) over Bluetooth Smart
       using the (not yet existing) Physical Access Control Profile,
       which is a security protocol that utilizes public key
       cryptography where the app demonstrates that it knows the private
       key corresponding to the finger of the public key found in the
       token.

   5.  The door lock software receives the request and verifies the
       digital signature, inspects the content (such as expiry date, and
       scope), and determines whether the fingerprint of the public key
       corresponds to the private key used by the client.  Once
       successfully verified the door is unlocked, and Alice is allowed
       to enter.

   6.  The physical access control app caches the access token for
       future use.



Tschofenig, et al.     Expires September 10, 2015              [Page 15]

Internet-Draft              OAuth/UMA for ACE                 March 2015


   As a variation of the above-described procedure, the door lock might
   consult the authorization server using token introspection to
   determine the validity of the access token.  This allows the
   enterprise system software to make real-time access control decisions
   and to better gain visibility about the number of employees in the
   building (in case of an emergency).

   When Alice approaches the door next time her physical access control
   app determines that a cached (and still valid) access token is
   available and no further interaction with the authorization server is
   needed.  Decisions about how long to cache access tokens are a policy
   decision configurable into the system and impact the performance of
   the protocol execution.

   When Bob, who is employed by Alice, approaches the office building
   for the first time his downloaded physical access control app also
   interacts with the door.  While Bob still has to consent to the use
   of app, Alice does not need to authorize access of Bob to the office
   building in real-time since she has already granted access to her
   employees earlier already.

6.  UMA Use Case Mapping Exercise

   An analysis of [I-D.hardjono-oauth-umacore] suggests that its
   capabilities have a good architectural match with many published ACE
   use cases.  The following are aggregated and paraphrased versions of
   use cases discussed in [I-D.ietf-ace-usecases]:

   Owner grants different resource access rights to different parties
   (U1.1, U2.3, U.3.2):

      UMA meets this use case because the requesting party is formally
      distinct from the resource owner and because each requesting
      party, and each client, is represented distinctly at each
      authorization server, able to have differential policy applied to
      it.

   Owner grants different access rights for different resources on a
   device (U1.3, U4.4, U5.2):

      UMA meets this use case because the resource server is able to
      register each resource set (according to boundaries it
      unilaterally determines) at the authorization server, so that the
      resource owner can apply policy to it distinctly.

   Owner not always present at time of access (U1.6, U5.5):





Tschofenig, et al.     Expires September 10, 2015              [Page 16]

Internet-Draft              OAuth/UMA for ACE                 March 2015


      UMA meets this use case because it is a profile of OAuth that
      defines an asynchronous authorization grant, meaning that the
      client's interactions during a resource access attempt do not
      require a resource owner's interaction.

   Owner grants temporary access permissions to a party (U1.7):

      UMA meets this use case because the default, mandatory-to-
      implement permissions associated with a requesting party token
      (the "bearer" profile) are able to be time-limited and are in a
      time-limitable JSON Web Token as well.

   Owner applies verifiable context-based conditions to authorizations
   (U2.4, U4.5, U6.3):

      UMA meets this use case because a resource owner can configure an
      authorization server with policies, or an authorization server can
      apply system-default policies, to demand "trust elevation" when a
      client requests authorization data, such that a requesting party
      or client must satisfy authentication, claims-based, or (through
      extension) any other criteria prior to being issued authorization
      data.

   Owner preconfigures access rights to specific data (U3.1, U6.3):

      UMA meets this use case because it defines an asynchronous
      authorization grant, as described above.  Preconfiguration is a
      case when a resource owner sets policy prior to an access attempt.

   Owner adds a new device under protection (U4.1):

      UMA meets this use case because it enables a resource owner to
      associate a device and its corresponding resource server with an
      authorization server through consenting to the issuance of a
      protection API token (PAT), enabling the resource server to
      outsource protection of its resources to the authorization server.

   Owner puts a previously owned device under protection (U4.2):

      UMA meets this use case because a previous resource owner can
      revoke a pre-existing PAT if one existed, revoking the previous
      consent in place, and the new owner can mint a new PAT.

   Owner removes a device from protection (U4.3):

      UMA meets this use case because the resource owner can revoke the
      PAT.




Tschofenig, et al.     Expires September 10, 2015              [Page 17]

Internet-Draft              OAuth/UMA for ACE                 March 2015


   Owner revokes permissions (U4.6):

      UMA meets this use case because the resource owner can configure
      the authorization server to revoke or terminate an existing
      permission.  The default, mandatory-to-implement requesting party
      token profile ("bearer") requires runtime token introspection,
      ensuring relatively timely retrieval of a revoked permission
      (barring authorization server caching policy).  Other profiles may
      have different results.

   Owner grants access only to authentic, authorized clients (U7.1,
   U7.2):

      UMA meets this use case because it enables OAuth as well as OpenID
      Connect authentication of clients, including dynamic
      authentication, and also enables resource owners to configure
      authorization servers with policy, such that only desired clients
      wielded by desired requesting parties are given access to the
      owner's resources.

7.  Security Considerations

   This specification re-uses several existing specifications, including
   OAuth and UMA, and hence the security-related discussion in those
   documents is applicable to this specification.  A reader is
   encouraged to consult [RFC6819] for a discussion of security threats
   in OAuth and ways to mitigate them.  On a high level, the security
   guidance provided in [I-D.iab-smart-object-architecture] will help to
   improve security of Internet of Things devices in general.

   Despite all the available guidance it is nevertheless worthwhile to
   repeat the most important aspects regarding the use of access tokens,
   which are a core security mechanism in the OAuth / UMA
   specifications.

   Safeguard bearer tokens:  Client implementations MUST ensure that
      bearer tokens are not leaked to unintended parties, as they will
      be able to use them to gain access to protected resources.  This
      is the primary security consideration when using bearer tokens and
      underlies all the more specific recommendations that follow.  This
      document also outlines the use of proof-of-possessions, which
      provide stronger security properties than bearer tokens and their
      use is RECOMMENDED.

   Validate TLS certificates:  TLS/DTLS clients MUST validate the
      certificates received during the handshaking procedure.  TLS/DTLS
      is used heavily in OAuth/UMA between various parties.  Failure to
      verify certificates will enable man-in-the-middle attacks.



Tschofenig, et al.     Expires September 10, 2015              [Page 18]

Internet-Draft              OAuth/UMA for ACE                 March 2015


   Always use TLS/DTLS:  The use of TLS/DTLS is mandatory for use with
      OAuth as a default.  Particularly when bearer tokens are exchanged
      the communication interaction MUST experience communication
      security protectoin using TLS (or DTLS).  Failing to do so exposes
      bearer tokens to third parties and could consequently give
      attackers unintended access.  Proof-of-possession tokens on the
      other hand do not necessarily require the use of TLS/DTLS but TLS/
      DTLS is RECOMMENDED even in those cases since TLS/DTLS offers many
      desireable security properties, such as authentication of the
      server side.

   Issue short-lived tokens:  Authorization servers SHOULD issue short-
      lived tokens.  Using short-lived bearer tokens reduces the impact
      of them being leaked and allows easier revocation in scenarios
      where resource servers are offline.

   Issue scoped tokens:  Authorization servers MUST issue tokens that
      restrict tokens for use with a specific resource server and
      contains appropriate entitlements to control access in a fine-
      grained fashion.

8.  IANA Considerations

   This document does not require actions by IANA.

9.  Acknowledgements

   This is the first version of the document.  We appreciate feedback.

10.  References

10.1.  Normative References

   [I-D.hardjono-oauth-umacore]
              Hardjono, T., Maler, E., Machulak, M., and D. Catalano,
              "User-Managed Access (UMA) Profile of OAuth 2.0", draft-
              hardjono-oauth-umacore-12 (work in progress), February
              2015.

   [I-D.ietf-jose-json-web-signature]
              Jones, M., Bradley, J., and N. Sakimura, "JSON Web
              Signature (JWS)", draft-ietf-jose-json-web-signature-41
              (work in progress), January 2015.








Tschofenig, et al.     Expires September 10, 2015              [Page 19]

Internet-Draft              OAuth/UMA for ACE                 March 2015


   [I-D.ietf-oauth-dyn-reg]
              ietf@justin.richer.org, i., Jones, M., Bradley, J.,
              Machulak, M., and P. Hunt, "OAuth 2.0 Dynamic Client
              Registration Protocol", draft-ietf-oauth-dyn-reg-24 (work
              in progress), February 2015.

   [I-D.ietf-oauth-introspection]
              ietf@justin.richer.org, i., "OAuth 2.0 Token
              Introspection", draft-ietf-oauth-introspection-05 (work in
              progress), February 2015.

   [I-D.ietf-oauth-json-web-token]
              Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
              (JWT)", draft-ietf-oauth-json-web-token-32 (work in
              progress), December 2014.

   [I-D.ietf-oauth-pop-architecture]
              Hunt, P., ietf@justin.richer.org, i., Mills, W., Mishra,
              P., and H. Tschofenig, "OAuth 2.0 Proof-of-Possession
              (PoP) Security Architecture", draft-ietf-oauth-pop-
              architecture-01 (work in progress), March 2015.

   [I-D.tschofenig-ace-oauth-bt]
              Tschofenig, H., "The OAuth 2.0 Bearer Token Usage over the
              Constrained Application Protocol (CoAP)", draft-
              tschofenig-ace-oauth-bt-01 (work in progress), March 2015.

   [I-D.tschofenig-ace-oauth-iot]
              Tschofenig, H., "The OAuth 2.0 Internet of Things (IoT)
              Client Credentials Grant", draft-tschofenig-ace-oauth-
              iot-01 (work in progress), March 2015.

   [I-D.wahlstroem-ace-oauth-introspection]
              Wahlstroem, E., "OAuth 2.0 Introspection over the
              Constrained Application Protocol (CoAP)", draft-
              wahlstroem-ace-oauth-introspection-00 (work in progress),
              October 2014.

   [OIDC]     Sakimura, N., "OpenID Connect Core 1.0 incorporating
              Errata Set 1",
              http://openid.net/specs/openid-connect-core-1_0.html,
              November 2014.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC6749]  Hardt, D., "The OAuth 2.0 Authorization Framework", RFC
              6749, October 2012.



Tschofenig, et al.     Expires September 10, 2015              [Page 20]

Internet-Draft              OAuth/UMA for ACE                 March 2015


   [RFC6750]  Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
              Framework: Bearer Token Usage", RFC 6750, October 2012.

   [RFC6819]  Lodderstedt, T., McGloin, M., and P. Hunt, "OAuth 2.0
              Threat Model and Security Considerations", RFC 6819,
              January 2013.

   [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
              Application Protocol (CoAP)", RFC 7252, June 2014.

10.2.  Informative References

   [I-D.iab-smart-object-architecture]
              Tschofenig, H., Arkko, J., Thaler, D., and D. McPherson,
              "Architectural Considerations in Smart Object Networking",
              draft-iab-smart-object-architecture-06 (work in progress),
              October 2014.

   [I-D.ietf-ace-usecases]
              Seitz, L., Gerdes, S., Selander, G., Mani, M., and S.
              Kumar, "ACE use cases", draft-ietf-ace-usecases-02 (work
              in progress), February 2015.

   [RFC7228]  Bormann, C., Ersue, M., and A. Keranen, "Terminology for
              Constrained-Node Networks", RFC 7228, May 2014.

Authors' Addresses

   Hannes Tschofenig
   ARM Limited
   Austria

   Email: Hannes.Tschofenig@gmx.net
   URI:   http://www.tschofenig.priv.at


   Eve Maler
   Forgerock

   Email: eve.maler@forgerock.com


   Erik Wahlstroem
   Nexus Technology
   Sweden

   Email: erik.wahlstrom@nexusgroup.com
   URI:   https://www.nexusgroup.com



Tschofenig, et al.     Expires September 10, 2015              [Page 21]

Internet-Draft              OAuth/UMA for ACE                 March 2015


   Samuel Erdtman
   Nexus Technology
   Sweden

   Email: samuel.erdtman@nexusgroup.com
   URI:   https://www.nexusgroup.com













































Tschofenig, et al.     Expires September 10, 2015              [Page 22]