--- 1/draft-ietf-kitten-sasl-oauth-17.txt 2014-11-25 12:14:49.117021900 -0800 +++ 2/draft-ietf-kitten-sasl-oauth-18.txt 2014-11-25 12:14:49.161022981 -0800 @@ -1,21 +1,21 @@ KITTEN W. Mills Internet-Draft Microsoft Intended status: Standards Track T. Showalter -Expires: May 16, 2015 +Expires: May 29, 2015 H. Tschofenig ARM Ltd. - November 12, 2014 + November 25, 2014 A set of SASL Mechanisms for OAuth - draft-ietf-kitten-sasl-oauth-17.txt + draft-ietf-kitten-sasl-oauth-18.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 May 16, 2015. + This Internet-Draft will expire on May 29, 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 @@ -97,24 +97,23 @@ 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 between the OAuth client and the authorization server; it does not define the interaction between the OAuth client and the resource server for the access to a protected resource using an Access Token. Instead, the OAuth client to resource server interaction is described in separate specifications, such as the bearer token specification - [RFC6750] and the MAC Token specification - [I-D.ietf-oauth-v2-http-mac]. OAuth 1.0a included the protocol - specification for the communication between the OAuth client and the - resource server in [RFC5849]. + [RFC6750]. OAuth 1.0a included the protocol specification for the + communication between the OAuth client and the resource server in + [RFC5849]. The main use cases for OAuth 2.0 and OAuth 1.0a have so far focused on an HTTP-based [RFC2616] environment only. This document integrates OAuth 1.0a and OAuth 2.0 into non-HTTP-based applications using the integration into SASL. Hence, this document takes advantage of the OAuth protocol and its deployment base to provide a way to use the Simple Authentication and Security Layer (SASL) [RFC4422] to gain access to resources when using non-HTTP-based protocols, such as the Internet Message Access Protocol (IMAP) [RFC3501] and the Simple Mail Transfer Protocol (SMTP) [RFC5321], @@ -357,21 +356,21 @@ about the authentication of the resource owner and about the client and may therefore make this information accessible to the resource server. If both identifiers are needed by an application the developer will need to provide a way to communicate that from the SASL mechanism back to the application. 3.2.2. Server Response to Failed Authentication - For a failed authentication the server returns a JSON [RFC4627] + For a failed authentication the server returns a JSON [RFC7159] formatted error result, and fails the authentication. The error result consists of the following values: status (REQUIRED): The authorization error code. Valid error codes are defined in the IANA "OAuth Extensions Error Registry" specified in the OAuth 2 core specification. scope (OPTIONAL): An OAuth scope which is valid to access the service. This may be empty which implies that unscoped tokens are required, or a scope value. If a scope is specified then a @@ -404,21 +403,22 @@ 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. + 'iss' element defined in OpenID Connect Core [OpenID.Core] 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. @@ -749,23 +749,20 @@ [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. [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006. - [RFC4627] Crockford, D., "The application/json Media Type for - JavaScript Object Notation (JSON)", RFC 4627, July 2006. - [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006. [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [RFC5801] Josefsson, S. and N. Williams, "Using Generic Security @@ -775,37 +772,35 @@ [RFC5849] Hammer-Lahav, E., "The OAuth 1.0 Protocol", RFC 5849, 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. + [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data + Interchange Format", RFC 7159, March 2014. + 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-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. + (JWT)", draft-ietf-oauth-json-web-token-31 (work in + progress), November 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. [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003. [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008. @@ -828,24 +823,33 @@ 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 ]] + -18 + + o Last call feedback round #5. Fixed -17 change log. + + o Corrected "issue" to "iss", other minor changes. + -17 - o Last call feedback again. eradicated comma splicing. Removed - extra server message in example 4.3. + o Last call feedback again (WGLC #4). eradicated comma splicing. + Removed extra server message in example 4.3. + + o Added recommendations for discovery and dynamic client + registration support. -16 o Last call feedback again. Primarily editorial changes. Corrected examples. -15 o Last call feedack on the GS2 stuff being ripped out completely.