idnits 2.17.1 draft-maler-ace-oauth-uma-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 9, 2015) is 3334 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC7252' is defined on line 929, but no explicit reference was found in the text == Outdated reference: A later version (-14) exists of draft-hardjono-oauth-umacore-12 == Outdated reference: A later version (-30) exists of draft-ietf-oauth-dyn-reg-24 == Outdated reference: A later version (-11) exists of draft-ietf-oauth-introspection-05 == Outdated reference: A later version (-08) exists of draft-ietf-oauth-pop-architecture-01 == Outdated reference: A later version (-01) exists of draft-wahlstroem-ace-oauth-introspection-00 == Outdated reference: A later version (-10) exists of draft-ietf-ace-usecases-02 Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Tschofenig 3 Internet-Draft ARM Limited 4 Intended status: Informational E. Maler 5 Expires: September 10, 2015 Forgerock 6 E. Wahlstroem 7 S. Erdtman 8 Nexus Technology 9 March 9, 2015 11 Authentication and Authorization for Constrained Environments Using 12 OAuth and UMA 13 draft-maler-ace-oauth-uma-00.txt 15 Abstract 17 Authentication and authorization are fundamental security features 18 used in Internet and Web applications. Providing the same level of 19 security functionality to the Internet of Things (IoT) environment as 20 well is a logical enhancement and reduces the risk of unauthorized 21 access to personal data. 23 IoT devices, however, have limitations in terms of processing power, 24 memory, user interface, Internet connectivity, etc. Since many use 25 cases span Web and IoT environments and the question of "Web" vs. 26 "IoT" can in some cases be considered a continuum, it is required to 27 find security solutions that can accommodate the capabilities and 28 constraints of both environments without significant compromises. 30 Thus, an approach of adapting already standardized and deployed 31 authentication and authorization technologies is worth examining. 32 This document describes how the Web Authorization Protocol (OAuth) in 33 combination with User-Managed Access (UMA) can be used for an IoT 34 environment to bring Web-scale authorization services to the IoT 35 world. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on September 10, 2015. 54 Copyright Notice 56 Copyright (c) 2015 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 72 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 73 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 74 3.1. Using OAuth with Scales . . . . . . . . . . . . . . . . . 4 75 3.2. Using UMA with Scales . . . . . . . . . . . . . . . . . . 6 76 3.3. Using OAuth and UMA with Cars . . . . . . . . . . . . . . 8 77 3.4. Using OAuth and UMA with Door Locks . . . . . . . . . . . 9 78 4. Protocol Designs for the Web and Beyond . . . . . . . . . . . 10 79 5. Instantiations . . . . . . . . . . . . . . . . . . . . . . . 11 80 5.1. Car Use Case . . . . . . . . . . . . . . . . . . . . . . 12 81 5.2. Door Lock Use Case . . . . . . . . . . . . . . . . . . . 14 82 6. UMA Use Case Mapping Exercise . . . . . . . . . . . . . . . . 16 83 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 84 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 85 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 86 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 87 10.1. Normative References . . . . . . . . . . . . . . . . . . 19 88 10.2. Informative References . . . . . . . . . . . . . . . . . 21 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 91 1. Introduction 93 Deciding when a certain use case falls under the category of IoT and 94 when it is not turns out to be a difficult task. For this reason, 95 [RFC7228] made an attempt to describe characteristics of constrained- 96 node networks and highlights some of the challenges. Companies often 97 have some degree of freedom to make trade-off decisions, for example, 98 in terms of cost vs. physically available resources to push the 99 boundaries of what can be done with IoT devices. 101 Manufacturers must take not only hardware costs into account, but 102 also software development costs; reusing existing software, 103 standards, practices, and expertise can help to lower the total cost 104 of a product. Hence, the use cases combine the already existing 105 identity and access management infrastructure with access control to 106 objects in the physical world. 108 2. Terminology 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in "Key words for use in 113 RFCs to Indicate Requirement Levels" [RFC2119]. 115 This document leverages terminology from [RFC6749] and 116 [I-D.hardjono-oauth-umacore] . Especially pertinent definitions are 117 paraphrased below. 119 Resource Owner: An entity capable of granting access to a protected 120 resource. 122 Resource Server: The server hosting the protected resources, capable 123 of accepting and responding to protected resource requests using 124 access tokens. 126 Authorization Server: The server issuing access tokens to the client 127 after successfully authorizing it. 129 Requesting Party: An entity (which may or may not be the same as the 130 resource owner) that uses a client to seek access to a protected 131 resource. 133 Client: An application making protected resource requests with the 134 resource owner's authorization and on the requesting party's 135 behalf. 137 3. Use Cases 139 The sub-sections below illustrate some use cases that start with 140 classic OAuth functionality and then extend it to functionality only 141 available with UMA-based environments. The scenarios involve Web, 142 smart phone app, and IoT devices. Unlike the scenarios described in 143 [I-D.ietf-ace-usecases] this write-up is not solution agnostic but 144 instead aims to take the OAuth/UMA solutions into account. In a 145 stepwise refinement we then add even more details in Section 5. 147 3.1. Using OAuth with Scales 149 In a classic OAuth flow, an end-user (the resource owner) can enable 150 a client application to call an API (at the resource server) on his 151 or her behalf securely and with authorized consent, without having to 152 reveal his or her credentials, such as a username and password, to 153 the client. An app-specific access token (issued by the 154 authorization server at which the resource owner is able to 155 authenticate), whose operation may be scoped to some subset of the 156 API's capabilities, is substituted for the long-term credentials 157 instead. 159 The basic OAuth architecture is shown in Figure 1 and the 160 corresponding message exchange in Figure 2. 162 +-------------+ 163 |Authorization| 164 |Server (AS) |\ 165 +-------------+ \ 166 ^ / ^ \ 167 Request / / \ \ *Token 168 Access / Access / \ \ Introspection 169 Token / Token / \ \ 170 / / \ \ 171 / / \ \ 172 / / \ \ 173 / / \ \ 174 O / v \ v 175 /|\ +-----------+ +-----------+ 176 | -----> | | Access Token | Resource | 177 / \ <----- | Client |----------------->| Server | 178 Resource | |<================>| (RS) | 179 Owner +-----------+ Application Data +-----------+ 181 *: indicates optional exchange. 183 Figure 1: OAuth Architecture. 185 +--------+ +---------------+ 186 | |--(A)- Authorization Request ->| Resource | 187 | | | Owner | 188 | |<-(B)-- Authorization Grant ---| | 189 | | +---------------+ 190 | | 191 | | +---------------+ 192 | |--(C)-- Authorization Grant -->| Authorization | 193 | Client | | Server | 194 | |<-(D)----- Access Token -------| | 195 | | +---------------+ 196 | | ^ | *Token 197 | | (F)| |(G) Introspection 198 | | | v 199 | | +---------------+ 200 | |--(E)----- Access Token ------>| Resource | 201 | | | Server | 202 | |<-(H)--- Protected Resource ---| | 203 +--------+ +---------------+ 205 Figure 2: OAuth 2.0 Message Exchange. 207 We can apply a similar pattern to IoT devices as well. For example, 208 envision an end-user Alice and her new purchase of an Internet- 209 connected scale designed for "quantified self" scenarios. In our 210 example, the scale has a micro-controller that was pre-provisioned 211 with a certificate during manufacturing enabling the device to 212 authenticate itself to the vendor-authorized software update server 213 as well as to other parties. The identifier used for authentication 214 of a scale is something as benign as an EUI-64 serial number. 216 Once the identifier used by the scale and Alice's account information 217 have been provisioned into an online repository, and if Alice can 218 demonstrate appropriate control of the device -- for example, by 219 entering a confirmable PIN code or serial number that was packaged 220 with the shipped device into her online account record, whether 221 through a Web or mobile app -- it is possible to treat the device as 222 an OAuth client and issue it an OAuth token so that it can act on 223 Alice's behalf. 225 The value of this association is that any API calls made by the 226 scale, for example to report Alice's weight, body mass index (BMI), 227 or progress against health goals into her online account, will be 228 associated with her alone. If other household members use the scale 229 as well, their unique associations will ensure that their data will 230 go to the right place (assuming there is a mechanism at the scale 231 that allows family members to be differentiated). Further, each 232 token can be revoked and expired exactly like any other OAuth token. 234 3.2. Using UMA with Scales 236 UMA builds on top of OAuth (and optionally OpenID Connect [OIDC]) to 237 let an end-user achieve three main goals: 239 1. authorize other parties to access APIs under his or her control 240 using client applications; 242 2. set conditions for access so that those other parties may have to 243 provide "claims" and do step-up authentication to get access (in 244 a so-called claims gathering process); and 246 3. centralize management of all these conditions for access in one 247 cloud service. 249 The basic architecture and flow is shown in Figure 3. A protection 250 API token (PAT) is an OAuth token with a scope that gives the 251 resource server access to the UMA-standardized protection API at the 252 authorization server; an authorization API token (AAT) is an OAuth 253 token with a scope that gives the client access to the UMA- 254 standardized authorization API; and a requesting party token (RPT) is 255 the main access token issued to a requesting party, which does not 256 rely on resource owner presence for issuance. 258 +--------------+ 259 | resource | 260 +---------manage (A)------------ | owner | 261 | +--------------+ 262 | Phase 1: | 263 | protect a control (C) 264 | resource | 265 v v 266 +------------+ +----------+--------------+ 267 | | |protection| | 268 | resource | | API | authorization| 269 | server |<-protect (B)--| (needs | server | 270 | | | PAT) | | 271 +------------+ +----------+--------------+ 272 | protected | | authorization| 273 | resource | | API | 274 |(needs RPT) | | (needs AAT) | 275 +------------+ +--------------+ 276 ^ | 277 | Phases 2 and 3: authorize (D) 278 | get authorization, | 279 | access a resource v 280 | +--------------+ 281 +---------access (E)-------------| client | 282 +--------------+ 284 requesting party 286 Figure 3: OAuth++: The UMA Architecture. 288 UMA can be thought of as "OAuth++", in that it adds two major 289 elements: a formal protection API presented by the authorization 290 server, so that resource servers running in different domains can be 291 "authorization relying parties" to it, and the "requesting party" 292 concept distinct from the resource owner (as discussed in Section 2). 294 The requesting party may be required to interact with the 295 authorization server when the client asks for permission to access a 296 resource. However, if this interaction requires authentication, this 297 authentication step may be outsourced to a variety of different 298 identity providers, including the client (which may be allowed to 299 "push" identity claims to the authorization server), the 300 authorization server itself, or any other identity provider, with the 301 authorization server functioning as a relying party in this case. 303 Similarly to the previous use case in Section 3.1, there is value in 304 extending the Web world to the world of devices because the data 305 originating in a device often travels to the cloud. Alice may want 306 to share her scale data with friends, with her doctor, or in 307 anonymized form with a public health service. 309 The benefit of using an UMA authorization server, requesting party 310 tokens, and so on to manage Alice's control of her doctor's and 311 others' access to the data her scale generates is that she: 313 1. does not have to be present when they request access, crafting 314 policies prior to access attempts or handling access approval 315 requests after attempts; 317 2. can demand that requesting parties present proof of their 318 suitability (such as current valid hospital credentials); 320 3. can change the length permission validity, including revoking 321 sharing relationships; 323 4. can set policies governing clients used by requesting parties as 324 well; and 326 5. can do this from a centralizable authorization point, crossing 327 multiple resource servers (and thus devices feeding into them). 329 3.3. Using OAuth and UMA with Cars 331 A connected car example illustrates other desirable aspects of IoT 332 authentication and authorization. 334 Alice buys a new car. At manufacture time, the car was registered at 335 the manufacturer's authorization server. When buying the car, Alice 336 can create an account at the manufacturer's website and reuse the 337 already configured authorization server. Alice installs a car 338 managing mobile app on her phone to manage her car. Alice authorizes 339 the app to act on her behalf as OAuth client to perform actions, such 340 as open car door, which would be similar to authorizing an app to 341 send tweets on my behalf to the twitter API but in this case the 342 resource server is the car and the API is accessed over Bluetooth 343 Smart. 345 Since the operation of opening the car is security sensitive, it is 346 desirable to require more than a long term access token to open the 347 door and to start the car. So instead of just accepting the access 348 token the authorization server may require Alice to supply more 349 information and a UMA claims gathering process is started, such as 350 requiring a multi-factor authentication using a fingerprint or a PIN 351 code on her phone. 353 Furthermore, Alice wants to share driving rights with her husband 354 Ted. Alice is owner of the car and is authorized to add new drivers 355 to the car. To do this Alice can setup the policies at the 356 authorization service governing who can do what with the car at what 357 time. Alice configures a rule that allows Ted to request a token for 358 the scope of driving the car, but just as Alice, Ted is required to 359 download the app, authorize it and go through a claims gathering flow 360 to actually get the token to start the car using his smart phone app. 362 With this delegation of rights to the car Ted could potentially even 363 create a valet key with geo fenced driving range and no access to 364 trunk when he leaves the car in a parking garage and thereby create a 365 valet key for the physical world. 367 The use of standardized protocols allows Alice to use her own 368 authorization server. Alice could choose to unregister the car at 369 the manufacturer authorization server and register the car to an 370 authorization server of her liking. The car would register available 371 resources and scopes and Alice could configure policies as above 372 using her own authorization server. 374 Since cars are not always located in areas with Internet connectivity 375 it is envisioned that cars need to be able to verify access tokens 376 locally (without the need to consult an authorization server in real- 377 time). Once the car is online again it could check whether any new 378 revocation information is available and upload information about 379 earlier authorization decisions to the audit log. 381 A similiar situation may occur when Alice asks her friend Trudy to 382 get the groceries from the trunk of her car (which she forgot there 383 earlier) while they are at their remote summer cottage. Without 384 Internet connectivity Alice cannot delegate access to her car to 385 Trudy using the authorization server located in the cloud. Instead, 386 she transfers an access token to Trudy using Bluetooth. This access 387 token entitles Trudy to open the trunk but not to drive it and grants 388 those permissions only for a limited period. To ensure that the car 389 can actually verify the content of the access token the client app of 390 Alice again uses the capabilities of the proof-of-possession tokens. 392 3.4. Using OAuth and UMA with Door Locks 394 Alice, the owner of a small enterprise, buys a door lock system for 395 her office. She would expect to be able to provision policies for 396 access herself, in effect acting as "system administrator" for 397 herself and for her five employees. She may also want to choose her 398 own authorization server, since she wants to integrate the physical 399 access control system with the rest of the resources in her company 400 and the enterprise identity management system she already owns. She 401 wants to control the cloud-based file system, financial and health 402 data, as well as the version control and issue tracking software. 404 4. Protocol Designs for the Web and Beyond 406 The design of OAuth was intentionally kept flexible to accommodate 407 different deployment situations. For example, authentication of the 408 resource owner to the authorization server before granting access is 409 not standardized and different authentication technologies can be 410 used for that purpose. The user interface shown to the resource 411 owner when asking for access to the protected resource is not 412 standardized either. 414 Over the years various extensions have been standardized to the core 415 OAuth protocol to reduce the need for proprietary extensions that 416 offer token revocation, an access token format called JSON Web Token, 417 or proof-of-possession tokens that offer an alternative security 418 model for bearer tokens [RFC6750]. 420 Due to the nature of the Web, OAuth protocol interactions have used 421 HTTPS as a transport; however, other transports have been 422 investigated as well, such as OAuth for use over SASL (for use with 423 email) and more recently OAuth over the Constrained Application 424 Protocol (CoAP). 426 This document provides the reader with information about which OAuth 427 extensions will be useful for the IoT context. In its structure it 428 is very similar to the DTLS/TLS IoT profile document that explains 429 what TLS extensions and ciphersuites to use for different IoT 430 deployment environments. Interestingly, very little standardization 431 effort is necessary to make OAuth and UMA fit for IoT. To a large 432 extend the work is centered around using alternative transports (such 433 as CoAP and DTLS instead of HTTP over TLS) to minimize the on-the- 434 wire overhead and to lower code-size and to define profiles for 435 highly demanded use cases. 437 The UMA group, benefiting from observing the OAuth experience and 438 from the era in which UMA itself has been developed, has built 439 extension points into the protocol, already anticipating a need for 440 flexibility in transport bindings. Thus, UMA has three 441 "extensibility profiles" that enable alternate bindings (such as 442 CoAP) to be defined for communications between an authorization 443 server and resource server, a resource server and client, and an 444 authorization server and client respectively. It also, similarly to 445 OAuth, as other extensibility options, such as token profiling and 446 the ability to extend JSON formats to suit a variety of deployment 447 needs. 449 5. Instantiations 451 In this section we provide additional details about the use of OAuth 452 and UMA for solving the use cases outlined in Section 3. In general, 453 the following specifications are utilized: 455 o OAuth 2.0 [RFC6749] for interacting with the authorization server. 456 The use of the CoAP-OAuth profile [I-D.tschofenig-ace-oauth-iot] 457 maybe used but is not essential for the examples in this section 458 since the client is less constrained. 460 o Bearer tokens and proof-of-possession tokens as two different 461 security models for obtaining and presenting access tokens. 462 Bearer tokens are defined in [RFC6750] and the architecture for 463 proof-of-possession (PoP) tokens can be found at 464 [I-D.ietf-oauth-pop-architecture]. PoP tokens introduce the 465 ability to bind credentials, such as an ephemeral public key, to 466 the access token. 468 o UMA [I-D.hardjono-oauth-umacore] for registering the resource 469 server with the authorization server provided by Alice and for 470 management of policy. 472 o Dynamic Client Registration [I-D.ietf-oauth-dyn-reg] for the 473 client app to register at the authorization server. 475 o Token introspection [I-D.ietf-oauth-introspection] for optionally 476 allowing the resource server to verify the validity of the access 477 token (if this step is not done locally at the resource server). 478 The use of token introspection over CoAP 479 [I-D.wahlstroem-ace-oauth-introspection] reduces overhead. 481 o JSON Web Token (JWT) [I-D.ietf-oauth-json-web-token] for the 482 format of the access token. JSON Web Signatures (JWT) 483 [I-D.ietf-jose-json-web-signature] are used for creating a 484 signature over the JWT. The use of a CBOR encoding of various 485 JSON-based security specifications is under discussion to reduce 486 the size of JSON-based tokens. 488 o A new Bluetooth Smart service and profile for conveying access 489 tokens securely from the client to the resource server. If CoAP 490 runs between the client and a constrained resouce server then 491 [I-D.tschofenig-ace-oauth-bt] provides additional overhead 492 reduction. 494 5.1. Car Use Case 496 In the car use case, as described in Section 3.3, the car acts as the 497 resource server and an application on the smart phone plays the role 498 of the client. Alice is first a delegated administrator then becomes 499 a resource owner of the car. 501 Alice creates an account, downloads and authorizes the mobile app: 503 1. Alice creates an account on manufacturer's website. 505 2. Alice selects that two factor authentication must be used to be 506 able to start controlling car from an app. 508 3. Alice downloads app and starts it. 510 4. App has never been provisioned so a browser is started, user 511 selects manufacturer's authorization server from a list. 513 5. Alice authenticates using two factors and authorizes the 514 application. 516 6. Access and refresh tokens are provisioned to the app. 518 Alice configures policies to add Tim as new driver: 520 1. Alice opens the car-settings page within the app. 522 2. Alice selects to add a new driver by supplying Tims email 523 address. 525 3. Alice checks the checkboxes that also makes Tim a delegated 526 administrator. 528 4. Alice saves the new policies. 530 Alice opens car door over Bluetooth Smart: 532 1. The smartphone detects the advertising packets of the door lock 533 and asks Alice whether she wants to open the car door. 535 2. Alice confirms and a request is sent to the authorization server 536 together with an ephemeral public key created by the phone. The 537 request indicates information about the car Alice is seeking 538 access to. 540 3. The authorization server evaluates the request to open the car 541 door on the specific car and verifies it against the access 542 control policy. Note that the app authenticated itself to the 543 authorization server. 545 4. The authorization server prompts Alice for a PIN code using 546 claims gathering. 548 5. Alice enters pin and the application communicates it to the 549 authorization server. 551 6. It turns out that the system administrator has granted her 552 access to that specific car and she is given access by returning 553 an access token. 555 7. The smart phone app then uses the obtained access token to 556 create a request (which includes the access token) over 557 Bluetooth Smart using on the (not yet existing) Physical Access 558 Control Profile, which is a security protocol that utilizes 559 public key cryptography where the app demonstrates that it knows 560 the private key corresponding to the finger of the public key 561 found in the token. 563 8. The car receives the request and verifies it. 565 9. To check whether the permissions are still valid the car sends 566 the access token to the introspection endpoint. 568 10. The authorization server validates the access token and returns 569 information about the validity of the token to the car. In this 570 case it's a valid token. 572 11. The request is logged. 574 12. The car gets a response and opens the car door. 576 Alice changes authorization server: 578 1. Alice wants to connect the car to her own authorization server 579 instead of the manufacturers default authorization server. 581 2. Alice makes a request to the current authorization server to 582 unbind the device from the authorization server. 584 3. The authorization server validates Alice request to remove the 585 authorization server. 587 4. Alice configures a new authorization server in the apps UI. 589 5. The app starts an authorization code grant flow with the private 590 authorization server of Alice. Alice logs on and authorizes the 591 app to act on her behalf. 593 6. The app sends information about the new authorization server to 594 the car using Bluetooth Smart. 596 7. The car registers the resource it offers with the new 597 authorization server. 599 8. Alice configures herself as the car owner in the new 600 authorization server. 602 9. The car unbinds itself from the old authorization server by 603 invalidating the access tokens using the revocation endpoint. 605 5.2. Door Lock Use Case 607 In the constrained server use case, as described in Section 3.4, the 608 door lock acts as the resource server and an application on the smart 609 phone plays the role of the client. 611 Since the client runs on a powerful smartphone standard OAuth 612 according to OAuth Core can be used. To avoid leakage of the access 613 token the use of a proof-of-possession token is utilized instead of a 614 bearer token. This allows the client to demonstrate the possession 615 of the private key to the client. Both symmetric as well as 616 asymmetric cryptography can be used. The use of asymmetric 617 cryptography is beneficial since it allows the client to create a 618 public / private key pair and to never expose the private key to 619 other parties. 621 As a setup-step the following steps are taken as part of the 622 enterprise IT 624 1. Alice, as the enterprise network administrator and compay owner, 625 enables the physical access control rights at the identity 626 management server. 628 2. Alice downloads the enterprise physical access control system app 629 on her phone. By downloading the app she agrees to the terms of 630 use and she accepts the permissions being asked for by the app. 632 3. Alice associates her smart phone app with her account by login 633 into the enterprise management software, which uses OAuth 2.0 for 634 delegating access to the app. 636 4. Alice, as the enterprise administrator, configures policies at 637 the authorization server to give her employees access to the 638 office building as well. 640 5. In this use case each door lock is provisioned with an asymmetric 641 key pair and the public key of the authorization server. The 642 public key of each door lock is registered with the authorization 643 server. Door locks use these keys when interacting with the 644 authorization server (for authentication in case of token 645 introspection), for authenticating towards the client, and for 646 verifying the signature computed over the access token. 648 When Alice uses her smartphone for the first time to access the 649 office building the following steps take place: 651 1. The smartphone detects the advertising packets of the door lock 652 and asks Alice whether she wants access. 654 2. Alice confirms and a request is sent to the authorization server 655 together with an ephemeral public key created by the phone. The 656 request indicates information about the door Alice is seeking 657 access to. The request is protected using TLS. 659 3. The authorization server evaluates the request and verifies it 660 against the access control policy. Since Alice has added herself 661 to access control policies already she is given access by 662 returning an access token. This access token includes the 663 fingerprint of the public key provided in the request. The 664 access token is digitally signed to avoid any modification of the 665 content. 667 4. The smart phone app then uses the obtained information to create 668 a request (which includes the access token) over Bluetooth Smart 669 using the (not yet existing) Physical Access Control Profile, 670 which is a security protocol that utilizes public key 671 cryptography where the app demonstrates that it knows the private 672 key corresponding to the finger of the public key found in the 673 token. 675 5. The door lock software receives the request and verifies the 676 digital signature, inspects the content (such as expiry date, and 677 scope), and determines whether the fingerprint of the public key 678 corresponds to the private key used by the client. Once 679 successfully verified the door is unlocked, and Alice is allowed 680 to enter. 682 6. The physical access control app caches the access token for 683 future use. 685 As a variation of the above-described procedure, the door lock might 686 consult the authorization server using token introspection to 687 determine the validity of the access token. This allows the 688 enterprise system software to make real-time access control decisions 689 and to better gain visibility about the number of employees in the 690 building (in case of an emergency). 692 When Alice approaches the door next time her physical access control 693 app determines that a cached (and still valid) access token is 694 available and no further interaction with the authorization server is 695 needed. Decisions about how long to cache access tokens are a policy 696 decision configurable into the system and impact the performance of 697 the protocol execution. 699 When Bob, who is employed by Alice, approaches the office building 700 for the first time his downloaded physical access control app also 701 interacts with the door. While Bob still has to consent to the use 702 of app, Alice does not need to authorize access of Bob to the office 703 building in real-time since she has already granted access to her 704 employees earlier already. 706 6. UMA Use Case Mapping Exercise 708 An analysis of [I-D.hardjono-oauth-umacore] suggests that its 709 capabilities have a good architectural match with many published ACE 710 use cases. The following are aggregated and paraphrased versions of 711 use cases discussed in [I-D.ietf-ace-usecases]: 713 Owner grants different resource access rights to different parties 714 (U1.1, U2.3, U.3.2): 716 UMA meets this use case because the requesting party is formally 717 distinct from the resource owner and because each requesting 718 party, and each client, is represented distinctly at each 719 authorization server, able to have differential policy applied to 720 it. 722 Owner grants different access rights for different resources on a 723 device (U1.3, U4.4, U5.2): 725 UMA meets this use case because the resource server is able to 726 register each resource set (according to boundaries it 727 unilaterally determines) at the authorization server, so that the 728 resource owner can apply policy to it distinctly. 730 Owner not always present at time of access (U1.6, U5.5): 732 UMA meets this use case because it is a profile of OAuth that 733 defines an asynchronous authorization grant, meaning that the 734 client's interactions during a resource access attempt do not 735 require a resource owner's interaction. 737 Owner grants temporary access permissions to a party (U1.7): 739 UMA meets this use case because the default, mandatory-to- 740 implement permissions associated with a requesting party token 741 (the "bearer" profile) are able to be time-limited and are in a 742 time-limitable JSON Web Token as well. 744 Owner applies verifiable context-based conditions to authorizations 745 (U2.4, U4.5, U6.3): 747 UMA meets this use case because a resource owner can configure an 748 authorization server with policies, or an authorization server can 749 apply system-default policies, to demand "trust elevation" when a 750 client requests authorization data, such that a requesting party 751 or client must satisfy authentication, claims-based, or (through 752 extension) any other criteria prior to being issued authorization 753 data. 755 Owner preconfigures access rights to specific data (U3.1, U6.3): 757 UMA meets this use case because it defines an asynchronous 758 authorization grant, as described above. Preconfiguration is a 759 case when a resource owner sets policy prior to an access attempt. 761 Owner adds a new device under protection (U4.1): 763 UMA meets this use case because it enables a resource owner to 764 associate a device and its corresponding resource server with an 765 authorization server through consenting to the issuance of a 766 protection API token (PAT), enabling the resource server to 767 outsource protection of its resources to the authorization server. 769 Owner puts a previously owned device under protection (U4.2): 771 UMA meets this use case because a previous resource owner can 772 revoke a pre-existing PAT if one existed, revoking the previous 773 consent in place, and the new owner can mint a new PAT. 775 Owner removes a device from protection (U4.3): 777 UMA meets this use case because the resource owner can revoke the 778 PAT. 780 Owner revokes permissions (U4.6): 782 UMA meets this use case because the resource owner can configure 783 the authorization server to revoke or terminate an existing 784 permission. The default, mandatory-to-implement requesting party 785 token profile ("bearer") requires runtime token introspection, 786 ensuring relatively timely retrieval of a revoked permission 787 (barring authorization server caching policy). Other profiles may 788 have different results. 790 Owner grants access only to authentic, authorized clients (U7.1, 791 U7.2): 793 UMA meets this use case because it enables OAuth as well as OpenID 794 Connect authentication of clients, including dynamic 795 authentication, and also enables resource owners to configure 796 authorization servers with policy, such that only desired clients 797 wielded by desired requesting parties are given access to the 798 owner's resources. 800 7. Security Considerations 802 This specification re-uses several existing specifications, including 803 OAuth and UMA, and hence the security-related discussion in those 804 documents is applicable to this specification. A reader is 805 encouraged to consult [RFC6819] for a discussion of security threats 806 in OAuth and ways to mitigate them. On a high level, the security 807 guidance provided in [I-D.iab-smart-object-architecture] will help to 808 improve security of Internet of Things devices in general. 810 Despite all the available guidance it is nevertheless worthwhile to 811 repeat the most important aspects regarding the use of access tokens, 812 which are a core security mechanism in the OAuth / UMA 813 specifications. 815 Safeguard bearer tokens: Client implementations MUST ensure that 816 bearer tokens are not leaked to unintended parties, as they will 817 be able to use them to gain access to protected resources. This 818 is the primary security consideration when using bearer tokens and 819 underlies all the more specific recommendations that follow. This 820 document also outlines the use of proof-of-possessions, which 821 provide stronger security properties than bearer tokens and their 822 use is RECOMMENDED. 824 Validate TLS certificates: TLS/DTLS clients MUST validate the 825 certificates received during the handshaking procedure. TLS/DTLS 826 is used heavily in OAuth/UMA between various parties. Failure to 827 verify certificates will enable man-in-the-middle attacks. 829 Always use TLS/DTLS: The use of TLS/DTLS is mandatory for use with 830 OAuth as a default. Particularly when bearer tokens are exchanged 831 the communication interaction MUST experience communication 832 security protectoin using TLS (or DTLS). Failing to do so exposes 833 bearer tokens to third parties and could consequently give 834 attackers unintended access. Proof-of-possession tokens on the 835 other hand do not necessarily require the use of TLS/DTLS but TLS/ 836 DTLS is RECOMMENDED even in those cases since TLS/DTLS offers many 837 desireable security properties, such as authentication of the 838 server side. 840 Issue short-lived tokens: Authorization servers SHOULD issue short- 841 lived tokens. Using short-lived bearer tokens reduces the impact 842 of them being leaked and allows easier revocation in scenarios 843 where resource servers are offline. 845 Issue scoped tokens: Authorization servers MUST issue tokens that 846 restrict tokens for use with a specific resource server and 847 contains appropriate entitlements to control access in a fine- 848 grained fashion. 850 8. IANA Considerations 852 This document does not require actions by IANA. 854 9. Acknowledgements 856 This is the first version of the document. We appreciate feedback. 858 10. References 860 10.1. Normative References 862 [I-D.hardjono-oauth-umacore] 863 Hardjono, T., Maler, E., Machulak, M., and D. Catalano, 864 "User-Managed Access (UMA) Profile of OAuth 2.0", draft- 865 hardjono-oauth-umacore-12 (work in progress), February 866 2015. 868 [I-D.ietf-jose-json-web-signature] 869 Jones, M., Bradley, J., and N. Sakimura, "JSON Web 870 Signature (JWS)", draft-ietf-jose-json-web-signature-41 871 (work in progress), January 2015. 873 [I-D.ietf-oauth-dyn-reg] 874 ietf@justin.richer.org, i., Jones, M., Bradley, J., 875 Machulak, M., and P. Hunt, "OAuth 2.0 Dynamic Client 876 Registration Protocol", draft-ietf-oauth-dyn-reg-24 (work 877 in progress), February 2015. 879 [I-D.ietf-oauth-introspection] 880 ietf@justin.richer.org, i., "OAuth 2.0 Token 881 Introspection", draft-ietf-oauth-introspection-05 (work in 882 progress), February 2015. 884 [I-D.ietf-oauth-json-web-token] 885 Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 886 (JWT)", draft-ietf-oauth-json-web-token-32 (work in 887 progress), December 2014. 889 [I-D.ietf-oauth-pop-architecture] 890 Hunt, P., ietf@justin.richer.org, i., Mills, W., Mishra, 891 P., and H. Tschofenig, "OAuth 2.0 Proof-of-Possession 892 (PoP) Security Architecture", draft-ietf-oauth-pop- 893 architecture-01 (work in progress), March 2015. 895 [I-D.tschofenig-ace-oauth-bt] 896 Tschofenig, H., "The OAuth 2.0 Bearer Token Usage over the 897 Constrained Application Protocol (CoAP)", draft- 898 tschofenig-ace-oauth-bt-01 (work in progress), March 2015. 900 [I-D.tschofenig-ace-oauth-iot] 901 Tschofenig, H., "The OAuth 2.0 Internet of Things (IoT) 902 Client Credentials Grant", draft-tschofenig-ace-oauth- 903 iot-01 (work in progress), March 2015. 905 [I-D.wahlstroem-ace-oauth-introspection] 906 Wahlstroem, E., "OAuth 2.0 Introspection over the 907 Constrained Application Protocol (CoAP)", draft- 908 wahlstroem-ace-oauth-introspection-00 (work in progress), 909 October 2014. 911 [OIDC] Sakimura, N., "OpenID Connect Core 1.0 incorporating 912 Errata Set 1", 913 http://openid.net/specs/openid-connect-core-1_0.html, 914 November 2014. 916 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 917 Requirement Levels", BCP 14, RFC 2119, March 1997. 919 [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC 920 6749, October 2012. 922 [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization 923 Framework: Bearer Token Usage", RFC 6750, October 2012. 925 [RFC6819] Lodderstedt, T., McGloin, M., and P. Hunt, "OAuth 2.0 926 Threat Model and Security Considerations", RFC 6819, 927 January 2013. 929 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 930 Application Protocol (CoAP)", RFC 7252, June 2014. 932 10.2. Informative References 934 [I-D.iab-smart-object-architecture] 935 Tschofenig, H., Arkko, J., Thaler, D., and D. McPherson, 936 "Architectural Considerations in Smart Object Networking", 937 draft-iab-smart-object-architecture-06 (work in progress), 938 October 2014. 940 [I-D.ietf-ace-usecases] 941 Seitz, L., Gerdes, S., Selander, G., Mani, M., and S. 942 Kumar, "ACE use cases", draft-ietf-ace-usecases-02 (work 943 in progress), February 2015. 945 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 946 Constrained-Node Networks", RFC 7228, May 2014. 948 Authors' Addresses 950 Hannes Tschofenig 951 ARM Limited 952 Austria 954 Email: Hannes.Tschofenig@gmx.net 955 URI: http://www.tschofenig.priv.at 957 Eve Maler 958 Forgerock 960 Email: eve.maler@forgerock.com 962 Erik Wahlstroem 963 Nexus Technology 964 Sweden 966 Email: erik.wahlstrom@nexusgroup.com 967 URI: https://www.nexusgroup.com 968 Samuel Erdtman 969 Nexus Technology 970 Sweden 972 Email: samuel.erdtman@nexusgroup.com 973 URI: https://www.nexusgroup.com