idnits 2.17.1 draft-leiba-oauth-additionalsecurityconsiderations-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 28, 2011) is 4778 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-31) exists of draft-ietf-oauth-v2-13 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OAuth working group B. Leiba 3 Internet-Draft Huawei Technologies 4 Intended status: Informational March 28, 2011 5 Expires: September 29, 2011 7 OAuth Additional Security Considerations 8 draft-leiba-oauth-additionalsecurityconsiderations-00 10 Abstract 12 The Open Authentication Protocol (OAuth) specifies a security 13 protocol that involves significant end-user interaction -- the model 14 is based on having the end-user approve the authorization that is 15 being requested. That aspect makes the user interaction a part of 16 the security model, and raises additional security considerations 17 beyond those that are typical for client/server protocols. This 18 document describes those considerations. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on September 29, 2011. 37 Copyright Notice 39 Copyright (c) 2011 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Laying Out the Issues . . . . . . . . . . . . . . . . . . . 3 57 2.1. On Granting Access . . . . . . . . . . . . . . . . . . . . . 4 58 2.2. On Discovering and Revoking Access . . . . . . . . . . . . . 7 60 3. Recommendations . . . . . . . . . . . . . . . . . . . . . . 8 62 4. Security Considerations . . . . . . . . . . . . . . . . . . 9 64 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 9 66 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 68 7. Normative References . . . . . . . . . . . . . . . . . . . . 9 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . 10 72 1. Introduction 74 The Open Authentication Protocol [I-D.ietf-oauth-v2] specifies a 75 security protocol used to authorize one service to act on behalf of a 76 user to a second service (to give a somewhat oversimplified 77 description). For example: 79 o A photo-printing service needs authorization to retrieve photos 80 from a user's private photo albums, stored with a photo-sharing 81 service. 83 o A social-network service needs authorization to read a user's 84 personal address book, stored in the email service she uses. 86 In most use cases, part of the protocol involves prompting the user 87 to log in to the second service and accept the authorization request. 88 That aspect makes the user interaction a part of the security model, 89 and raises additional security considerations beyond those that are 90 typical for client/server protocols. 92 [[anchor1: Should this be targeted for a BCP? I would prefer that, 93 as it would give it more weight.]] 95 2. Laying Out the Issues 97 The OAuth version 2 spec [I-D.ietf-oauth-v2] describes, in its 98 introduction, a typical example of the use of OAuth: 100 For example, a web user (resource owner) can grant a printing 101 service (client) access to her protected photos stored at a photo 102 sharing service (resource server), without sharing her username 103 and password with the printing service. Instead, she 104 authenticates directly with a server trusted by the photo sharing 105 service (authorization server) which issues the printing service 106 delegation-specific credentials (access token). 108 In such a typical case: 110 1. The user (resource owner) visits the client's web site (the 111 printing service) and makes a web request ("Print a photo from my 112 photo-sharing site.") 114 2. The client, behind the scenes and not apparent to the user, 115 requests authorization from the resource server, and is given a 116 request token. 118 3. The client sends a response to the user's web request. The 119 response redirects the user's web browser to the authorization 120 server (of the photo-sharing service) and passes the server the 121 request token. 123 4. The authorization server prompts the user to accept the requested 124 authorization. The user sees this authorization prompt in the 125 browser, and it appears to be the first response to the original 126 request. 128 5. The user accepts the authorization request. She might have to 129 log in first, or an existing login might be used. Typically, she 130 will click a visual "button" that says "Accept", "Authorize", 131 "OK", or the like. 133 6. The authorization server sends a response to that action. The 134 response redirects the user's web browser to the client web 135 server (the printing service) and passes the server an access 136 token. 138 7. The client (the printing service) uses the access token behind 139 the scenes to contact the resource server (the photo-sharing 140 service) and to perform the service for the user. The user is 141 given a response that indicates that the request is in the works. 143 From the user's point of view, the interaction has seemed simple; 144 this is a great benefit of OAuth. But there was actually a 145 reasonable amount of complexity "behind the scenes" that the user did 146 not understand, and that leaves us with a conflicted situation: 148 1. the user shouldn't have to understand all of the behind-the- 149 scenes detail, but 151 2. the user needs to understand what she's being asked to authorize, 152 in order that she might make the right security decision about 153 the request. 155 2.1. On Granting Access 157 Some of the things a user might need to understand to make the 158 decision include 160 o Who is requesting the access. This can be a tricky point. The 161 authorization server might likely know only the domain name, or 162 even just the IP address of the client that's making the request. 163 The user *might* be able to make some sense of the domain name, 164 but really would do better with a real, human-readable name that 165 matches what she calls the service. And the authorization server 166 has no cause to trust any human-readable string the requestor 167 gives. 169 A DKIM-like digital signature [I-D.crocker-dkim-doseta] along with 170 a mapping of known signing identities to readable names can be a 171 great help here. But be aware that any name provided by the 172 client is open to abuse by a bad actor, and should not be trusted. 174 o Who will be granting the access. It's easy to leave this out, 175 with the idea that it should be self-evident. The problem is that 176 if a client is requesting access beyond what it should be asking 177 for, it might be asking the wrong entity as well. If a user asks 178 for a photo to be printed, the requested authorization should not 179 be to the user's email account. 181 o The specific access that is being requested. This might not 182 always be obvious, depending upon the request, and depending upon 183 how the prompt is worded. "Print a photo for me," will likely 184 translate into read access to the photo. For "Auto-adjust the 185 contrast before printing, and save the adjusted version," the 186 service will need access to update the photo or to save a new 187 copy. 189 "Send e-cards to my family on their birthdays," might translate 190 into authority to send email on her behalf, plus read access to 191 her address book. The address book access is somewhat less 192 evident, and leaves a different avenue for abuse. 194 o The scope of the access. If she wants to print a single photo, 195 then read access to just that photo will do. If she wants to 196 print all photos in an album, she'll need to grant read access to 197 the whole album. 199 o The duration of the access. If she just wants to print a photo, 200 then a single read access to the photo should be enough. If she 201 wants the service to automatically print all her new photos every 202 week, persistent, long-term read access to her "new uploads" photo 203 album might work. 205 Because end-users are accepting or rejecting the authorization that 206 the client service is requesting, their understanding of what they're 207 being asked is important to the overall security of the system. And 208 because end-users often know nothing about computer security, the way 209 these various points are presented to them is a critical piece of the 210 security design. That is, the prompts and the user's understanding 211 of them and response to them have to be considered part of the 212 security model. 214 This is especially important because the user is thinking in terms of 215 a task, while the authorization system is working in terms of what 216 accesses are needed for the task. The mapping between the two is 217 often not clear to the user, and the user's trust of the service 218 requesting the access might be tenuous. 220 We need to avoid asking users questions they're not prepared or 221 qualified to answer. Unfortunately, most security-related questions 222 fall into that category. The more we can put the request into plain 223 language, and the better we can explain, in clear, simple terms 224 what's being asked and what the ramifications of it are, the more 225 likely it is that we'll be working with informed consent and will 226 have a chance at fending off attacks on the system. 228 Consider the difference, for example, between the following two 229 prompts. 231 ----------------------------------------------------------------- 232 Give printpix.example r/o access to 233 http://photoshare.example/usr213554/fnxgrptl/250/43/342500134.jpg 235 (OK) (Cancel) 236 ----------------------------------------------------------------- 237 Example 1a 239 ----------------------------------------------------------------- 240 The Print My Pix service (printpix.example) is asking PhotoShare 241 for access to your photo titled "Ralph in the park" in album 242 "New York". Granting access will allow Print My Pix to read, but 243 not alter nor delete, your photo. Access will be allowed one 244 time only. 246 For a more detailed explanation of what this means, [click here]. 248 Do you want to allow access? 250 (Yes) (No) 251 ----------------------------------------------------------------- 252 Example 1b 254 The second prompt is wordier, but might be easier for most people to 255 understand. Some of the technical details (such as the URL to the 256 photo in question) are available at a click, for users who want more 257 details. 259 Note how that difference appears to a user when the Print My Pix 260 service is actually abusive, and tries to get broader access than it 261 needs. 263 ----------------------------------------------------------------- 264 Give printpix.example r/w access to 265 http://photoshare.example/usr213554/ 267 (OK) (Cancel) 268 ----------------------------------------------------------------- 269 Example 2a 271 ----------------------------------------------------------------- 272 The Print My Pix service (printpix.example) is asking PhotoShare 273 for access to all your photo albums. Granting access will allow 274 Print My Pix to read, alter and delete, your photos. Access will 275 be allowed permanently. 277 For a more detailed explanation of what this means, [click here]. 279 Do you want to allow access? 281 (Yes) (No) 282 ----------------------------------------------------------------- 283 Example 2b 285 The second prompt makes it clearer that Print My Pix is asking for a 286 lot. Specific warnings might also be added for atypical access 287 requests, or ones that seem to be overstepping. 289 It is not the intent, here, to give specific user-interface design 290 advice, and the design and wording of these prompts and other user- 291 interface elements will not necessarily come out well if given to 292 some protocol designers. The point, rather, is to highlight the 293 issues and raise awareness of the security implications of how OAuth 294 requests are communicated, so interface designers can take that into 295 account. 297 2.2. On Discovering and Revoking Access 299 As we use a great many services that each act as clients to other 300 services we use, we soon get into a very complex and hard-to-manage 301 situation. Suppose our hypothetical user allows Facebook to access 302 Flickr and to import contacts from Gmail; she allows her Blogger 303 account to post photos to Flickr and to read the photos there; she 304 allows Twitter to post her tweets to Facebook.... 306 By the nature of these arrangements, and by the design of OAuth, 307 there's no central place that keeps track of all the authorizations. 309 Each service knows what accesses she has authorized to it, but she 310 has to check each service individually. It's critical that she have 311 an easy way to do that, that she can easily find the way to do that, 312 and that she can understand the results that her queries return -- it 313 won't do to have them in computer-geek gibberish. 315 Further, it has to be easy for her to suspend or revoke the 316 authorizations she's made -- stale authorizations are entry points 317 for security vulnerabilities. She needs to be able to correct errors 318 she has made in authorizing things, as well as to rescind the 319 authorizations that are no longer appropriate. 321 3. Recommendations 323 1. Implementations should consider clarity to end users as a 324 critical part of the security model. Because users who are not 325 experts in security are being asked to make security decisions, 326 it is very important that the questions be clear, and that it be 327 easy to find more information. 329 2. Implementations should explain exactly what is being requested by 330 whom, and should provide one-click access to a more detailed 331 explanation. 333 3. Implementations should explain the ramifications of accepting the 334 request. Because the user is thinking of a specific task, other 335 aspects of what the requested access permits are not in the 336 user's mind. Put them there. Explain that this means that they 337 will be able to put all your photos into their photo pool, send 338 email on your behalf forever, and put everyone you know into 339 their marketing database. 341 4. Implementations should be attuned to the more usual requests, and 342 should highlight unusual requests when they arrive. If most 343 reasonable requests need read access and one asks for read/write, 344 tell the user it's unusual. Similarly, if most requests need 345 one-time access, or access to a single resource, let the user 346 know that a request for permanent access to multiple resources is 347 cause for concern. This particular task might need it, but make 348 sure the user is aware that this isn't what you usually see. 350 5. This should be a tractable problem, because most authorization 351 servers will be dealing with a limited set of resources, and, 352 hence, a limited set of typical authorization requests. The set 353 of typical requests will often be readily enumerable, and out-of- 354 the-ordinary ones will usually stand out. 356 6. Implementations should provide an easy way, obvious to the user, 357 to inquire about active authorizations. This should not be 358 hidden behind a sort of "advanced" page, but should be within 359 easy reach of every user, along with a clear explanation of what 360 it means. 362 7. Implementations should provide an easy way, once the active 363 authorizations are shown, to get a detailed explanation of the 364 authorization -- what it means, what it allows access to, what 365 the ramifications are. Anything that should have been part of 366 the original access prompt should be available here. 368 8. Implementations should provide an easy way, once the active 369 authorizations are shown, to suspend or revoke each authorization 370 immediately. 372 9. Client implementations should gracefully re-authorize in the 373 event of a revoked authorization. Failure because an expected 374 authorization has been revoked is considered poor quality of 375 implementation. It is only appropriate to fail after an attempt 376 to re-authorize is denied. 378 4. Security Considerations 380 This entire document is about security considerations. Can we have 381 the RFC Editor remove this section prior to publication? 383 5. IANA Considerations 385 There are no IANA actions needed for this document, and the RFC 386 Editor may remove this section prior to publication. 388 6. Acknowledgements 390 [Thanks will go here.] 392 7. Normative References 394 [I-D.crocker-dkim-doseta] 395 Crocker, D. and M. Kucherawy, "DomainKeys Security Tagging 396 (DOSETA)", draft-crocker-dkim-doseta-00 (work in 397 progress), January 2011. 399 [I-D.ietf-oauth-v2] 400 Hammer-Lahav, E., Recordon, D., and D. Hardt, "The OAuth 401 2.0 Authorization Protocol", draft-ietf-oauth-v2-13 (work 402 in progress), February 2011. 404 Author's Address 406 Barry Leiba 407 Huawei Technologies 409 Phone: +1 646 827 0648 410 Email: barryleiba@computer.org 411 URI: http://internetmessagingtechnology.org/