idnits 2.17.1 draft-lodderstedt-oauth-securityconsiderations-02.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 document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([I-D.ietf-oauth-v2]), 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 date (April 7, 2011) is 4767 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-31) exists of draft-ietf-oauth-v2-15 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Open Authentication Protocol T. Lodderstedt, Ed. 3 Internet-Draft Deutsche Telekom AG 4 Intended status: Standards Track M. McGloin 5 Expires: October 9, 2011 IBM 6 P. Hunt 7 Oracle Corporation 8 A. Nadalin 9 Microsoft Corporation 10 April 7, 2011 12 OAuth 2.0 Security Considerations 13 draft-lodderstedt-oauth-securityconsiderations-02 15 Abstract 17 This document gives security considerations for the OAuth 2.0 18 protocol. The proposed text is intended to be included into 19 [I-D.ietf-oauth-v2]. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 25 document are to be interpreted as described in RFC 2119 [RFC2119]. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on October 9, 2011. 44 Copyright Notice 46 Copyright (c) 2011 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Security Considerations . . . . . . . . . . . . . . . . . . . . 3 63 2.1. Client Authentication . . . . . . . . . . . . . . . . . . . 3 64 2.2. Malicious Client Obtains Authorization . . . . . . . . . . 4 65 2.3. Access Tokens . . . . . . . . . . . . . . . . . . . . . . . 4 66 2.4. Refresh Tokens . . . . . . . . . . . . . . . . . . . . . . 5 67 2.5. Token Scope . . . . . . . . . . . . . . . . . . . . . . . . 5 68 2.6. Request Confidentiality . . . . . . . . . . . . . . . . . . 5 69 2.7. Endpoints Authenticity . . . . . . . . . . . . . . . . . . 6 70 2.8. Online Guessing Attacks . . . . . . . . . . . . . . . . . . 6 71 2.9. Phishing Attacks . . . . . . . . . . . . . . . . . . . . . 6 72 2.10. Authorization Code Disclosure . . . . . . . . . . . . . . . 6 73 2.11. Session Fixation . . . . . . . . . . . . . . . . . . . . . 7 74 2.12. Resource Owner Password Credentials . . . . . . . . . . . . 7 75 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 76 4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 77 4.1. Normative References . . . . . . . . . . . . . . . . . . . 8 78 4.2. Informative References . . . . . . . . . . . . . . . . . . 8 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 81 1. Definitions 83 This document considers the following clients categories: 85 Web Application Such an application is installed on a server. End- 86 users access it via a HTML user interface rendered in the user 87 agent on the end-user's device. All application data relevant to 88 the OAuth protocol are stored on the server and is not accessible 89 by the user. 91 User Agent-based Application Such an application is downloaded from 92 a web site and runs within the user agent on the end-user's 93 device. All application data relevant to the OAuth protocol is 94 accessible by the user. Since such applications directly reside 95 within the user agent, they can seamlessly make use of it 96 capabilities in the end-user authorization process. 98 Native Application Such an app is installed and runs on an end- 99 user's device. All application data relevant to the OAuth 100 protocol is accessible by the user. It is assumed that such 101 applications can protect dynamically issued secrets, such as 102 refresh tokens, from eavesdropping by other applications residing 103 on the same device. 105 2. Security Considerations 107 Note: This section focuses on the security guidelines implementors of 108 the protocol MUST consider. We encourage readers to consult the more 109 detailed analysis with additional background information in 110 [I-D.lodderstedt-oauth-security]. 112 2.1. Client Authentication 114 Authorization servers MAY issue client secrets to web applications 115 for the purpose of authenticating them. Authorization servers are 116 encouraged to consider stronger client authentication means. 117 Application developers MUST ensure confidentiality of client secrets 118 and other credentials. 120 Authorization server MUST NOT issue client secrets to native or user 121 agent-based applications in general. An authorization server MAY 122 issue a client secret for an installation of a native application on 123 a specific device. Alternatively, authorization servers MUST utilize 124 other means than client authentication to achieve their security 125 objectives. 127 2.2. Malicious Client Obtains Authorization 129 A malicious client could impersonate a valid client and obtain access 130 to a protected resource. 132 Assumption: It is not the task of the authorization server to protect 133 the end-user's device from malicious software. This is the 134 responsibility of the platform running on the particular device 135 probably in cooperation with other components of the respective 136 ecosystem (e.g. an application management infrastructure). The sole 137 responsibility of the authorization server is to control access to 138 the end-user's resources living in resource servers and to prevent 139 unauthorized access to them. Based on this assumption, the following 140 countermeasures are recommended. 142 Where the client can be authenticate, the authorization server MUST 143 authenticate it. If the authorization server cannot authenticate the 144 particular impersonated client, the authorization server MUST utilize 145 other means to achieve its security objectives. The authorization 146 server MAY enforce explicit user authentication or ask the end-user 147 for consent. In this context, the user SHALL be explained the 148 purpose, scope, and duration of the authorization. The authorization 149 server MUST make the meta-data it associates with the particular 150 client (e.g. the name) available to the end-user. It is up to the 151 user to validate the binding of this data to the particular 152 application and to approve the authorization request. 154 Authorization servers MUST NOT automatically process (without user 155 interaction) repeated authorizations without authenticating the 156 client. 158 The authorization server SHOULD require clients to pre-register their 159 redirect_uri's and validate the actual redirect_uri against the pre- 160 registered value. 162 It is higly RECOMMENDED that the authorization server limits the 163 scope of tokens. 165 2.3. Access Tokens 167 Access tokens MUST only be accessible to the authorization server, 168 the resource servers this token is valid for and the client to whom 169 they have been issued. The only exception is the implicit grant 170 where the user agent gets access to the access token that is 171 transmitted in the URI fragment. 173 Authorization server as well as application developers MUST ensure 174 confidentiality of access tokens, on transit and in storage. 176 Application developers MUST NOT store access tokens in non-transient 177 memory. 179 Authorization servers MUST ensure that access tokens cannot be 180 manufactured, modified, or guessed. 182 2.4. Refresh Tokens 184 Authorization servers MAY issue refresh tokens to web and native 185 applications. 187 Refresh tokens MUST only be accessible to the authorization server 188 and the client to whom they have been issued. The authorization 189 server MUST maintain the link between a refresh token and the client 190 to whom it has been issued. 192 Where the client can be authenticated, this relation between client 193 and refresh token MUST be validated on every token refreshment 194 request. If this is not possible, it is RECOMMENDED for 195 authorization servers to implement other means to detect abuse of 196 refresh tokens. 198 Authorization server as well as application developers MUST ensure 199 confidentiality of refresh tokens, on transit and in storage. 201 Authorization servers MUST ensure that refresh tokens cannot be 202 manufactured, modified, or guessed. 204 2.5. Token Scope 206 It is strongly RECOMMENDED that application developers only acquire 207 access tokens with the minimal scope they need in order to implement 208 the respective application function. 210 When obtaining end user authorization and where the client requests 211 scope, the authorization server MAY want to consider whether to 212 honour that scope based on who/what the client is and the type of 213 access grant the client asked for. The resource owner MAY also 214 further restrict the scope of the access tokens. 216 2.6. Request Confidentiality 218 The following security sensitive data elements MUST NOT be 219 transmitted in clear: access tokens, refresh tokens, resource owner 220 passwords, authorization codes, and client secrets. 222 2.7. Endpoints Authenticity 224 In order to prevent men-in-the-middle and phishing attacks, HTTPS 225 with server-side authentication MUST be implemented and used by 226 authorization servers in all exchanges. 228 For the same purpose, HTTPS with server-side authentication SHOULD/ 229 MUST [note: this is still subject to a WG discussion] be implemented 230 and used by web application clients at least on their redirect_uri. 232 Application developers MUST provide mechanisms to validate the 233 authorization server endpoint's authenticity and ensure proper 234 handling of CA certificates as well as certificate chain validation. 236 2.8. Online Guessing Attacks 238 Authorization servers MUST prevent guessing attacks on the following 239 credentials: authorization codes, refresh tokens, resource owner 240 passwords, and client secrets. 242 When creating token handles or other secrets not intended for usage 243 by human users, the authorization server MUST include a reasonable 244 level of entropy in order to mitigate the risk of guessing attacks. 245 When creating secrets intended for usage by human users, the 246 authorization server MUST utilize other means to protect those 247 secrets. 249 2.9. Phishing Attacks 251 It is strongly RECOMMENDED that native application developers use 252 external browsers instead of browsers embedded in the application for 253 performing the end-user authorization process. External browsers 254 offer a familiar usage experience and a trusted environment, in which 255 users can confirm the authentictity of the site. 257 To reduce the risk of phishing attacks, authorization servers MUST 258 support the authentication of their endpoint. For example, they can 259 utilize HTTPS server authentication for that purpose. Moreover, 260 service providers should attempt to educate users about the risks 261 phishing attacks pose, and should provide mechanisms that make it 262 easy for users to confirm the authenticity of their sites. e.g. 263 extended validation certificates. 265 2.10. Authorization Code Disclosure 267 Confidentiality of authorization codes MUST be ensured on transport. 268 Note: Since the code is transmitted via browser redirects, it could 269 also be disclosed through browser histories and HTTP referers. 271 The authorization server and the client MUST ensure that the 272 authorization code transmission is protected by using channel 273 security, such as TLS, and that the authorization code is short 274 lived. 276 Where the client can be authenticated, the authorization servers MUST 277 authenticate the client and validate that the authorization code had 278 been issued to the same client. If the client cannot be 279 authenticated, authorization servers MUST enforce one time usage of 280 the authorization code. Moreover, if an authorization server 281 observes multiple attempts to redeem an authorization code, the 282 authorization server MAY want to revoke all tokens granted based on 283 this authorization code. 285 2.11. Session Fixation 287 The session fixation attack leverages the authorization code flow in 288 an attempt to get another user to log-in and authorize access on 289 behalf of the attacker. The victim, seeing only a normal request 290 from an expected application, approves the request. The attacker 291 then uses the victim's authorization to gain access to the 292 information unknowingly authorized by the victim. 294 In order to prevent such an attack, authorization servers MUST ensure 295 that the redirect_uri used in the authorization flow is the same as 296 the redirect_uri used to exchange the respective authorization code 297 into tokens. The authorization server operators SHOULD require 298 client application developers to pre-register their redirect_uri's 299 and validate the actual redirect_uri against the pre-registered 300 value. 302 2.12. Resource Owner Password Credentials 304 The "Resource Owner Password Credentials" grant type is often used 305 for legacy/migration reasons. It reduces the overall risk of storing 306 username and password in the client. 308 It has higher risk than the other OAuth grant types because it 309 maintains the password anti-pattern. The client could abuse the 310 password or the password could unintentionally be disclosed on the 311 client site e.g. through log files. Additionally, because the user 312 does not have control over the authorization process, clients could 313 acquire tokens with much broader scope and longer livetime than 314 desired by the user. 316 The authorization server MUST ensure the resource owner's control and 317 transparency with respect to all authorizations issued to clients. 319 Authorization servers and application developers SHOULD minimize use 320 of this grant type. Other grant types which facilitate user control 321 and transparency should be used instead. 323 The authorization server SHOULD generally restrict the scope of 324 access tokens issued by this grant type. 326 3. Acknowledgements 328 4. References 330 4.1. Normative References 332 [I-D.ietf-oauth-v2] 333 Hammer-Lahav, E., Recordon, D., and D. Hardt, "The OAuth 334 2.0 Authorization Protocol", draft-ietf-oauth-v2-15 (work 335 in progress), April 2011. 337 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 338 Requirement Levels", BCP 14, RFC 2119, March 1997. 340 4.2. Informative References 342 [I-D.lodderstedt-oauth-security] 343 Lodderstedt, T., McGloin, M., and P. Hunt, "OAuth 2.0 344 Threat Model and Security Considerations", 345 draft-lodderstedt-oauth-security-01 (work in progress), 346 March 2011. 348 Authors' Addresses 350 Dr.-Ing. Torsten Lodderstedt (editor) 351 Deutsche Telekom AG 353 Email: torsten@lodderstedt.net 355 Mark McGloin 356 IBM 358 Email: mark.mcgloin@ie.ibm.com 359 Phil Hunt 360 Oracle Corporation 362 Email: phil.hunt@yahoo.com 364 Anthony Nadalin 365 Microsoft Corporation 367 Email: tonynad@microsoft.com