draft-ietf-kitten-sasl-oauth-15.txt   draft-ietf-kitten-sasl-oauth-16.txt 
KITTEN W. Mills KITTEN W. Mills
Internet-Draft Skype Internet-Draft Microsoft
Intended status: Standards Track T. Showalter Intended status: Standards Track T. Showalter
Expires: January 23, 2015 Expires: March 20, 2015
H. Tschofenig H. Tschofenig
ARM Ltd. ARM Ltd.
July 22, 2014 September 16, 2014
A set of SASL Mechanisms for OAuth A set of SASL Mechanisms for OAuth
draft-ietf-kitten-sasl-oauth-15.txt draft-ietf-kitten-sasl-oauth-16.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 January 23, 2015. This Internet-Draft will expire on March 20, 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 32 skipping to change at page 2, line 32
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 . . . . . . . . 9
3.3. OAuth Access Token Types using Keyed Message Digests . . 9 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 . . . . . . . . . . 13 4.4. SMTP Example of a Failed Negotiation . . . . . . . . . . 14
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6. Internationalization Considerations . . . . . . . . . . . . . 15 6. Internationalization Considerations . . . . . . . . . . . . . 16
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
7.1. SASL Registration . . . . . . . . . . . . . . . . . . . . 16 7.1. SASL Registration . . . . . . . . . . . . . . . . . . . . 16
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.1. Normative References . . . . . . . . . . . . . . . . . . 16 8.1. Normative References . . . . . . . . . . . . . . . . . . 17
8.2. Informative References . . . . . . . . . . . . . . . . . 17 8.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. Acknowlegements . . . . . . . . . . . . . . . . . . 18 Appendix A. Acknowlegements . . . . . . . . . . . . . . . . . . 18
Appendix B. Document History . . . . . . . . . . . . . . . . . . 18 Appendix B. Document History . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
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
skipping to change at page 3, line 36 skipping to change at page 3, line 36
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],
which is what this memo uses in the examples. which is what this memo uses in the examples.
To illustrate the impact of integrating this specification into an To illustrate the impact of integrating this specification into an
OAuth-enabled application environment Figure 1 shows the abstract OAuth-enabled application environment, Figure 1 shows the abstract
message flow of OAuth 2.0 [RFC6749]. As indicated in the figure, message flow of OAuth 2.0 [RFC6749]. As indicated in the figure,
this document impacts the exchange of messages (E) and (F) since SASL this document impacts the exchange of messages (E) and (F) since SASL
is used for interaction between the client and the resource server is used for interaction between the client and the resource server
instead of HTTP. instead of HTTP.
----+ ----+
+--------+ +---------------+ | +--------+ +---------------+ |
| |--(A)-- Authorization Request --->| Resource | | | |--(A)-- Authorization Request --->| Resource | |
| | | Owner | |Plain | | | Owner | |Plain
| |<-(B)------ Access Grant ---------| | |OAuth | |<-(B)------ Access Grant ---------| | |OAuth
skipping to change at page 4, line 37 skipping to change at page 4, line 37
Figure 1: OAuth 2.0 Protocol Flow Figure 1: OAuth 2.0 Protocol Flow
The Simple Authentication and Security Layer (SASL) is a framework The Simple Authentication and Security Layer (SASL) is a framework
for providing authentication and data security services in for providing authentication and data security services in
connection-oriented protocols via replaceable authentication connection-oriented protocols via replaceable authentication
mechanisms. It provides a structured interface between protocols and mechanisms. It provides a structured interface between protocols and
mechanisms. The resulting framework allows new protocols to reuse mechanisms. The resulting framework allows new protocols to reuse
existing authentication protocols and allows old protocols to make existing authentication protocols and allows old protocols to make
use of new authentication mechanisms. The framework also provides a use of new authentication mechanisms. The framework also provides a
protocol for securing subsequent protocol exchanges within a data protocol for securing subsequent exchanges within a data security
security layer. layer.
When OAuth is integrated into SASL the high-level steps are as When OAuth is integrated into SASL the high-level steps are as
follows: follows:
(A) The client requests authorization from the resource owner. (A) The client requests authorization from the resource owner.
The authorization request can be made directly to the resource The authorization request can be made directly to the resource
owner (as shown), or preferably indirectly via the authorization owner (as shown), or preferably indirectly via the authorization
server as an intermediary. server as an intermediary.
(B) The client receives an authorization grant which is a (B) The client receives an authorization grant which is a
skipping to change at page 5, line 30 skipping to change at page 5, line 30
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 and
authorization server endpoints is outside the scope of this authorization server endpoints is outside the scope of this
specification. The client must discover those endpoints using a specification. The client must discover those endpoints using a
discovery mechanisms, such as Webfinger using host-meta [RFC7033]. discovery mechanism, such as Webfinger using host-meta [RFC7033]. In
In band discovery is not tenable if clients support the OAuth 2.0 band discovery is not tenable if clients support the OAuth 2.0
password grant. Once credentials are obtained the client proceeds to password grant. Once credentials are obtained the client proceeds to
steps (E) and (F) defined in this specification. steps (E) and (F) defined in this specification.
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",
skipping to change at page 7, line 7 skipping to change at page 7, line 7
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.
3.1. Initial Client Response 3.1. Initial Client Response
Client responses are a GS2 [RFC5801] header followed by a key/value Client responses are a GS2 [RFC5801] header followed by zero or more
pair sequence, 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 carry the this document does not define one. These key/value pairs take the
equivalent values from an HTTP context in order to be able to place of the corresponding HTTP headers and values to convey the
complete an OAuth style HTTP authorization. Unknown key/value pairs information necessary to complete an OAuth style HTTP authorization.
MUST be ignored by the server. The ABNF [RFC5234] syntax is: Unknown key/value pairs MUST be ignored by the server. The ABNF
[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 following key/value pairs are defined in the client response: The following keys and corresponding values are defined in the client
response:
auth (REQUIRED): The payload of the HTTP Authorization header for auth (REQUIRED): The payload that would be in the HTTP
an equivalent HTTP OAuth authorization. Authorization header if this OAuth exchange was being carried
out over HTTP.
host: Contains the host name to which the client connected. 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 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.
qs: The HTTP query string. This is reserved for future use, the For OAuth token types such as OAuth 1.0a that use keyed message
client SHOUD NOT send it, and has the default value of "". digests the client MUST send host and port number key/values, and the
server MUST fail an authorization request requiring keyed message
For OAuth token types that use keyed message digests the client MUST digests that are not accompanied by host and port values. In OAuth
send host and port number key/values, and the server MUST fail an 1.0a for example, the so-called "signature base string calculation"
authorization request requiring keyed message digests that do not includes the reconstructed HTTP URL.
have host and port values. In OAuth 1.0a for example, the so-called
"signature base string calculation" 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 use request keyed message digest
the default values MUST be used unless explicit values are provided the default values MUST be used unless explicit values are provided
in the client response. The following key values are reserved for in the client response. The following key values are reserved for
future use: 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 "".
3.2. Server's Response 3.2. Server's Response
The server validates the response per the specification for the OAuth The server validates the response according the specification for the
Access Token Types used. If the OAuth Access Token Type utilizes a OAuth Access Token Types used. If the OAuth Access Token Type
keyed message digest of the request parameters then the client must utilizes a keyed message digest of the request parameters then the
provide a client response that satisfies the data requirements for client must provide a client response that satisfies the data
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 authz-id is specified by
the SASL framework [RFC4422]. the SASL framework [RFC4422].
skipping to change at page 9, line 33 skipping to change at page 9, line 37
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.
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 needed. an empty scope (unscoped token) is required to access the resource.
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 11, line 7 skipping to change at page 11, line 11
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 an IMAP and SMTP clients These examples illustrate exchanges between IMAP and SMTP clients and
and servers. servers.
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. This example shows a successful OAuth 2.0 bearer token exchange in
Note that line breaks are inserted for readability and the underlying IMAP. Note that line breaks are inserted for readability and the
TLS establishment is not shown either. underlying TLS establishment is not shown either.
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 AUTHENTICATE OAUTHBEARER bixhPXVzZXJAZXhhbXBsZS5jb20sAWhvc3Q9c2
VydmVyLmV4YW1wbGUuY29tAXBvcnQ9MTQzAWF1dGg9QmVhcmVyIHZGOWRmdDRxb VydmVyLmV4YW1wbGUuY29tAXBvcnQ9MTQzAWF1dGg9QmVhcmVyIHZGOWRmdDRxb
VRjMk52YjNSbGNrQmhiSFJoZG1semRHRXVZMjl0Q2c9PQEB VRjMk52YjNSbGNrQmhiSFJoZG1semRHRXVZMjl0Q2c9PQEB
S: t1 OK SASL authentication succeeded S: t1 OK SASL authentication succeeded
skipping to change at page 12, line 22 skipping to change at page 12, line 22
S: 250-ENHANCEDSTATUSCODES S: 250-ENHANCEDSTATUSCODES
S: 250 PIPELINING S: 250 PIPELINING
C: t1 AUTHENTICATE OAUTHBEARER bixhPXVzZXJAZXhhbXBsZS5jb20sAWhvc3Q9c C: t1 AUTHENTICATE 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 example shows a successful OAuth 1.0a token exchange. Note that This IMAP example shows a successful OAuth 1.0a token exchange. Note
line breaks are inserted for readability and the underlying TLS that line breaks are inserted for readability and the underlying TLS
establishment is not shown. Signature computation is discussed in establishment is not shown. Signature computation is discussed in
Section 3.3. 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 AUTHENTICATE OAUTH10A bixhPXVzZXJAZXhhbXBsZS5jb20sAWhvc3Q9ZXhhb
XBsZS5jb20BcG9ydD0xNDMBYXV0aD1PQXV0aCByZWFsbT0iRXhhbXBsZSIsb2F1 XBsZS5jb20BcG9ydD0xNDMBYXV0aD1PQXV0aCByZWFsbT0iRXhhbXBsZSIsb2F1
dGhfY29uc3VtZXJfa2V5PSI5ZGpkajgyaDQ4ZGpzOWQyIixvYXV0aF90b2tlbj0 dGhfY29uc3VtZXJfa2V5PSI5ZGpkajgyaDQ4ZGpzOWQyIixvYXV0aF90b2tlbj0
skipping to change at page 13, line 18 skipping to change at page 13, line 18
auth=OAuth realm="Example", auth=OAuth realm="Example",
oauth_consumer_key="9djdj82h48djs9d2", oauth_consumer_key="9djdj82h48djs9d2",
oauth_token="kkk9d7dh3k39sjv7", oauth_token="kkk9d7dh3k39sjv7",
oauth_signature_method="HMAC-SHA1", oauth_signature_method="HMAC-SHA1",
oauth_timestamp="137131201", oauth_timestamp="137131201",
oauth_nonce="7d8f3e4a", oauth_nonce="7d8f3e4a",
oauth_signature="SSdtIGEgbGl0dGxlIHRlYSBwb3Qu"^A^A oauth_signature="SSdtIGEgbGl0dGxlIHRlYSBwb3Qu"^A^A
4.3. Failed Exchange 4.3. Failed Exchange
This 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
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
X3Njb3BlIiwib3BlbmlkLWNvbmZpZ3VyYXRpb24iOiJodHRwczovL2V4
YW1wbGUuY29tLy53ZWxsLWtub3duL29wZW5pZC1jb25maWd1cmF0aW9u
In0=
S: + eyJzdGF0dXMiOiI0MDEiLCJzY29wZSI6ImV4YW1wbGVfc2NvcGUiLCJv S: + eyJzdGF0dXMiOiI0MDEiLCJzY29wZSI6ImV4YW1wbGVfc2NvcGUiLCJv
cGVuaWQtY29uZmlndXJhdGlvbiI6Imh0dHBzOi8vZXhhbXBsZS5jb20v cGVuaWQtY29uZmlndXJhdGlvbiI6Imh0dHBzOi8vZXhhbXBsZS5jb20v
LndlbGwta25vd24vb3BlbmlkLWNvbmZpZ3VyYXRpb24ifQ== 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":"401", "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. base64 encoding of the ASCII value 0x01.
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.
[connection begins] [connection begins]
S: 220 mx.example.com ESMTP 12sm2095603fks.9 S: 220 mx.example.com ESMTP 12sm2095603fks.9
skipping to change at page 15, line 39 skipping to change at page 15, line 46
application protocols where connections are long-lived, and not a application protocols where connections are long-lived, and not a
problem with this mechanism per se. Resource servers may problem with this mechanism per se. Resource servers may
unilaterally disconnect clients in accordance with the application unilaterally disconnect clients in accordance with the application
protocol. protocol.
Access tokens have a lifetime. Access tokens have a lifetime.
Reducing the lifetime of an access token provides security Reducing the lifetime of an access token provides security
benefits and OAuth 2.0 introduces refresh tokens to obtain new benefits and OAuth 2.0 introduces refresh tokens to obtain new
access token on the fly without any need for a human interaction. access token on the fly without any need for a human interaction.
Additionally, a previously obtained access token may be revoked or Additionally, a previously obtained access token might be revoked
rendered invalid at any time. The client may request a new access or rendered invalid at any time. The client MAY request a new
token for each connection to a resource server, but it SHOULD access token for each connection to a resource server, but it
cache and re-use valid credentials. SHOULD cache and re-use valid credentials.
6. Internationalization Considerations 6. Internationalization Considerations
The identifer asserted by the OAuth authorization server about the The identifer asserted by the OAuth authorization server about the
resource owner inside the access token may be displayed to a human. resource owner inside the access token may be displayed to a human.
For example, when SASL is used in the context of IMAP the resource For example, when SASL is used in the context of IMAP the client may
server may assert the resource owner's email address to the IMAP assert the resource owner's email address to the IMAP server for
server for usage in an email-based application. The identifier may usage in an email-based application. The identifier may therefore
therefore contain internationalized characters and an application contain internationalized characters and an application needs to
needs to ensure that the mapping between the identifier provided by ensure that the mapping between the identifier provided by OAuth is
OAuth is suitable for use with the application layer protocol SASL is suitable for use with the application layer protocol SASL is
incorporated into. incorporated into.
At the time of writing the standardization of the various claims in At the time of writing the standardization of the various claims in
the access token (in JSON format) is still ongoing, see the access token (in JSON format) is still ongoing, see
[I-D.ietf-oauth-json-web-token]. Once completed it will provide a [I-D.ietf-oauth-json-web-token]. Once completed it will provide a
standardized format for exchanging identity information between the standardized format for exchanging identity information between the
authorization server and the resource server. authorization server and the resource server.
7. IANA Considerations 7. IANA Considerations
skipping to change at page 18, line 30 skipping to change at page 18, line 42
January 2013. January 2013.
[RFC7033] Jones, P., Salgueiro, G., Jones, M., and J. Smarr, [RFC7033] Jones, P., Salgueiro, G., Jones, M., and J. Smarr,
"WebFinger", RFC 7033, September 2013. "WebFinger", RFC 7033, September 2013.
Appendix A. Acknowlegements Appendix A. Acknowlegements
The authors would like to thank the members of the Kitten working The authors would like to thank the members of the Kitten working
group, and in addition and specifically: Simon Josefson, Torsten group, and in addition and specifically: Simon Josefson, Torsten
Lodderstadt, Ryan Troll, Alexey Melnikov, Jeffrey Hutzelman, Nico Lodderstadt, Ryan Troll, Alexey Melnikov, Jeffrey Hutzelman, Nico
Williams, and Matt Miller. 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 ]]
-16
o Last call feedback again. Primarily editorial changes. Corrected
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
-10. -10.
o Added an OAuth 1.0A example explicitly. o Added an OAuth 1.0A example explicitly.
skipping to change at page 21, line 28 skipping to change at page 21, line 45
-00 -00
o Renamed draft into proper IETF naming format now that it's o Renamed draft into proper IETF naming format now that it's
adopted. adopted.
o Minor fixes. o Minor fixes.
Authors' Addresses Authors' Addresses
William Mills William Mills
Skype Microsoft
Email: wmills_92105@yahoo.com Email: wimills@microsoft.com
Tim Showalter Tim Showalter
Email: tjs@psaux.com Email: tjs@psaux.com
Hannes Tschofenig Hannes Tschofenig
ARM Ltd. ARM Ltd.
110 Fulbourn Rd 110 Fulbourn Rd
Cambridge CB1 9NJ Cambridge CB1 9NJ
Great Britain Great Britain
Email: Hannes.tschofenig@gmx.net Email: Hannes.tschofenig@gmx.net
URI: http://www.tschofenig.priv.at URI: http://www.tschofenig.priv.at
 End of changes. 36 change blocks. 
66 lines changed or deleted 78 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/