draft-ietf-kitten-sasl-oauth-16.txt   draft-ietf-kitten-sasl-oauth-17.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: March 20, 2015 Expires: May 16, 2015
H. Tschofenig H. Tschofenig
ARM Ltd. ARM Ltd.
September 16, 2014 November 12, 2014
A set of SASL Mechanisms for OAuth A set of SASL Mechanisms for OAuth
draft-ietf-kitten-sasl-oauth-16.txt draft-ietf-kitten-sasl-oauth-17.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 March 20, 2015. This Internet-Draft will expire on May 16, 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 2, line 31 skipping to change at page 2, line 31
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. OAuth SASL Mechanism Specifications . . . . . . . . . . . . . 6 3. OAuth SASL Mechanism Specifications . . . . . . . . . . . . . 6
3.1. Initial Client Response . . . . . . . . . . . . . . . . . 7 3.1. Initial Client Response . . . . . . . . . . . . . . . . . 7
3.1.1. Reserved Key/Values . . . . . . . . . . . . . . . . . 8 3.1.1. Reserved Key/Values . . . . . . . . . . . . . . . . . 8
3.2. Server's Response . . . . . . . . . . . . . . . . . . . . 8 3.2. Server's Response . . . . . . . . . . . . . . . . . . . . 8
3.2.1. OAuth Identifiers in the SASL Context . . . . . . . . 8 3.2.1. OAuth Identifiers in the SASL Context . . . . . . . . 8
3.2.2. Server Response to Failed Authentication . . . . . . 9 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 3.3. OAuth Access Token Types using Keyed Message Digests . . 10
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Successful Bearer Token Exchange . . . . . . . . . . . . 11 4.1. Successful Bearer Token Exchange . . . . . . . . . . . . 11
4.2. Successful OAuth 1.0a Token Exchange . . . . . . . . . . 12 4.2. Successful OAuth 1.0a Token Exchange . . . . . . . . . . 12
4.3. Failed Exchange . . . . . . . . . . . . . . . . . . . . . 13 4.3. Failed Exchange . . . . . . . . . . . . . . . . . . . . . 13
4.4. SMTP Example of a Failed Negotiation . . . . . . . . . . 14 4.4. SMTP Example of a Failed Negotiation . . . . . . . . . . 14
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15
6. Internationalization Considerations . . . . . . . . . . . . . 16 6. Internationalization Considerations . . . . . . . . . . . . . 16
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
7.1. SASL Registration . . . . . . . . . . . . . . . . . . . . 16 7.1. SASL Registration . . . . . . . . . . . . . . . . . . . . 16
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.1. Normative References . . . . . . . . . . . . . . . . . . 17 8.1. Normative References . . . . . . . . . . . . . . . . . . 17
8.2. Informative References . . . . . . . . . . . . . . . . . 18 8.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. Acknowlegements . . . . . . . . . . . . . . . . . . 18 Appendix A. Acknowlegements . . . . . . . . . . . . . . . . . . 19
Appendix B. Document History . . . . . . . . . . . . . . . . . . 18 Appendix B. Document History . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
OAuth 1.0a [RFC5849] and OAuth 2.0 [RFC6749] are protocol frameworks OAuth 1.0a [RFC5849] and OAuth 2.0 [RFC6749] are protocol frameworks
that enable a third-party application to obtain limited access to a that enable 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.
The core OAuth 2.0 specification [RFC6749] specifies the interaction The core OAuth 2.0 specification [RFC6749] specifies the interaction
skipping to change at page 5, line 27 skipping to change at page 5, line 27
(F) The resource server validates the access token, and if valid, (F) The resource server validates the access token, and if valid,
indicates a successful authentication. indicates a successful authentication.
Again, steps (E) and (F) are not defined in [RFC6749] (but are Again, steps (E) and (F) are not defined in [RFC6749] (but are
described in, for example, [RFC6750] for the OAuth Bearer Token described in, for example, [RFC6750] for the OAuth Bearer Token
instead) and are the main functionality specified within this instead) and are the main functionality specified within this
document. Consequently, the message exchange shown in Figure 1 is document. Consequently, the message exchange shown in Figure 1 is
the result of this specification. The client will generally need to the result of this specification. The client will generally need to
determine the authentication endpoints (and perhaps the service determine the authentication endpoints (and perhaps the service
endpoints) before the OAuth 2.0 protocol exchange messages in steps endpoints) before the OAuth 2.0 protocol exchange messages in steps
(A)-(D) are executed. The discovery of the resource owner and (A)-(D) are executed. The discovery of the resource owner,
authorization server endpoints is outside the scope of this authorization server endpoints, and client registration are outside
specification. The client must discover those endpoints using a the scope of this specification. The client must discover the
discovery mechanism, such as Webfinger using host-meta [RFC7033]. In authorization endpoints using a discovery mechanism such as OpenID
band discovery is not tenable if clients support the OAuth 2.0 Connect Discovery [OpenID.Discovery] or Webfinger using host-meta
password grant. Once credentials are obtained the client proceeds to [RFC7033]. Once credentials are obtained the client proceeds to
steps (E) and (F) defined in this specification. 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 OAuth 1.0 follows a similar model but uses a different terminology
and does not separate the resource server from the authorization and does not separate the resource server from the authorization
server. server.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
skipping to change at page 7, line 35 skipping to change at page 7, line 37
protocols are allowed to require an authzid, as are specific server protocols are allowed to require an authzid, as are specific server
implementations. implementations.
The following keys and corresponding values are defined in the client The following keys and corresponding values are defined in the client
response: response:
auth (REQUIRED): The payload that would be in the HTTP auth (REQUIRED): The payload that would be in the HTTP
Authorization header if this OAuth exchange was being carried Authorization header if this OAuth exchange was being carried
out over HTTP. out over HTTP.
host: Contains the host name to which the client connected, in an host: Contains the host name to which the client connected. In
HTTP context this is the value of the HTTP Host header. an HTTP context this is the value of the HTTP Host header.
port: Contains the port number represented as a decimal positive port: Contains the port number represented as a decimal positive
integer string without leading zeros to which the client integer string without leading zeros to which the client
connected. connected.
For OAuth token types such as OAuth 1.0a that use keyed message 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 digests the client MUST send host and port number key/values, and the
server MUST fail an authorization request requiring keyed message server MUST fail an authorization request requiring keyed message
digests that are not accompanied by host and port values. In OAuth digests that are not accompanied by host and port values. In OAuth
1.0a for example, the so-called "signature base string calculation" 1.0a for example, the so-called "signature base string calculation"
skipping to change at page 9, line 32 skipping to change at page 9, line 32
single scope is preferred, use of a space separated list of single scope is preferred, use of a space separated list of
scopes is NOT RECOMMENDED. scopes is NOT RECOMMENDED.
oauth-configuration (OPTIONAL): The URL for for a document oauth-configuration (OPTIONAL): The URL for for a document
following the OpenID Provider Configuration Information schema following the OpenID Provider Configuration Information schema
as described in OpenID Connect Discovery [OpenID.Discovery] as described in OpenID Connect Discovery [OpenID.Discovery]
section 3 that is appropriate for the user. This document MUST section 3 that is appropriate for the user. This document MUST
have all OAuth related data elements populated. The server MAY have all OAuth related data elements populated. The server MAY
return different URLs for users in different domains and the return different URLs for users in different domains and the
client SHOULD NOT cache a single returned value and assume it 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 If the resource server provides a scope then the client MUST always
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
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 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.
3.3. OAuth Access Token Types using Keyed Message Digests 3.3. OAuth Access Token Types using Keyed Message Digests
skipping to change at page 13, line 33 skipping to change at page 13, line 50
C: t0 CAPABILITY C: t0 CAPABILITY
S: * CAPABILITY IMAP4rev1 AUTH=OAUTHBEARER SASL-IR IMAP4rev1 Server S: * CAPABILITY IMAP4rev1 AUTH=OAUTHBEARER SASL-IR IMAP4rev1 Server
Ready Ready
S: t0 OK Completed S: t0 OK Completed
C: t1 AUTHENTICATE OAUTHBEARER bixhPXVzZXJAZXhhbXBsZS5jb20sAW C: t1 AUTHENTICATE OAUTHBEARER bixhPXVzZXJAZXhhbXBsZS5jb20sAW
hvc3Q9c2VydmVyLmV4YW1wbGUuY29tAXBvcnQ9MTQzAWF1dGg9AQE= hvc3Q9c2VydmVyLmV4YW1wbGUuY29tAXBvcnQ9MTQzAWF1dGg9AQE=
S: + eyJzdGF0dXMiOiJpbnZhbGlkX3Rva2VuIiwic2NvcGUiOiJleGFtcGxl S: + eyJzdGF0dXMiOiJpbnZhbGlkX3Rva2VuIiwic2NvcGUiOiJleGFtcGxl
X3Njb3BlIiwib3BlbmlkLWNvbmZpZ3VyYXRpb24iOiJodHRwczovL2V4 X3Njb3BlIiwib3BlbmlkLWNvbmZpZ3VyYXRpb24iOiJodHRwczovL2V4
YW1wbGUuY29tLy53ZWxsLWtub3duL29wZW5pZC1jb25maWd1cmF0aW9u YW1wbGUuY29tLy53ZWxsLWtub3duL29wZW5pZC1jb25maWd1cmF0aW9u
In0= In0=
S: + eyJzdGF0dXMiOiI0MDEiLCJzY29wZSI6ImV4YW1wbGVfc2NvcGUiLCJv
cGVuaWQtY29uZmlndXJhdGlvbiI6Imh0dHBzOi8vZXhhbXBsZS5jb20v
LndlbGwta25vd24vb3BlbmlkLWNvbmZpZ3VyYXRpb24ifQ==
C: + AQ== C: + AQ==
S: t1 NO SASL authentication failed S: t1 NO SASL authentication failed
The decoded initial client response is: The decoded initial client response is:
n,a=user@example.com,^Ahost=server.example.com^A n,a=user@example.com,^Ahost=server.example.com^A
port=143^Aauth=^A^A port=143^Aauth=^A^A
The decoded server error response is: The decoded server error response is:
{ {
"status":"invalid_token", "status":"invalid_token",
"scope":"example_scope", "scope":"example_scope",
skipping to change at page 17, line 4 skipping to change at page 17, line 17
SASL mechanism profile: OAUTH10A SASL mechanism profile: OAUTH10A
Security Considerations: See this document Security Considerations: See this document
Published Specification: See this document Published Specification: See this document
For further information: Contact the authors of this document. For further information: Contact the authors of this document.
Owner/Change controller: the IETF Owner/Change controller: the IETF
Note: None Note: None
8. References 8. References
8.1. Normative 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] [OpenID.Discovery]
Sakimura, N., Bradley, J., Jones, M., and E. Jay, "OpenID Sakimura, N., Bradley, J., Jones, M., and E. Jay, "OpenID
Connect Discovery 1.0", July 2011. Connect Discovery 1.0", July 2011.
[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.
skipping to change at page 18, line 7 skipping to change at page 18, line 21
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.
8.2. Informative References 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] [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-25 (work in (JWT)", draft-ietf-oauth-json-web-token-30 (work in
progress), July 2014. progress), October 2014.
[I-D.ietf-oauth-v2-http-mac] [I-D.ietf-oauth-v2-http-mac]
Richer, J., Mills, W., Tschofenig, H., and P. Hunt, "OAuth Richer, J., Mills, W., Tschofenig, H., and P. Hunt, "OAuth
2.0 Message Authentication Code (MAC) Tokens", draft-ietf- 2.0 Message Authentication Code (MAC) Tokens", draft-ietf-
oauth-v2-http-mac-05 (work in progress), January 2014. 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.
skipping to change at page 18, line 52 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 ]]
-17
o Last call feedback again. eradicated comma splicing. Removed
extra server message in example 4.3.
-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.
o Removed the "user" parameter and put stuff back into the o Removed the "user" parameter and put stuff back into the
gs2-header. Call out that the authzid goes in the gs2-header with gs2-header. Call out that the authzid goes in the gs2-header with
some prose about when it might be required. Very comparable to some prose about when it might be required. Very comparable to
 End of changes. 19 change blocks. 
25 lines changed or deleted 62 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/