draft-ietf-kitten-sasl-oauth-18.txt   draft-ietf-kitten-sasl-oauth-19.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 29, 2015 Expires: July 24, 2015
H. Tschofenig H. Tschofenig
ARM Ltd. ARM Ltd.
November 25, 2014 January 20, 2015
A set of SASL Mechanisms for OAuth A set of SASL Mechanisms for OAuth
draft-ietf-kitten-sasl-oauth-18.txt draft-ietf-kitten-sasl-oauth-19.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 29, 2015. This Internet-Draft will expire on July 24, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
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 . . . . . . . . 9
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 . . . . . . . . 10 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 . . . . . . . . . . . . 12
4.2. Successful OAuth 1.0a Token Exchange . . . . . . . . . . 12 4.2. Successful OAuth 1.0a Token Exchange . . . . . . . . . . 13
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 . . . . . . . . . . 15
5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15
6. Internationalization Considerations . . . . . . . . . . . . . 16 6. Internationalization Considerations . . . . . . . . . . . . . 17
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
7.1. SASL Registration . . . . . . . . . . . . . . . . . . . . 16 7.1. SASL Registration . . . . . . . . . . . . . . . . . . . . 17
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.1. Normative References . . . . . . . . . . . . . . . . . . 17 8.1. Normative References . . . . . . . . . . . . . . . . . . 18
8.2. Informative References . . . . . . . . . . . . . . . . . 18 8.2. Informative References . . . . . . . . . . . . . . . . . 19
Appendix A. Acknowlegements . . . . . . . . . . . . . . . . . . 19 Appendix A. Acknowlegements . . . . . . . . . . . . . . . . . . 19
Appendix B. Document History . . . . . . . . . . . . . . . . . . 19 Appendix B. Document History . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
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 6, line 38 skipping to change at page 6, line 38
further definition. further definition.
These mechanisms are client initiated and lock-step, the server These mechanisms are client initiated and lock-step, the server
always replying to a client message. In the case where the client always replying to a client message. In the case where the client
has and correctly uses a valid token the flow is: has and correctly uses a valid token the flow is:
1. Client sends a valid and correct initial client response. 1. Client sends a valid and correct initial client response.
2. Server responds with a successful authentication. 2. Server responds with a successful authentication.
In the case where authorization fails the server sends an error In the case where authentication fails the server sends an error
result, then client MUST then send an additional message to the result, then client MUST then send an additional message to the
server in order to allow the server to finish the exchange. Some server in order to allow the server to finish the exchange. Some
protocols and common SASL implementations do not support both sending protocols and common SASL implementations do not support both sending
a SASL message and finalizing a SASL negotiation, the additional a SASL message and finalizing a SASL negotiation. The additional
client message in the error case deals with this problem. This client message in the error case deals with this problem. This
exchange is: exchange is:
1. Client sends an invalid initial client response. 1. Client sends an invalid initial client response.
2. Server responds with an error message. 2. Server responds with an error message.
3. Client sends a dummy client response. 3. Client sends a dummy client response.
4. Server fails the authentication. 4. Server fails the authentication.
skipping to change at page 7, line 19 skipping to change at page 7, line 19
Client responses are a GS2 [RFC5801] header followed by zero or more Client responses are a GS2 [RFC5801] header followed by zero or more
key/value pairs, or may be empty. The gs2-header is defined here for key/value pairs, or may be empty. The gs2-header is defined here for
compatibility with GS2 if a GS2 mechanism is formally defined, but compatibility with GS2 if a GS2 mechanism is formally defined, but
this document does not define one. These key/value pairs take the this document does not define one. These key/value pairs take the
place of the corresponding HTTP headers and values to convey the place of the corresponding HTTP headers and values to convey the
information necessary to complete an OAuth style HTTP authorization. information necessary to complete an OAuth style HTTP authorization.
Unknown key/value pairs MUST be ignored by the server. The ABNF Unknown key/value pairs MUST be ignored by the server. The ABNF
[RFC5234] syntax is: [RFC5234] syntax is:
kvsep = %x01 kvsep = %x01
key = 1*(ALPHA / ",") key = 1*(ALPHA)
value = *(VCHAR / SP / HTAB / CR / LF ) value = *(VCHAR / SP / HTAB / CR / LF )
kvpair = key "=" value kvsep kvpair = key "=" value kvsep
;;gs2-header = See RFC 5801 ;;gs2-header = See RFC 5801
client_resp = (gs2-header kvsep 0*kvpair kvsep) / kvsep client_resp = (gs2-header kvsep 0*kvpair kvsep) / kvsep
The GS2 header MAY include the user name associated with the resource The GS2 header MAY include the user name associated with the resource
being accessed, the "authzid". It is worth noting that application being accessed, the "authzid". It is worth noting that application
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 client response consisting of only a single kvsep is used only
when authentication fails, and is only valid in that context. If
sent as the first message from the client the server MAY simply fail
the authentication without returning discovery information since
there is no user or server name indication.
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 host: Contains the host name to which the client connected. In
an HTTP context this is the value of the HTTP Host header. an HTTP context this is the value of the HTTP Host header.
skipping to change at page 8, line 10 skipping to change at page 8, line 17
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"
includes the reconstructed HTTP URL. includes the reconstructed HTTP URL.
3.1.1. Reserved Key/Values 3.1.1. Reserved Key/Values
In these mechanisms values for path, query string and post body are In these mechanisms values for path, query string and post body are
assigned default values. OAuth authorization schemes MAY define assigned default values. OAuth authorization schemes MAY define
usage of these in the SASL context and extend this specification. usage of these in the SASL context and extend this specification.
For OAuth Access Token Types that use request keyed message digest For OAuth Access Token Types that include a keyed message digest of
the default values MUST be used unless explicit values are provided the request the default values MUST be used unless explicit values
in the client response. The following key values are reserved for are provided in the client response. The following key values are
future use: reserved for future use:
mthd (RESERVED): HTTP method, the default value is "POST". mthd (RESERVED): HTTP method, the default value is "POST".
path (RESERVED): HTTP path data, the default value is "/". path (RESERVED): HTTP path data, the default value is "/".
post (RESERVED): HTTP post data, the default value is "". post (RESERVED): HTTP post data, the default value is "".
qs (RESERVED): The HTTP query string, the default value is "". qs (RESERVED): The HTTP query string, the default value is "".
3.2. Server's Response 3.2. Server's Response
skipping to change at page 8, line 37 skipping to change at page 8, line 44
utilizes a keyed message digest of the request parameters then the utilizes a keyed message digest of the request parameters then the
client must provide a client response that satisfies the data client must provide a client response that satisfies the data
requirements for the scheme in use. requirements for the scheme in use.
The server responds to a successfully verified client message by The server responds to a successfully verified client message by
completing the SASL negotiation. The authenticated identity reported completing the SASL negotiation. The authenticated identity reported
by the SASL mechanism is the identity securely established for the by the SASL mechanism is the identity securely established for the
client with the OAuth credential. The application, not the SASL client with the OAuth credential. The application, not the SASL
mechanism, based on local access policy determines whether the mechanism, based on local access policy determines whether the
identity reported by the mechanism is allowed access to the requested identity reported by the mechanism is allowed access to the requested
resource. Note that the semantics of the authz-id is specified by resource. Note that the semantics of the authorization identity is
the SASL framework [RFC4422]. specified by the SASL framework [RFC4422].
3.2.1. OAuth Identifiers in the SASL Context 3.2.1. OAuth Identifiers in the SASL Context
In the OAuth framework the client may be authenticated by the In the OAuth framework the client may be authenticated by the
authorization server and the resource owner is authenticated to the authorization server and the resource owner is authenticated to the
authorization server. OAuth access tokens may contain information authorization server. OAuth access tokens may contain information
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.
skipping to change at page 9, line 25 skipping to change at page 9, line 34
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
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 openid-configuration (OPTIONAL): The URL for a document following
following the OpenID Provider Configuration Information schema the OpenID Provider Configuration Information schema as
as described in OpenID Connect Discovery [OpenID.Discovery] described in OpenID Connect Discovery (OIDCD)
section 3 that is appropriate for the user. This document MUST [OpenID.Discovery] section 3 that is appropriate for the user.
have all OAuth related data elements populated. The server MAY As specified in OIDCD this will have the "https" URL scheme.
return different URLs for users in different domains and the This document MUST have all OAuth related data elements
client SHOULD NOT cache a single returned value and assume it populated. The server MAY return different URLs for users in
applies for all users/domains that the server suports. The different domains and the client SHOULD NOT cache a single
returned discovery document SHOULD have all data elements returned value and assume it applies for all users/domains that
required by the OpenID Connect Discovery specification the server suports. The returned discovery document SHOULD
populated. In addition, the discovery document SHOULD contain have all data elements required by the OpenID Connect Discovery
the 'registration_endpoint' element to learn about the endpoint specification populated. In addition, the discovery document
to be used with the Dynamic Client Registration protocol SHOULD contain the 'registration_endpoint' element to learn
[I-D.ietf-oauth-dyn-reg] to obtain the minimum number of about the endpoint to be used with the Dynamic Client
parameters necessary for the OAuth protocol exchange to Registration protocol [I-D.ietf-oauth-dyn-reg] to obtain the
function. Another comparable discovery or client registration minimum number of parameters necessary for the OAuth protocol
mechanism MAY be used if available. 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 The use of the 'offline_access' scope, as defined in
[OpenID.Core] is RECOMMENDED to give clients the capability to [OpenID.Core] is RECOMMENDED to give clients the capability to
explicitly request a refresh token. 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.
skipping to change at page 10, line 16 skipping to change at page 10, line 27
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
'iss' element defined in OpenID Connect Core [OpenID.Core] to make 'iss' element defined in OpenID Connect Core [OpenID.Core] to make
this determination. 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 SASL [RFC4422] explicitly prohibits additional
in an unsuccessful authentication outcome. Therefore, the error information in an unsuccessful authentication outcome. Therefore,
message is sent in a normal message. The client MUST then send an the error message is sent in a normal message. The client MUST then
additional client response consisting of a single %x01 (control A) send either an additional client response consisting of a single %x01
character to the server in order to allow the server to finish the (control A) character to the server in order to allow the server to
exchange. finish the exchange or send a SASL cancellation token as generally
defined in section 3.5 of SASL [RFC4422]. A specific example of a
cancellation token can be found in IMAP [RFC3501] section 6.2.2.
3.3. OAuth Access Token Types using Keyed Message Digests 3.3. OAuth Access Token Types using Keyed Message Digests
OAuth Access Token Types may use keyed message digests and the client OAuth Access Token Types may use keyed message digests and the client
and the resource server may need to perform a cryptographic and the resource server may need to perform a cryptographic
computation for integrity protection and data origin authentication. computation for integrity protection and data origin authentication.
OAuth is designed for access to resources identified by URIs. SASL OAuth is designed for access to resources identified by URIs. SASL
is designed for user authentication, and has no facility for more is designed for user authentication, and has no facility for more
fine-grained access control. In this specification we require or fine-grained access control. In this specification we require or
skipping to change at page 11, line 38 skipping to change at page 11, line 43
In this example the signature base string with line breaks added for In this example the signature base string with line breaks added for
readability would be: readability would be:
POST&http%3A%2F%2Fexample.com:143%2F&oauth_consumer_key%3D9djdj82h4 POST&http%3A%2F%2Fexample.com:143%2F&oauth_consumer_key%3D9djdj82h4
8djs9d2%26oauth_nonce%3D7d8f3e4a%26oauth_signature_method%3DHMAC-SH 8djs9d2%26oauth_nonce%3D7d8f3e4a%26oauth_signature_method%3DHMAC-SH
A1%26oauth_timestamp%3D137131201%26oauth_token%3Dkkk9d7dh3k39sjv7 A1%26oauth_timestamp%3D137131201%26oauth_token%3Dkkk9d7dh3k39sjv7
4. Examples 4. Examples
These examples illustrate exchanges between IMAP and SMTP clients and These examples illustrate exchanges between IMAP and SMTP clients and
servers. servers. All IMAP examples use SASL-IR [RFC4959] and send payload in
the initial client response. The Bearer Token examples assume
encrypted transport, if the underlying connection is not already TLS
then STARTTLS MUST be used as TLS is required in the Bearer Token
specification.
Note to implementers: The SASL OAuth method names are case Note to implementers: The SASL OAuth method names are case
insensitive. One example uses "Bearer" but that could as easily be insensitive. One example uses "Bearer" but that could as easily be
"bearer", "BEARER", or "BeArEr". "bearer", "BEARER", or "BeArEr".
4.1. Successful Bearer Token Exchange 4.1. Successful Bearer Token Exchange
This example shows a successful OAuth 2.0 bearer token exchange in This example shows a successful OAuth 2.0 bearer token exchange in
IMAP. Note that line breaks are inserted for readability and the IMAP. Note that line breaks are inserted for readability. The
underlying TLS establishment is not shown either. underlying TLS establishment is not shown but is required for using
Bearer Tokens per that specification.
S: * OK IMAP4rev1 Server Ready S: * OK IMAP4rev1 Server Ready
C: t0 CAPABILITY C: t0 CAPABILITY
S: * CAPABILITY IMAP4rev1 AUTH=OAUTHBEARER SASL-IR S: * CAPABILITY IMAP4rev1 AUTH=OAUTHBEARER SASL-IR
S: t0 OK Completed S: t0 OK Completed
C: t1 AUTHENTICATE OAUTHBEARER bixhPXVzZXJAZXhhbXBsZS5jb20sAWhvc3Q9c2 C: t1 AUTH OAUTHBEARER bixhPXVzZXJAZXhhbXBsZS5jb20sAWhvc3Q9c2
VydmVyLmV4YW1wbGUuY29tAXBvcnQ9MTQzAWF1dGg9QmVhcmVyIHZGOWRmdDRxb VydmVyLmV4YW1wbGUuY29tAXBvcnQ9MTQzAWF1dGg9QmVhcmVyIHZGOWRmdDRxb
VRjMk52YjNSbGNrQmhiSFJoZG1semRHRXVZMjl0Q2c9PQEB VRjMk52YjNSbGNrQmhiSFJoZG1semRHRXVZMjl0Q2c9PQEB
S: t1 OK SASL authentication succeeded S: t1 OK SASL authentication succeeded
As required by IMAP [RFC3501], the payloads are base64-encoded. The As required by IMAP [RFC3501], the payloads are base64-encoded. The
decoded initial client response (with %x01 represented as ^A and long decoded initial client response (with %x01 represented as ^A and long
lines wrapped for readability) is: lines wrapped for readability) is:
n,a=user@example.com,^Ahost=server.example.com^Aport=143^A n,a=user@example.com,^Ahost=server.example.com^Aport=143^A
auth=Bearer vF9dft4qmTc2Nvb3RlckBhbHRhdmlzdGEuY29tCg==^A^A auth=Bearer vF9dft4qmTc2Nvb3RlckBhbHRhdmlzdGEuY29tCg==^A^A
The same credential used in an SMTP exchange is shown below. Note The same credential used in an SMTP exchange is shown below. Note
that line breaks are inserted for readability, and that the SMTP that line breaks are inserted for readability, and that the SMTP
protocol terminates lines with CR and LF characters (ASCII values protocol terminates lines with CR and LF characters (ASCII values
0x0D and 0x0A), these are not displayed explicitly in the example. 0x0D and 0x0A), these are not displayed explicitly in the example.
Again this example assumes that TLS is already established per the
Bearer Token specification requirements.
[connection begins] [connection begins]
S: 220 mx.example.com ESMTP 12sm2095603fks.9 S: 220 mx.example.com ESMTP 12sm2095603fks.9
C: EHLO sender.example.com C: EHLO sender.example.com
S: 250-mx.example.com at your service,[172.31.135.47] S: 250-mx.example.com at your service,[172.31.135.47]
S: 250-SIZE 35651584 S: 250-SIZE 35651584
S: 250-8BITMIME S: 250-8BITMIME
S: 250-AUTH LOGIN PLAIN OAUTHBEARER S: 250-AUTH LOGIN PLAIN OAUTHBEARER
S: 250-ENHANCEDSTATUSCODES S: 250-ENHANCEDSTATUSCODES
S: 250-STARTTLS
S: 250 PIPELINING S: 250 PIPELINING
C: t1 AUTHENTICATE OAUTHBEARER bixhPXVzZXJAZXhhbXBsZS5jb20sAWhvc3Q9c [Negotiate TLS...]
C: t1 AUTH OAUTHBEARER bixhPXVzZXJAZXhhbXBsZS5jb20sAWhvc3Q9c
2VydmVyLmV4YW1wbGUuY29tAXBvcnQ9MTQzAWF1dGg9QmVhcmVyIHZGOWRmdDR 2VydmVyLmV4YW1wbGUuY29tAXBvcnQ9MTQzAWF1dGg9QmVhcmVyIHZGOWRmdDR
xbVRjMk52YjNSbGNrQmhiSFJoZG1semRHRXVZMjl0Q2c9PQEB xbVRjMk52YjNSbGNrQmhiSFJoZG1semRHRXVZMjl0Q2c9PQEB
S: 235 Authentication successful. S: 235 Authentication successful.
[connection continues...] [connection continues...]
4.2. Successful OAuth 1.0a Token Exchange 4.2. Successful OAuth 1.0a Token Exchange
This IMAP example shows a successful OAuth 1.0a token exchange. Note This IMAP example shows a successful OAuth 1.0a token exchange. Note
that line breaks are inserted for readability and the underlying TLS that line breaks are inserted for readability. This example assumes
establishment is not shown. Signature computation is discussed in that TLS is already established. Signature computation is discussed
Section 3.3. in Section 3.3.
S: * OK IMAP4rev1 Server Ready S: * OK IMAP4rev1 Server Ready
C: t0 CAPABILITY C: t0 CAPABILITY
S: * CAPABILITY IMAP4rev1 AUTH=OAUTHBEARER OAUTH10A SASL-IR S: * CAPABILITY IMAP4rev1 AUTH=OAUTHBEARER OAUTH10A SASL-IR
S: t0 OK Completed S: t0 OK Completed
C: t1 AUTHENTICATE OAUTH10A bixhPXVzZXJAZXhhbXBsZS5jb20sAWhvc3Q9ZXhhb C: t1 AUTH OAUTH10A bixhPXVzZXJAZXhhbXBsZS5jb20sAWhvc3Q9ZXhhb
XBsZS5jb20BcG9ydD0xNDMBYXV0aD1PQXV0aCByZWFsbT0iRXhhbXBsZSIsb2F1 XBsZS5jb20BcG9ydD0xNDMBYXV0aD1PQXV0aCByZWFsbT0iRXhhbXBsZSIsb2F1
dGhfY29uc3VtZXJfa2V5PSI5ZGpkajgyaDQ4ZGpzOWQyIixvYXV0aF90b2tlbj0 dGhfY29uc3VtZXJfa2V5PSI5ZGpkajgyaDQ4ZGpzOWQyIixvYXV0aF90b2tlbj0
ia2trOWQ3ZGgzazM5c2p2NyIsb2F1dGhfc2lnbmF0dXJlX21ldGhvZD0iSE1BQy ia2trOWQ3ZGgzazM5c2p2NyIsb2F1dGhfc2lnbmF0dXJlX21ldGhvZD0iSE1BQy
1TSEExIixvYXV0aF90aW1lc3RhbXA9IjEzNzEzMTIwMSIsb2F1dGhfbm9uY2U9I 1TSEExIixvYXV0aF90aW1lc3RhbXA9IjEzNzEzMTIwMSIsb2F1dGhfbm9uY2U9I
jdkOGYzZTRhIixvYXV0aF9zaWduYXR1cmU9IlRtOTBJR0VnY21WaGJDQnphV2R1 jdkOGYzZTRhIixvYXV0aF9zaWduYXR1cmU9IlRtOTBJR0VnY21WaGJDQnphV2R1
WVhSMWNtVSUzRCIBAQ== WVhSMWNtVSUzRCIBAQ==
S: t1 OK SASL authentication succeeded S: t1 OK SASL authentication succeeded
As required by IMAP [RFC3501], the payloads are base64-encoded. The As required by IMAP [RFC3501], the payloads are base64-encoded. The
decoded initial client response (with %x01 represented as ^A and decoded initial client response (with %x01 represented as ^A and
skipping to change at page 13, line 41 skipping to change at page 14, line 7
oauth_signature="SSdtIGEgbGl0dGxlIHRlYSBwb3Qu"^A^A oauth_signature="SSdtIGEgbGl0dGxlIHRlYSBwb3Qu"^A^A
4.3. Failed Exchange 4.3. Failed Exchange
This IMAP example shows a failed exchange because of the empty This IMAP example shows a failed exchange because of the empty
Authorization header, which is how a client can query for the needed Authorization header, which is how a client can query for the needed
scope. Note that line breaks are inserted for readability. scope. Note that line breaks are inserted for readability.
S: * OK IMAP4rev1 Server Ready S: * OK IMAP4rev1 Server Ready
C: t0 CAPABILITY C: t0 CAPABILITY
S: * CAPABILITY IMAP4rev1 AUTH=OAUTHBEARER SASL-IR IMAP4rev1 Server S: * CAPABILITY IMAP4rev1 AUTH=OAUTHBEARER SASL-IR
Ready
S: t0 OK Completed S: t0 OK Completed
C: t1 AUTHENTICATE OAUTHBEARER bixhPXVzZXJAZXhhbXBsZS5jb20sAW C: t1 AUTH OAUTHBEARER bixhPXVzZXJAZXhhbXBsZS5jb20sAW
hvc3Q9c2VydmVyLmV4YW1wbGUuY29tAXBvcnQ9MTQzAWF1dGg9AQE= hvc3Q9c2VydmVyLmV4YW1wbGUuY29tAXBvcnQ9MTQzAWF1dGg9AQE=
S: + eyJzdGF0dXMiOiJpbnZhbGlkX3Rva2VuIiwic2NvcGUiOiJleGFtcGxl S: + eyJzdGF0dXMiOiJpbnZhbGlkX3Rva2VuIiwic2NvcGUiOiJleGFtcGxl
X3Njb3BlIiwib3BlbmlkLWNvbmZpZ3VyYXRpb24iOiJodHRwczovL2V4 X3Njb3BlIiwib3BlbmlkLWNvbmZpZ3VyYXRpb24iOiJodHRwczovL2V4
YW1wbGUuY29tLy53ZWxsLWtub3duL29wZW5pZC1jb25maWd1cmF0aW9u YW1wbGUuY29tLy53ZWxsLWtub3duL29wZW5pZC1jb25maWd1cmF0aW9u
In0= In0=
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 14, line 18 skipping to change at page 14, line 32
The decoded server error response is: The decoded server error response is:
{ {
"status":"invalid_token", "status":"invalid_token",
"scope":"example_scope", "scope":"example_scope",
"openid-configuration":"https://example.com/.well-known/openid-configuration" "openid-configuration":"https://example.com/.well-known/openid-configuration"
} }
The client responds with the required dummy response, "AQ==" is the The client responds with the required dummy response, "AQ==" is the
base64 encoding of the ASCII value 0x01. base64 encoding of the ASCII value 0x01. The same exchange using the
IMAP specific method of cancelling an AUTHENTICATE command sends "*"
and is shown below.
S: * OK IMAP4rev1 Server Ready
C: t0 CAPABILITY
S: * CAPABILITY IMAP4rev1 AUTH=OAUTHBEARER SASL-IR IMAP4rev1
S: t0 OK Completed
C: t1 AUTH OAUTHBEARER bixhPXVzZXJAZXhhbXBsZS5jb20sAW
hvc3Q9c2VydmVyLmV4YW1wbGUuY29tAXBvcnQ9MTQzAWF1dGg9AQE=
S: + eyJzdGF0dXMiOiJpbnZhbGlkX3Rva2VuIiwic2NvcGUiOiJleGFtcGxl
X3Njb3BlIiwib3BlbmlkLWNvbmZpZ3VyYXRpb24iOiJodHRwczovL2V4
YW1wbGUuY29tLy53ZWxsLWtub3duL29wZW5pZC1jb25maWd1cmF0aW9u
In0=
C: *
S: t1 NO SASL authentication failed
4.4. SMTP Example of a Failed Negotiation 4.4. SMTP Example of a Failed Negotiation
This example shows an authorization failure in an SMTP exchange. This example shows an authorization failure in an SMTP exchange.
Note that line breaks are inserted for readability, and that the SMTP Note that line breaks are inserted for readability, and that the SMTP
protocol terminates lines with CR and LF characters (ASCII values protocol terminates lines with CR and LF characters (ASCII values
0x0D and 0x0A), these are not displayed explicitly in the example. 0x0D and 0x0A), these are not displayed explicitly in the example.
TLS negotiation is not shown but as noted above it is required for
the use of Bearer Tokens.
[connection begins] [connection begins]
S: 220 mx.example.com ESMTP 12sm2095603fks.9 S: 220 mx.example.com ESMTP 12sm2095603fks.9
C: EHLO sender.example.com C: EHLO sender.example.com
S: 250-mx.example.com at your service,[172.31.135.47] S: 250-mx.example.com at your service,[172.31.135.47]
S: 250-SIZE 35651584 S: 250-SIZE 35651584
S: 250-8BITMIME S: 250-8BITMIME
S: 250-AUTH LOGIN PLAIN OAUTHBEARER S: 250-AUTH LOGIN PLAIN OAUTHBEARER
S: 250-ENHANCEDSTATUSCODES S: 250-ENHANCEDSTATUSCODES
S: 250 PIPELINING S: 250 PIPELINING
skipping to change at page 17, line 35 skipping to change at page 18, line 21
Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and
C. Mortimore, "OpenID Connect Core 1.0", February 2014. 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.
[RFC2244] Newman, C. and J. Myers, "ACAP -- Application
Configuration Access Protocol", RFC 2244, November 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.
[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
skipping to change at page 18, line 27 skipping to change at page 19, line 13
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 [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, March 2014. 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-22 (work in progress), January
2014. 2015.
[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-31 (work in (JWT)", draft-ietf-oauth-json-web-token-32 (work in
progress), November 2014. progress), December 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.
[RFC4959] Siemborski, R. and A. Gulbrandsen, "IMAP Extension for
Simple Authentication and Security Layer (SASL) Initial
Client Response", RFC 4959, September 2007.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
October 2008. October 2008.
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Core", RFC 6120, March 2011. Protocol (XMPP): Core", RFC 6120, March 2011.
[RFC6819] Lodderstedt, T., McGloin, M., and P. Hunt, "OAuth 2.0 [RFC6819] Lodderstedt, T., McGloin, M., and P. Hunt, "OAuth 2.0
Threat Model and Security Considerations", RFC 6819, Threat Model and Security Considerations", RFC 6819,
January 2013. January 2013.
skipping to change at page 19, line 23 skipping to change at page 20, line 13
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 ]]
-19
o Last call feedback agaiun.
o Clarified usage of TLS in examples and fixed them some more.
Adding reference to RFC4422 and cancellation token and an example
for that.
-18 -18
o Last call feedback round #5. Fixed -17 change log. o Last call feedback round #5. Fixed -17 change log.
o Corrected "issue" to "iss", other minor changes. o Corrected "issue" to "iss", other minor changes.
-17 -17
o Last call feedback again (WGLC #4). eradicated comma splicing. o Last call feedback again (WGLC #4). eradicated comma splicing.
Removed extra server message in example 4.3. Removed extra server message in example 4.3.
 End of changes. 37 change blocks. 
67 lines changed or deleted 117 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/