idnits 2.17.1 draft-zhu-ace-offline-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.ietf-ace-oauth-authz]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 13, 2017) is 2601 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-07) exists of draft-ietf-ace-actors-05 == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-05 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ACE Working Group J. Zhu 3 Internet-Draft Huawei 4 Intended status: Informational March 13, 2017 5 Expires: September 14, 2017 7 Offline usage of ACE 8 draft-zhu-ace-offline-00 10 Abstract 12 [I-D.ietf-ace-oauth-authz] defines a framework for both 13 authentication and authorization in constrained Internet of Things 14 (IoT) environments. A constrained node in this framework may have 15 constraints in computational capability, memory storage, lack of user 16 interface, transmission bandwidth and/or power supply. Battery- 17 powered devices are widely used in IoT deployments and they sleep 18 most of their lifetime for battery saving. Hence, they are usually 19 disconnected from other nodes. This draft provides an overview of 20 the disconnection use cases and discusses offline authentication and 21 authorization solutions. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on September 14, 2017. 40 Copyright Notice 42 Copyright (c) 2017 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3.1. Case 1 Client-AS disconnection . . . . . . . . . . . . . 5 61 3.1.1. Sub-case 1 Client instructs the RS to obtain 62 authorization information from AS . . . . . . . . . . 5 63 3.1.2. Sub-case 2 Introspection Aided Token Validation . . . 7 64 3.1.3. Sub-case 3 RS caches authorization information . . . 7 65 3.2. RS-AS disconnection . . . . . . . . . . . . . . . . . . . 7 66 3.2.1. Sub-case 1: Local Token Validation . . . . . . . . . 7 67 3.3. Client-RS disconnection . . . . . . . . . . . . . . . . . 7 68 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 69 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 70 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 71 7. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 74 8.2. Informative References . . . . . . . . . . . . . . . . . 9 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 77 1. Introduction 79 [I-D.ietf-ace-oauth-authz] defines a framework for both 80 authentication and authorization in constrained Internet of Things 81 (IoT) environments. The framework is based on a set of building 82 blocks including OAuth 2.0 and CoAP. 83 Figure 1/[I-D.ietf-ace-oauth-authz] describes the basic ACE protocol 84 flow. The diagram is repeated below. 86 +--------+ +---------------+ 87 | |---(A)-- Token Request ------->| | 88 | | | Authorization | 89 | |<--(B)-- Access Token ---------| Server | 90 | | + RS Information | | 91 | | +---------------+ 92 | | ^ | 93 | | Introspection Request (D)| | 94 | Client | | | 95 | | Response + Client Token | |(E) 96 | | | v 97 | | +--------------+ 98 | |---(C)-- Token + Request ----->| | 99 | | | Resource | 100 | |<--(F)-- Protected Resource ---| Server | 101 | | | | 102 +--------+ +--------------+ 104 Figure 1: Basic Protocol Flow 106 (A) The client makes an access token request to the /token endpoint 107 at the Authorization Server (AS). 109 (B) The AS successfully processes the request from the client, then 110 returns an access token and some RS information. 112 (C) The client interacts with the resource server (RS) to request 113 access to the protected resource and provides the access token. 115 (D) The RS may make an introspection request to the /introspect 116 endpoint at the AS to get more information about the access token. 118 (E) The AS validates the token and returns the most recent parameters 119 associated with it back to the RS. 121 (F) The RS uses the token information to process the resource access 122 request and returns the protected resources back to the client. 124 Note: Step D and E are optional steps as the RS can process the 125 access token information locally depending on the deployment 126 configurations. 128 There may be many constraints for a constrained IoT device such as 129 limited computational capability, memory storage, lack of user 130 interface, transmission bandwidth and/or power supply. According to 131 the [I-D.ietf-ace-actors], either the client or the RS MAY be a 132 constrained node. One critical issue for IoT ecosystems is that more 133 and more constrained devices are battery-powered, e.g. smart water 134 meters. These battery-powered constrained devices sleep most of 135 their lifetime to save power. What's more, in deployments the 136 underlying network between different nodes may vary from cellular to 137 WLAN even NFC. That means any two nodes of the ACE framework may be 138 disconnected from each other. 140 As a result of Figure 1, there are 3 different possible disconnection 141 cases between the nodes in the ACE framework: 143 1. Client-AS disconnection 145 2. RS-AS disconnection 147 3. Client-RS disconnection 149 This document provides an overview of these cases and discusses 150 offline authentication and authorization solutions based on the ACE 151 framework for each of the cases. 153 The cases discussed in this document utilise the A to F designations 154 from Figure 1 to maintain a relation to the functional steps. 156 2. Terminology 158 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 159 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 160 "OPTIONAL" in this specification are to be interpreted as described 161 in [RFC2119]. 163 This specification requires readers to be familiar with all the terms 164 and concepts that are discussed in [I-D.ietf-ace-oauth-authz] and 165 [RFC7252]. 167 3. Cases 169 This section discusses the disconnection cases including: 171 1. Client-AS disconnection 173 2. RS-AS disconnection 175 3. Client-RS disconnection 177 Each of the cases may have one or more sub-cases. 179 For each case there is a brief description at the beginning, and then 180 a possible solution for the disconnection case is discussed. 182 3.1. Case 1 Client-AS disconnection 184 In this case we consider the case where the Client is disconnected 185 from the Authorization Server when the Client wants to access a 186 resource on the Resource Server. This usually happens when the 187 network between client and AS goes down, but the client can 188 communicate with the RS via another network. 190 3.1.1. Sub-case 1 Client instructs the RS to obtain authorization 191 information from AS 193 This example shows the interaction between a remote controller 194 (Client), a smart television (RS) and a Hub (AS). The remote 195 controller is disconnected from the AS because its WIFI function 196 doesn't work well. However it can communicate with the smart TV via 197 Bluetooth. 199 This access procedure involves all the steps shown in Figure 1. In 200 this case, it is assumed that there is a DTLS connection between the 201 client and RS and a separate DTLS connection between the RS and AS. 203 The client firstly tries to turn on the RS without any authorization 204 information. 206 C: The client sends a request message to the RS in order to change 207 the state of the switch. However this message does not contain any 208 authorization information. 210 F: After receiving the request message, the RS verifies it and sends 211 an authorization verification failure response back to the client. 212 The payload of the response MAY contain the AS information in order 213 to instruct the client to obtain an access token from the right 214 address. 216 Messages C and F is shown in Figure 2. 218 Resource 219 Client Server 220 | | 221 | | 222 C: +-------->| Header: PUT (T=CON, Code=0.03) 223 | PUT | Uri-Path: switch 224 | | Payload: 1 (On) 225 | | 226 | | 227 F: |<--------+ Header: 4.01 Unauthorized 228 | 4.01 | 229 | | 231 Figure 2: Authorization Failure 233 After receiving the unauthorized failure message from the RS, the 234 client then tries to request an access token from the AS. 236 A: The client sends an authorization request to the AS. 238 B: Because the client is disconnected from the AS, the access token 239 request does not receive a response from the AS and the request times 240 out. 242 Message A and B are shown in Figure 3. 244 Authorization 245 Client Server 246 | | 247 |X=======X| Client is disconnected from AS 248 | | 249 | | 250 A: +-------X | Header: POST (T=CON, Code=0.02) 251 | POST | Uri-Path: token 252 | | Payload: client_credentials 253 | | 254 B: | TIMEOUT | 255 | | 257 Figure 3: Authorization Timeout 259 Question: Would it be possible to use the resource server as a proxy 260 to get the authorization information? 262 3.1.2. Sub-case 2 Introspection Aided Token Validation 264 In this scenario we consider the same example shown in Section 3.1.1. 265 The difference is that the client has previously (when it could 266 communicate with the AS) received a pre-provisioned long-lived access 267 token before it went offline. The RS uses its online connectivity to 268 validate the access token with the AS. 270 Note: This is the same use case as the example described in section 271 E.2 of [I-D.ietf-ace-oauth-authz]. 273 3.1.3. Sub-case 3 RS caches authorization information 275 In this section we consider the same case mentioned in Section 3.1.1. 277 It is assumed the client can communicate with the AS over a DTLS 278 channel before it goes offline. A DTLS channel is also established 279 between AS and RS as well as a separate channel between the client 280 and RS. 282 The RS has the capability to cache client authorization information. 284 Question: Would it be acceptable for the RS to have its cache managed 285 by the client? 287 3.2. RS-AS disconnection 289 3.2.1. Sub-case 1: Local Token Validation 291 In this scenario we consider the case where the resource server is 292 offline, i.e. it is not connected to the AS at the time of the access 293 request. This access procedure involves steps A, B, C, and F of 294 Figure 1. 296 Since the resource server must be able to verify the access token 297 locally, self-contained access tokens must be used. 299 Note: This case is the same as the example described in section E.1 300 of [I-D.ietf-ace-oauth-authz]. 302 3.3. Client-RS disconnection 304 In this scenario we consider the case where the client is 305 disconnected from resource server at the time of the access request. 306 For example, both a mobile phone (Client) and a thermostat(RS) are 307 connecting to a same cloud server(AS). The phone has no connection 308 to the thermostat, but the AS should provide a mechanism for the 309 client to query the temperature remotely. This access procedure 310 involves steps A, B, D, and E of Figure 1 as shown below. 312 +--------+ +---------------+ +----------+ 313 | Client |---(A)-->| Authorization |---(E)-->| Resource | 314 | |<--(B)---| Server |<--(D)---| Server | 315 +--------+ +---------------+ +----------+ 317 Figure 4: Client-RS disconnection 319 In this case, it is assumed that a DTLS channel is established 320 between the client & AS, and a separate DTLS connection between the 321 AS & RS as well. The AS SHOULD act as proxy and can forward the 322 resource access request by the client to the RS. The client prior to 323 sending a message to the AS, tried to access the resource directly. 324 However it did not get a successful response due to disconnection 325 between these two nodes. So the client then tries to access the 326 resource via the AS. 328 Question: Would it be acceptable for the AS to act as a proxy for 329 requests to the RS? 331 4. Security Considerations 333 This document addresses authorised access to resources in device 334 disconnection scenarios. 336 5. IANA Considerations 338 TBD. 340 6. Acknowledgements 342 TBD. 344 7. Changelog 346 Initial version 348 8. References 350 8.1. Normative References 352 [I-D.ietf-ace-actors] 353 Gerdes, S., Seitz, L., Selander, G., and C. Bormann, "An 354 architecture for authorization in constrained 355 environments", draft-ietf-ace-actors-05 (work in 356 progress), March 2017. 358 [I-D.ietf-ace-oauth-authz] 359 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 360 H. Tschofenig, "Authentication and Authorization for 361 Constrained Environments (ACE)", draft-ietf-ace-oauth- 362 authz-05 (work in progress), February 2017. 364 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 365 Requirement Levels", BCP 14, RFC 2119, 366 DOI 10.17487/RFC2119, March 1997, 367 . 369 8.2. Informative References 371 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 372 Application Protocol (CoAP)", RFC 7252, 373 DOI 10.17487/RFC7252, June 2014, 374 . 376 Author's Address 378 Jintao Zhu 379 Huawei 380 P.R.China 382 Email: jintao.zhu@huawei.com