idnits 2.17.1 draft-secheverria-ace-client-disadvantaged-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 8, 2019) is 1869 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 8152 (Obsoleted by RFC 9052, RFC 9053) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Echeverria 3 Internet-Draft CMU SEI 4 Intended status: Informational L. Seitz 5 Expires: September 9, 2019 RISE 6 D. Klinedinst 7 G. Lewis 8 CMU SEI 9 March 8, 2019 11 ACE Clients in Disadvantaged Networks 12 draft-secheverria-ace-client-disadvantaged-00 14 Abstract 16 This document describes a set of recommendations to use when 17 implementing ACE/OAuth 2.0 clients that are working in disadvantaged 18 networks. Issues such as token revocation have a much higher 19 priority in scenarios where Resource Servers are IoT devices, and 20 network connectivity is limited and intermittent. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 9, 2019. 39 Copyright Notice 41 Copyright (c) 2019 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Sample Scenario . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 3 59 3.1. Use of Client Introspection for Token Revocation . . . . 3 60 3.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 3 61 3.1.2. Specific Recommendations . . . . . . . . . . . . . . 4 62 3.1.3. Alternatives . . . . . . . . . . . . . . . . . . . . 5 63 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 65 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 66 7. Normative References . . . . . . . . . . . . . . . . . . . . 6 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 69 1. Introduction 71 Authentication and authorization in IoT (Internet of Things) devices 72 can be difficult due to constraints in terms of memory, processing, 73 user interface, power and communication bandwidth. OAuth 2.0 and 74 derived standards, such as ACE, can be still applied to these 75 scenarios, often with some modifications. However, when IoT devices 76 are working in disadvantaged networks, there are even greater 77 constraints in terms of communication bandwidth. Nodes in 78 disadvantaged networks operate in what are called DIL environments 79 (disconnected, intermittent, limited), which means that there is 80 limited and unreliable connectivity between nodes with potentially 81 periods of full disconnection. This document will focus on practices 82 that are recommended for clients using ACE/OAuth 2.0 while working 83 with IoT devices in disadvantaged networks. 85 There are cases in which a client may need to obtain further 86 information about a token without communicating with a Resource 87 Server (RS). One such case is when a client needs to know the active 88 status of a token that it possesses. This is particularly useful in 89 disadvantaged environments where RS impersonation and sabotage are 90 likely threats. 92 Section 2 describes a sample scenario and Section 3 describes 93 recommendations for client implementation, including the use of 94 client introspection: ensuring only authorized clients can perform 95 client introspection, enabling decryption of self-contained tokens, 96 and limiting information returned in the introspection response. 98 2. Sample Scenario 100 A sample scenario is the following: let's assume we have IoT devices 101 that are deployed over a large area to monitor it after an 102 earthquake. These IoT devices may be small sensors of different 103 types (temperature, motion detectors, etc.) that are constantly 104 collecting information from their environment. Each of these IoT 105 devices will act as an RS, and we want to be able to give 106 authorization to access their resources to mobile clients. The 107 Authorization Server (AS) will be mostly static, or slow moving; it 108 could be deployed in a nearby building, or carried along in vehicles 109 if there is no central location. Clients would most likely be 110 smartphones or tablets, carried by users in the field. Due to the 111 mobility of the clients and the large area over which the RSs are 112 deployed, clients would only intermittently have connectivity to both 113 the AS and to each RS. Clients would ask the AS for access tokens 114 when they are in range of the AS, and use the tokens to get 115 information from the RSs when they are in range of the IoT devices. 117 In this situation, being opportunistic about what to do when a client 118 gets in range of an AS is an important thing to consider. It is also 119 highly likely that clients or RSs may be impersonated or sabotaged. 120 This makes it a high priority to identify tokens associated to a 121 compromised RS or sent to a compromised client. 123 A specific situation for this would be if the AS admin learns that a 124 certain RS has been compromised. The AS does not have constant 125 connectivity to clients, so it can't let them know right away about 126 the issue. However, it wants to prevent all clients that had tokens 127 to communicate with that RS that they should no longer use those 128 tokens. The AS admin can manually mark all tokens issued to that RS 129 as an audience as revoked (internally). However, a means to let 130 clients know about the revocation of their tokens would be needed. 132 3. Recommendations 134 3.1. Use of Client Introspection for Token Revocation 136 3.1.1. Procedure 138 One way to let clients know when a token has been revoked is to 139 extend the existing protocol to add specific messages to handle this. 140 But an alternative, simpler way would be to use client introspection. 141 The end goal is to be able to revoke tokens for a RS that has been 142 compromised, by letting clients poll information about the tokens, 143 and then letting them know that they have been revoked. 145 A client can opportunistically poll an AS using the same 146 introspection mechanism defined in the OAuth 2.0 Token Introspection 147 RFC [RFC7662], to obtain information on whether a specific token is 148 still valid or not. That RFC defines a method for querying an 149 Authorization Server (AS) for metadata about a token. The 150 introspection process focuses on how a Resource Server (RS) could 151 benefit from this information. This is because, in most cases, the 152 token is assumed to be opaque to the client, as it is intended to be 153 a secure way of sending information to a RS, without the client being 154 able to modify it. 156 This same mechanism can be used to detect revoked tokens 157 opportunistically whenever a client gets in range of an AS. It 158 should work in the following way: 160 1- A client that gets in range of the AS, uses that opportunity to 161 contact the AS and to ask it about the state of its non-expired 162 tokens. More specifically, it sends a client introspection request 163 for each of the non-expired tokens it is using. 165 2- The AS replies to the client with information about whether each 166 token is "active" or not. For every token that has been revoked, it 167 returns that the token is not active. 169 3- The client receives the response and purges non-active tokens from 170 its list of tokens. 172 Thus the client will be protected from contacting the compromised RS. 173 Of course, this does not prevent the client from contacting the RS 174 before it can access the AS and ask about the tokens, but there is 175 not much that can be done about it until the client is able to 176 communicate with the AS. 178 3.1.2. Specific Recommendations 180 The following recommendations are useful to consider when 181 implementing client introspection: 183 1- The AS should have a way to limit which clients are allowed to 184 send introspection requests. This ensures that only clients that 185 really do need the information are allowed access to it. 187 2- The "kid" header parameter as defined in [RFC7519] and [RFC8152] 188 should be used when the token is encrypted in a structured 189 information object such as a JSON Web Token (JWT) [RFC7519] or CBOR 190 Web Token (CWT) [RFC8392]. The AS can store a key ID in this header 191 that can be associated with the RS key used during encrypted token 192 creation. If the AS does this when generating every encrypted token, 193 then it should always be able to decrypt that token on an 194 introspection request coming from a client or from a RS. 196 This is needed because an encrypted token can only be decrypted if 197 the proper key is known. When an RS performs introspection, the AS 198 can use the identity of the RS as a hint to find the related key. 199 However, if a client is performing the introspection request, the AS 200 receiving the request needs more information to know what audience 201 the encrypted token was issued for in order to decrypt it properly. 203 3- Only the value of the "active" parameter should be returned for 204 introspection requests coming from clients. An introspection 205 response has several parameters, but all of them are optional except 206 for the "active" parameter. The "active" parameter can be used to 207 indicate that a token has been revoked, and does not provide any 208 information about the claims, which the client should usually not 209 need. This prevents the disclosure of additional information to the 210 client. 212 3.1.3. Alternatives 214 An alternative way to handle token revocation would be to prevent the 215 AS from issuing more tokens for the same RS/audience, and for the 216 client to request a new token each time it is in range of the AS. In 217 this case, tokens would not be revoked, but rather clients would be 218 implicitly notified to no longer contact a specific RS. However, 219 this has at least two downsides. First, a client would have to 220 request a new token each time it is in range of an AS, constantly, to 221 be able to detect token revocation by getting the token request to be 222 denied. This could lead to many tokens issued to the same client and 223 for the same RS in a short period of time, which may not be even used 224 in that timeframe. In addition, this generates additional traffic in 225 an already constrained network. Second, client would be interpreting 226 a denial to issue a token from an AS as a warning not to contact that 227 RS anymore. This could lead the client to dump a previous token that 228 it has for that RS, to prevent potentially dangerous contact with it. 229 However, the denial may be for other reasons, but there is no way to 230 differentiate when denying a token request to a client. Thus, a 231 client may end up dumping working tokens because of a potentially 232 different issue with new token generation. In summary, this option 233 depends on the client making too many assumptions to successfuly 234 prevent it from accessing a compromised RS. Using client 235 introspection to detect revoked tokens is a much simpler and direct 236 way of handling this issue. 238 Another similar alternative to revoking tokens is to issue tokens 239 with very short lifetimes. In this case, even if a device having a 240 token is compromised, the short lifetime will make that token expire 241 quickly, making revocation notifications unnecessary. The main 242 problem with this option in disadvantaged networks is that clients 243 will not often be in range of the AS that issues the tokens or of the 244 RS they want to use the token with. Thus, if tokens have very short 245 lifetimes, they may not last long enough for a client to actually 246 send that token to the RS it needs to contact. Or even if it does, 247 if the token expires shortly afterwards, the client will not be able 248 to contact that or other RS in the same audience again until it comes 249 in range of the AS to obtain a new token. Thus, in this type of 250 environments, the lifetime of a token must be carefully balanced in 251 relation to its intended use and the frequency the devices will be in 252 range of each other. 254 4. IANA Considerations 256 This document makes no request of IANA. 258 Note to RFC Editor: this section may be removed on publication as an 259 RFC. 261 5. Security Considerations 263 There are some potential security issues with the recommendations 264 described in this document. Because the AS would accept 265 introspection requests from a client, claim information associated to 266 the tokens and not intended for a client could be sent back to it in 267 a response. The recommendations above explicitly indicate to only 268 send the "active" parameter as the response to this type of request, 269 but it is still up to the implementation to do this properly, and to 270 properly identify a device as a client (or more specifically as a 271 device to send limited information to in a reply). If this is 272 properly done, compromised or rogue clients sending introspection 273 requests would not be able to obtain more information than the token 274 active status from these types of introspection requests. 276 6. Acknowledgements 278 7. Normative References 280 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 281 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 282 . 284 [RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection", 285 RFC 7662, DOI 10.17487/RFC7662, October 2015, 286 . 288 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 289 RFC 8152, DOI 10.17487/RFC8152, July 2017, 290 . 292 [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 293 "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, 294 May 2018, . 296 Authors' Addresses 298 Sebastian Echeverria 299 CMU SEI 301 Ludwig Seitz 302 RISE 304 Dan Klinedinst 305 CMU SEI 307 Grace Lewis 308 CMU SEI