draft-ietf-kitten-sasl-oauth-17.txt   draft-ietf-kitten-sasl-oauth-18.txt 
KITTEN W. Mills KITTEN W. Mills
Internet-Draft Microsoft Internet-Draft Microsoft
Intended status: Standards Track T. Showalter Intended status: Standards Track T. Showalter
Expires: May 16, 2015 Expires: May 29, 2015
H. Tschofenig H. Tschofenig
ARM Ltd. ARM Ltd.
November 12, 2014 November 25, 2014
A set of SASL Mechanisms for OAuth A set of SASL Mechanisms for OAuth
draft-ietf-kitten-sasl-oauth-17.txt draft-ietf-kitten-sasl-oauth-18.txt
Abstract Abstract
OAuth enables a third-party application to obtain limited access to a OAuth enables a third-party application to obtain limited access to a
protected resource, either on behalf of a resource owner by protected resource, either on behalf of a resource owner by
orchestrating an approval interaction, or by allowing the third-party orchestrating an approval interaction, or by allowing the third-party
application to obtain access on its own behalf. application to obtain access on its own behalf.
This document defines how an application client uses credentials This document defines how an application client uses credentials
obtained via OAuth over the Simple Authentication and Security Layer obtained via OAuth over the Simple Authentication and Security Layer
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 19 skipping to change at page 3, line 19
protected resource, either on behalf of a resource owner by protected resource, either on behalf of a resource owner by
orchestrating an approval interaction, or by allowing the third-party orchestrating an approval interaction, or by allowing the third-party
application to obtain access on its own behalf. application to obtain access on its own behalf.
The core OAuth 2.0 specification [RFC6749] specifies the interaction The core OAuth 2.0 specification [RFC6749] specifies the interaction
between the OAuth client and the authorization server; it does not between the OAuth client and the authorization server; it does not
define the interaction between the OAuth client and the resource define the interaction between the OAuth client and the resource
server for the access to a protected resource using an Access Token. server for the access to a protected resource using an Access Token.
Instead, the OAuth client to resource server interaction is described Instead, the OAuth client to resource server interaction is described
in separate specifications, such as the bearer token specification in separate specifications, such as the bearer token specification
[RFC6750] and the MAC Token specification [RFC6750]. OAuth 1.0a included the protocol specification for the
[I-D.ietf-oauth-v2-http-mac]. OAuth 1.0a included the protocol communication between the OAuth client and the resource server in
specification for the communication between the OAuth client and the [RFC5849].
resource server in [RFC5849].
The main use cases for OAuth 2.0 and OAuth 1.0a have so far focused 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 on an HTTP-based [RFC2616] environment only. This document
integrates OAuth 1.0a and OAuth 2.0 into non-HTTP-based applications integrates OAuth 1.0a and OAuth 2.0 into non-HTTP-based applications
using the integration into SASL. Hence, this document takes using the integration into SASL. Hence, this document takes
advantage of the OAuth protocol and its deployment base to provide a advantage of the OAuth protocol and its deployment base to provide a
way to use the Simple Authentication and Security Layer (SASL) way to use the Simple Authentication and Security Layer (SASL)
[RFC4422] to gain access to resources when using non-HTTP-based [RFC4422] to gain access to resources when using non-HTTP-based
protocols, such as the Internet Message Access Protocol (IMAP) protocols, such as the Internet Message Access Protocol (IMAP)
[RFC3501] and the Simple Mail Transfer Protocol (SMTP) [RFC5321], [RFC3501] and the Simple Mail Transfer Protocol (SMTP) [RFC5321],
skipping to change at page 9, line 11 skipping to change at page 9, line 11
about the authentication of the resource owner and about the client about the authentication of the resource owner and about the client
and may therefore make this information accessible to the resource and may therefore make this information accessible to the resource
server. server.
If both identifiers are needed by an application the developer will If both identifiers are needed by an application the developer will
need to provide a way to communicate that from the SASL mechanism need to provide a way to communicate that from the SASL mechanism
back to the application. back to the application.
3.2.2. Server Response to Failed Authentication 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 formatted error result, and fails the authentication. The error
result consists of the following values: result consists of the following values:
status (REQUIRED): The authorization error code. Valid error status (REQUIRED): The authorization error code. Valid error
codes are defined in the IANA "OAuth Extensions Error Registry" codes are defined in the IANA "OAuth Extensions Error Registry"
specified in the OAuth 2 core specification. specified in the OAuth 2 core specification.
scope (OPTIONAL): An OAuth scope which is valid to access the scope (OPTIONAL): An OAuth scope which is valid to access the
service. This may be empty which implies that unscoped tokens service. This may be empty which implies that unscoped tokens
are required, or a scope value. If a scope is specified then a are required, or a scope value. If a scope is specified then a
skipping to change at page 10, line 11 skipping to change at page 10, line 11
request scoped tokens from the token endpoint. If the resource request scoped tokens from the token endpoint. If the resource
server provides no scope to the client then the client SHOULD presume server provides no scope to the client then the client SHOULD presume
an empty scope (unscoped token) is required to access the resource. an empty scope (unscoped token) is required to access the resource.
Since clients may interact with a number of application servers, such Since clients may interact with a number of application servers, such
as email servers and XMPP servers, they need to have a way to as email servers and XMPP servers, they need to have a way to
determine whether dynamic client registration has been performed determine whether dynamic client registration has been performed
already and whether an already available refresh token can be re-used already and whether an already available refresh token can be re-used
to obtain an access token for the desired resource server. This to obtain an access token for the desired resource server. This
specification RECOMMENDs that a client uses the information in the 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 3.2.3. Completing an Error Message Sequence
Section 3.6 of [RFC4422] explicitly prohibits additional information Section 3.6 of [RFC4422] explicitly prohibits additional information
in an unsuccessful authentication outcome. Therefore, the error in an unsuccessful authentication outcome. Therefore, the error
message is sent in a normal message. The client MUST then send an message is sent in a normal message. The client MUST then send an
additional client response consisting of a single %x01 (control A) additional client response consisting of a single %x01 (control A)
character to the server in order to allow the server to finish the character to the server in order to allow the server to finish the
exchange. exchange.
skipping to change at page 17, line 41 skipping to change at page 17, line 41
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 [RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1
(SHA1)", RFC 3174, September 2001. (SHA1)", RFC 3174, September 2001.
[RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and
Security Layer (SASL)", RFC 4422, June 2006. 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 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006. Encodings", RFC 4648, October 2006.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5801] Josefsson, S. and N. Williams, "Using Generic Security [RFC5801] Josefsson, S. and N. Williams, "Using Generic Security
skipping to change at page 18, line 19 skipping to change at page 18, line 19
[RFC5849] Hammer-Lahav, E., "The OAuth 1.0 Protocol", RFC 5849, [RFC5849] Hammer-Lahav, E., "The OAuth 1.0 Protocol", RFC 5849,
April 2010. April 2010.
[RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC
6749, October 2012. 6749, October 2012.
[RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
Framework: Bearer Token Usage", RFC 6750, October 2012. 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 8.2. Informative References
[I-D.ietf-oauth-dyn-reg] [I-D.ietf-oauth-dyn-reg]
Richer, J., Jones, M., Bradley, J., Machulak, M., and P. Richer, J., Jones, M., Bradley, J., Machulak, M., and P.
Hunt, "OAuth 2.0 Dynamic Client Registration Protocol", Hunt, "OAuth 2.0 Dynamic Client Registration Protocol",
draft-ietf-oauth-dyn-reg-20 (work in progress), August draft-ietf-oauth-dyn-reg-20 (work in progress), August
2014. 2014.
[I-D.ietf-oauth-json-web-token] [I-D.ietf-oauth-json-web-token]
Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", draft-ietf-oauth-json-web-token-30 (work in (JWT)", draft-ietf-oauth-json-web-token-31 (work in
progress), October 2014. progress), November 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., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, March 2003. 4rev1", RFC 3501, March 2003.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
October 2008. October 2008.
skipping to change at page 19, line 23 skipping to change at page 19, line 23
Williams, Matt Miller, and Benjamin Kaduk. Williams, Matt Miller, and Benjamin Kaduk.
This document was produced under the chairmanship of Alexey Melnikov, This document was produced under the chairmanship of Alexey Melnikov,
Tom Yu, Shawn Emery, Josh Howlett, Sam Hartman. The supervising area Tom Yu, Shawn Emery, Josh Howlett, Sam Hartman. The supervising area
director was Stephen Farrell. director was Stephen Farrell.
Appendix B. Document History Appendix B. Document History
[[ to be removed by RFC editor before publication as an RFC ]] [[ 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 -17
o Last call feedback again. eradicated comma splicing. Removed o Last call feedback again (WGLC #4). eradicated comma splicing.
extra server message in example 4.3. Removed extra server message in example 4.3.
o Added recommendations for discovery and dynamic client
registration support.
-16 -16
o Last call feedback again. Primarily editorial changes. Corrected o Last call feedback again. Primarily editorial changes. Corrected
examples. examples.
-15 -15
o Last call feedack on the GS2 stuff being ripped out completely. o Last call feedack on the GS2 stuff being ripped out completely.
 End of changes. 12 change blocks. 
22 lines changed or deleted 26 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/