--- 1/draft-ietf-kitten-sasl-oauth-16.txt 2014-11-12 08:14:49.078525814 -0800 +++ 2/draft-ietf-kitten-sasl-oauth-17.txt 2014-11-12 08:14:49.118526784 -0800 @@ -1,21 +1,21 @@ KITTEN W. Mills Internet-Draft Microsoft Intended status: Standards Track T. Showalter -Expires: March 20, 2015 +Expires: May 16, 2015 H. Tschofenig ARM Ltd. - September 16, 2014 + November 12, 2014 A set of SASL Mechanisms for OAuth - draft-ietf-kitten-sasl-oauth-16.txt + draft-ietf-kitten-sasl-oauth-17.txt Abstract OAuth enables a third-party application to obtain limited access to a protected resource, either on behalf of a resource owner by orchestrating an approval interaction, or by allowing the third-party application to obtain access on its own behalf. This document defines how an application client uses credentials obtained via OAuth over the Simple Authentication and Security Layer @@ -38,21 +38,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on March 20, 2015. + This Internet-Draft will expire on May 16, 2015. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -65,37 +65,37 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. OAuth SASL Mechanism Specifications . . . . . . . . . . . . . 6 3.1. Initial Client Response . . . . . . . . . . . . . . . . . 7 3.1.1. Reserved Key/Values . . . . . . . . . . . . . . . . . 8 3.2. Server's Response . . . . . . . . . . . . . . . . . . . . 8 3.2.1. OAuth Identifiers in the SASL Context . . . . . . . . 8 3.2.2. Server Response to Failed Authentication . . . . . . 9 - 3.2.3. Completing an Error Message Sequence . . . . . . . . 9 + 3.2.3. Completing an Error Message Sequence . . . . . . . . 10 3.3. OAuth Access Token Types using Keyed Message Digests . . 10 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1. Successful Bearer Token Exchange . . . . . . . . . . . . 11 4.2. Successful OAuth 1.0a Token Exchange . . . . . . . . . . 12 4.3. Failed Exchange . . . . . . . . . . . . . . . . . . . . . 13 4.4. SMTP Example of a Failed Negotiation . . . . . . . . . . 14 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 6. Internationalization Considerations . . . . . . . . . . . . . 16 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 7.1. SASL Registration . . . . . . . . . . . . . . . . . . . . 16 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 8.1. Normative References . . . . . . . . . . . . . . . . . . 17 8.2. Informative References . . . . . . . . . . . . . . . . . 18 - Appendix A. Acknowlegements . . . . . . . . . . . . . . . . . . 18 - Appendix B. Document History . . . . . . . . . . . . . . . . . . 18 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 + Appendix A. Acknowlegements . . . . . . . . . . . . . . . . . . 19 + Appendix B. Document History . . . . . . . . . . . . . . . . . . 19 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 1. Introduction OAuth 1.0a [RFC5849] and OAuth 2.0 [RFC6749] are protocol frameworks that enable a third-party application to obtain limited access to a protected resource, either on behalf of a resource owner by orchestrating an approval interaction, or by allowing the third-party application to obtain access on its own behalf. The core OAuth 2.0 specification [RFC6749] specifies the interaction @@ -190,27 +190,30 @@ (F) The resource server validates the access token, and if valid, indicates a successful authentication. Again, steps (E) and (F) are not defined in [RFC6749] (but are described in, for example, [RFC6750] for the OAuth Bearer Token instead) and are the main functionality specified within this document. Consequently, the message exchange shown in Figure 1 is the result of this specification. The client will generally need to determine the authentication endpoints (and perhaps the service endpoints) before the OAuth 2.0 protocol exchange messages in steps - (A)-(D) are executed. The discovery of the resource owner and - authorization server endpoints is outside the scope of this - specification. The client must discover those endpoints using a - discovery mechanism, such as Webfinger using host-meta [RFC7033]. In - band discovery is not tenable if clients support the OAuth 2.0 - password grant. Once credentials are obtained the client proceeds to - steps (E) and (F) defined in this specification. + (A)-(D) are executed. The discovery of the resource owner, + authorization server endpoints, and client registration are outside + the scope of this specification. The client must discover the + authorization endpoints using a discovery mechanism such as OpenID + Connect Discovery [OpenID.Discovery] or Webfinger using host-meta + [RFC7033]. Once credentials are obtained the client proceeds to + steps (E) and (F) defined in this specification. Authorization + endpoints MAY require client registration and generic clients SHOULD + support the Dynamic Client Registration protocol + [I-D.ietf-oauth-dyn-reg]. OAuth 1.0 follows a similar model but uses a different terminology and does not separate the resource server from the authorization server. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. @@ -290,22 +293,22 @@ protocols are allowed to require an authzid, as are specific server implementations. The following keys and corresponding values are defined in the client response: auth (REQUIRED): The payload that would be in the HTTP Authorization header if this OAuth exchange was being carried out over HTTP. - host: Contains the host name to which the client connected, in an - HTTP context this is the value of the HTTP Host header. + host: Contains the host name to which the client connected. In + an HTTP context this is the value of the HTTP Host header. port: Contains the port number represented as a decimal positive integer string without leading zeros to which the client connected. For OAuth token types such as OAuth 1.0a that use keyed message digests the client MUST send host and port number key/values, and the server MUST fail an authorization request requiring keyed message digests that are not accompanied by host and port values. In OAuth 1.0a for example, the so-called "signature base string calculation" @@ -375,27 +378,48 @@ single scope is preferred, use of a space separated list of scopes is NOT RECOMMENDED. oauth-configuration (OPTIONAL): The URL for for a document following the OpenID Provider Configuration Information schema as described in OpenID Connect Discovery [OpenID.Discovery] section 3 that is appropriate for the user. This document MUST have all OAuth related data elements populated. The server MAY return different URLs for users in different domains and the client SHOULD NOT cache a single returned value and assume it - applies for all users/domains that the server suports. + applies for all users/domains that the server suports. The + returned discovery document SHOULD have all data elements + required by the OpenID Connect Discovery specification + populated. In addition, the discovery document SHOULD contain + the 'registration_endpoint' element to learn about the endpoint + to be used with the Dynamic Client Registration protocol + [I-D.ietf-oauth-dyn-reg] to obtain the minimum number of + parameters necessary for the OAuth protocol exchange to + function. Another comparable discovery or client registration + mechanism MAY be used if available. + + The use of the 'offline_access' scope, as defined in + [OpenID.Core] is RECOMMENDED to give clients the capability to + explicitly request a refresh token. If the resource server provides a scope then the client MUST always request scoped tokens from the token endpoint. If the resource server provides no scope to the client then the client SHOULD presume an empty scope (unscoped token) is required to access the resource. + Since clients may interact with a number of application servers, such + as email servers and XMPP servers, they need to have a way to + determine whether dynamic client registration has been performed + already and whether an already available refresh token can be re-used + to obtain an access token for the desired resource server. This + specification RECOMMENDs that a client uses the information in the + 'issue' element to make this determination. + 3.2.3. Completing an Error Message Sequence Section 3.6 of [RFC4422] explicitly prohibits additional information in an unsuccessful authentication outcome. Therefore, the error message is sent in a normal message. The client MUST then send an additional client response consisting of a single %x01 (control A) character to the server in order to allow the server to finish the exchange. 3.3. OAuth Access Token Types using Keyed Message Digests @@ -546,26 +570,22 @@ C: t0 CAPABILITY S: * CAPABILITY IMAP4rev1 AUTH=OAUTHBEARER SASL-IR IMAP4rev1 Server Ready S: t0 OK Completed C: t1 AUTHENTICATE OAUTHBEARER bixhPXVzZXJAZXhhbXBsZS5jb20sAW hvc3Q9c2VydmVyLmV4YW1wbGUuY29tAXBvcnQ9MTQzAWF1dGg9AQE= S: + eyJzdGF0dXMiOiJpbnZhbGlkX3Rva2VuIiwic2NvcGUiOiJleGFtcGxl X3Njb3BlIiwib3BlbmlkLWNvbmZpZ3VyYXRpb24iOiJodHRwczovL2V4 YW1wbGUuY29tLy53ZWxsLWtub3duL29wZW5pZC1jb25maWd1cmF0aW9u In0= - S: + eyJzdGF0dXMiOiI0MDEiLCJzY29wZSI6ImV4YW1wbGVfc2NvcGUiLCJv - cGVuaWQtY29uZmlndXJhdGlvbiI6Imh0dHBzOi8vZXhhbXBsZS5jb20v - LndlbGwta25vd24vb3BlbmlkLWNvbmZpZ3VyYXRpb24ifQ== C: + AQ== S: t1 NO SASL authentication failed - The decoded initial client response is: n,a=user@example.com,^Ahost=server.example.com^A port=143^Aauth=^A^A The decoded server error response is: { "status":"invalid_token", "scope":"example_scope", @@ -705,26 +725,31 @@ SASL mechanism profile: OAUTH10A Security Considerations: See this document Published Specification: See this document For further information: Contact the authors of this document. Owner/Change controller: the IETF + Note: None 8. References 8.1. Normative References + [OpenID.Core] + Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and + C. Mortimore, "OpenID Connect Core 1.0", February 2014. + [OpenID.Discovery] Sakimura, N., Bradley, J., Jones, M., and E. Jay, "OpenID Connect Discovery 1.0", July 2011. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, September 2001. @@ -752,24 +777,30 @@ April 2010. [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC 6749, October 2012. [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization Framework: Bearer Token Usage", RFC 6750, October 2012. 8.2. Informative References + [I-D.ietf-oauth-dyn-reg] + Richer, J., Jones, M., Bradley, J., Machulak, M., and P. + Hunt, "OAuth 2.0 Dynamic Client Registration Protocol", + draft-ietf-oauth-dyn-reg-20 (work in progress), August + 2014. + [I-D.ietf-oauth-json-web-token] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token - (JWT)", draft-ietf-oauth-json-web-token-25 (work in - progress), July 2014. + (JWT)", draft-ietf-oauth-json-web-token-30 (work in + progress), October 2014. [I-D.ietf-oauth-v2-http-mac] Richer, J., Mills, W., Tschofenig, H., and P. Hunt, "OAuth 2.0 Message Authentication Code (MAC) Tokens", draft-ietf- oauth-v2-http-mac-05 (work in progress), January 2014. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. @@ -797,21 +828,27 @@ Williams, Matt Miller, and Benjamin Kaduk. This document was produced under the chairmanship of Alexey Melnikov, Tom Yu, Shawn Emery, Josh Howlett, Sam Hartman. The supervising area director was Stephen Farrell. Appendix B. Document History [[ to be removed by RFC editor before publication as an RFC ]] + -17 + + o Last call feedback again. eradicated comma splicing. Removed + extra server message in example 4.3. + -16 + o Last call feedback again. Primarily editorial changes. Corrected examples. -15 o Last call feedack on the GS2 stuff being ripped out completely. o Removed the "user" parameter and put stuff back into the gs2-header. Call out that the authzid goes in the gs2-header with some prose about when it might be required. Very comparable to