draft-ietf-kitten-sasl-oauth-02.txt   draft-ietf-kitten-sasl-oauth-03.txt 
KITTEN W. Mills KITTEN W. Mills
Internet-Draft Yahoo! Inc. Internet-Draft Yahoo! Inc.
Intended status: Standards Track T. Showalter Intended status: Standards Track T. Showalter
Expires: February 5, 2013 Expires: February 7, 2013
H. Tschofenig H. Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
August 4, 2012 August 6, 2012
A SASL and GSS-API Mechanism for OAuth A SASL and GSS-API Mechanism for OAuth
draft-ietf-kitten-sasl-oauth-02 draft-ietf-kitten-sasl-oauth-03
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 OAuth over the This document defines how an application client uses OAuth over the
Simple Authentication and Security Layer (SASL) or the Generic Simple Authentication and Security Layer (SASL) or the Generic
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 February 5, 2013. This Internet-Draft will expire on February 7, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 10, line 19 skipping to change at page 10, line 19
For a failed authentication the server returns a JSON [RFC4627] For a failed authentication the server returns a JSON [RFC4627]
formatted error result, and fails the authentication. The error formatted error result, and fails the authentication. The error
result consists of the following values: result consists of the following values:
status (REQUIRED): The authorization error code. Valid error status (REQUIRED): The authorization error code. Valid error
codes are defined in the IANA [[need registry name]] registry codes are defined in the IANA [[need registry name]] registry
specified in the OAuth 2 core specification. specified in the OAuth 2 core specification.
schemes (REQUIRED): A space separated list of the OAuth schemes (REQUIRED): A space separated list of the OAuth
authroization schemes supported by the server, i.e. "bearer" or authorization schemes supported by the server, i.e. "bearer" or
"bearer mac". "bearer mac".
scope (OPTIONAL): The OAuth scope required to access the service. scope (OPTIONAL): The OAuth scope required to access the service.
If the resource server provides a scope the client SHOULD always If the resource server provides a scope the client SHOULD always
request scoped tokens from the token endpoint. The client MAY use a request scoped tokens from the token endpoint. The client MAY use a
scope other than the one provided by the resource server. Scopes scope other than the one provided by the resource server. Scopes
other than those advertised by the resource server are be defined by other than those advertised by the resource server are be defined by
the resource owner and provided in service documentation or discovery the resource owner and provided in service documentation or discovery
information (which is beyond the scope of this memo). If not present information (which is beyond the scope of this memo). If not present
skipping to change at page 11, line 11 skipping to change at page 11, line 11
request which allow the signature base string to be constructed request which allow the signature base string to be constructed
properly. The default HTTP path is "/" and the default post body is properly. The default HTTP path is "/" and the default post body is
empty. These atoms are defined as extension points so that no empty. These atoms are defined as extension points so that no
changes are needed if there is a revision of SASL which supports more changes are needed if there is a revision of SASL which supports more
specific resource authorization, e.g. IMAP access to a specific specific resource authorization, e.g. IMAP access to a specific
folder or FTP access limited to a specific directory. folder or FTP access limited to a specific directory.
Using the example in the MAC specification Using the example in the MAC specification
[I-D.ietf-oauth-v2-http-mac] as a starting point, on an IMAP server [I-D.ietf-oauth-v2-http-mac] as a starting point, on an IMAP server
running on port 143 and given the MAC style authorization request running on port 143 and given the MAC style authorization request
(with %x01 shown as ^A and long lines wrapped for readability) below: (with %x01 shown as ^A and line breaks added for readability) below:
host=server.example.com^A host=server.example.com^A
user=user@example.com^A
port=143^A port=143^A
auth=MAC token="h480djs93hd8",timestamp="137131200",nonce="dj83hs9s", auth=MAC token="h480djs93hd8",timestamp="137131200",nonce="dj83hs9s",
signature="YTVjyNSujYs1WsDurFnvFi4JK6o="^A^A signature="YTVjyNSujYs1WsDurFnvFi4JK6o="^A^A
The normalized request string would be constructed per the MAC The normalized request string would be constructed per the MAC
specification [I-D.ietf-oauth-v2-http-mac]. In this example the specification [I-D.ietf-oauth-v2-http-mac]. In this example the
normalized request string with the new line separator character is normalized request string with the new line separator character is
represented by "\n" for display purposes only would be: represented by "\n" for display purposes only would be:
h480djs93hi8\n h480djs93hi8\n
skipping to change at page 14, line 10 skipping to change at page 14, line 10
Section 4). The exported name token does, of course, conform to Section 4). The exported name token does, of course, conform to
[RFC2743], Section 3.2, but the "NAME" part of the token should be [RFC2743], Section 3.2, but the "NAME" part of the token should be
treated as a potential input string to the OAuth name normalization treated as a potential input string to the OAuth name normalization
rules. rules.
5. Examples 5. Examples
These example illustrate exchanges between an IMAP client and an IMAP These example illustrate exchanges between an IMAP client and an IMAP
server. server.
Note to implementers: Authorization scheme names are case
insensitive. One example uses "Bearer" but that could as easily be
"bearer", "BEARER", or "BeArEr".
5.1. Successful Bearer Token Exchange 5.1. Successful Bearer Token Exchange
This example shows a successful OAuth 2.0 bearer token exchange with This example shows a successful OAuth 2.0 bearer token exchange with
an initial client response. Note that line breaks are inserted for an initial client response. Note that line breaks are inserted for
readability. readability.
S: * IMAP4rev1 Server Ready S: * IMAP4rev1 Server Ready
C: t0 CAPABILITY C: t0 CAPABILITY
S: * CAPABILITY IMAP4rev1 AUTH=OAUTH S: * CAPABILITY IMAP4rev1 AUTH=OAUTH
S: t0 OK Completed S: t0 OK Completed
C: t1 AUTHENTICATE OAUTH aG9zdD1zZXJ2ZXIuZXhhbXBsZS5jb20BcG9ydD0xNDMB C: t1 AUTHENTICATE OAUTH aG9zdD1zZXJ2ZXIuZXhhbXBsZS5jb20BcG9ydD0xNDMB
YXV0aD1CRUFSRVIgdkY5ZGZ0NHFtVGMyTnZiM1JsY2tCaGJIUmhkbWx6ZEdFdVk dXNlcj11c2VyQGV4YW1wbGUuY29tAWF1dGg9QmVhcmVyIHZGOWRmdDRxbVRjMk5
yOXRDZz09AQE= 2YjNSbGNrQmhiSFJoZG1semRHRXVZMjl0Q2c9PQEB
S: + S: +
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:
host=server.example.com^Aport=143^A host=server.example.com^Aport=143^Auser=user@example.com^A
auth=BEARER "vF9dft4qmTc2Nvb3RlckBhbHRhdmlzdGEuY29tCg=="^A^A auth=Bearer vF9dft4qmTc2Nvb3RlckBhbHRhdmlzdGEuY29tCg==^A^A
The line containing just a "+" and a space is an empty response from The line containing just a "+" and a space is an empty response from
the server. This response contains error information, and in the the server. This response contains error information, and in the
success case the error response is empty. Like other messages, and success case the error response is empty. Like other messages, and
in accordance with the IMAP SASL binding, the empty response is in accordance with the IMAP SASL binding, the empty response is
base64-encoded. base64-encoded.
5.2. MAC Authentication with Channel Binding 5.2. MAC Authentication with Channel Binding
This example shows a channel binding failure. The example sends the This example shows a channel binding failure. The example sends the
same request as above, but in the context of an OAUTH-PLUS exchange same request as above, but in the context of an OAUTH-PLUS exchange
the channel binding information is missing. Note that line breaks the channel binding information is missing. Note that line breaks
are inserted for readability. are inserted for readability.
S: * CAPABILITY IMAP4rev1 AUTH=OAUTH SASL-IR IMAP4rev1 Server Ready S: * CAPABILITY IMAP4rev1 AUTH=OAUTH SASL-IR IMAP4rev1 Server Ready
S: t0 OK Completed S: t0 OK Completed
C: t1 AUTHENTICATE MAC aG9zdD1zZXJ2ZXIuZXhhbXBsZS5jb20BcG9ydD0xNDMBYXV0a C: t1 AUTHENTICATE OAUTH-PLUS aG9zdD1zZXJ2ZXIuZXhhbXBsZS5jb20BdXNlcj11c2
D1NQUMgdG9rZW49Img0ODBkanM5M2hkOCIsdGltZXN0YW1wPSIxMzcxMzEyMDAiLG5vbm VyQGV4YW1wbGUuY29tAXBvcnQ9MTQzAWF1dGg9TUFDIHRva2VuPSJoNDgwZGpzOTNo
NlPSJkajgzaHM5cyIsc2lnbmF0dXJlPSJZVFZqeU5TdWpZczFXc0R1ckZudkZpNEpLNm8 ZDgiLHRpbWVzdGFtcD0iMTM3MTMxMjAwIixub25jZT0iZGo4M2hzOXMiLHNpZ25hdH
9IgFjYmRhdGE9U0c5M0lHSnBaeUJwY3lCaElGUk1VeUJtYVc1aGJDQnRaWE56WVdkbFB3 VyZT0iWVRWanlOU3VqWXMxV3NEdXJGbnZGaTRKSzZvPSIBY2JkYXRhPVNHOTNJR0pw
bz0BAQ== WnlCcGN5QmhJRlJNVXlCbWFXNWhiQ0J0WlhOellXZGxQd289AQE=
S: + S: +
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:
- -
host=server.example.com^A host=server.example.com^A
user=user@example.com^A
port=143^A port=143^A
auth=MAC token="h480djs93hd8",timestamp="137131200",nonce="dj83hs9s", auth=MAC token="h480djs93hd8",timestamp="137131200",nonce="dj83hs9s",
signature="YTVjyNSujYs1WsDurFnvFi4JK6o="^A signature="YTVjyNSujYs1WsDurFnvFi4JK6o="^A
cbdata=SG93IGJpZyBpcyBhIFRMUyBmaW5hbCBtZXNzYWdlPwo=^A^A cbdata=SG93IGJpZyBpcyBhIFRMUyBmaW5hbCBtZXNzYWdlPwo=^A^A
The line containing just a "+" and a space is an empty response from The line containing just a "+" and a space is an empty response from
the server. This response contains discovery information, and in the the server. This response contains discovery information, and in the
success case no discovery information is necessary so the response is success case no discovery information is necessary so the response is
empty. Like other messages, and in accordance with the IMAP SASL empty. Like other messages, and in accordance with the IMAP SASL
binding, the empty response is base64-encoded. binding, the empty response is base64-encoded.
5.3. Failed Exchange 5.3. Failed Exchange
This example shows a failed exchange because of the empty This 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: * CAPABILITY IMAP4rev1 AUTH=OAUTH SASL-IR IMAP4rev1 Server Ready S: * CAPABILITY IMAP4rev1 AUTH=OAUTH SASL-IR IMAP4rev1 Server Ready
S: t0 OK Completed S: t0 OK Completed
C: t1 AUTHENTICATE OAUTH aG9zdD1zZXJ2ZXIuZXhhbXBsZS5jb20BcG9ydD0xND C: t1 AUTHENTICATE OAUTH aG9zdD1zZXJ2ZXIuZXhhbXBsZS5jb20BdXNlcj11
MBYXV0aD0BAQ== c2VyQGV4YW1wbGUuY29tAXBvcnQ9MTQzAWF1dGg9AQE=
S: + ewoic3RhdHVzIjoiNDAxIiwKInNjb3BlIjoiZXhhbXBsZV9zY29wZSIKfQo= S: + eyJzdGF0dXMiOiI0MDEiLCJzY2hlbWVzIjoiYmVhcmVyIG1hYyIsInNjb3Bl
IjoiZXhhbXBsZV9zY29wZSJ9
S: t1 NO SASL authentication failed S: t1 NO SASL authentication failed
The decoded initial client response is: The decoded initial client response is:
host=server.example.com^Aport=143^Aauth=^A^A host=server.example.com^Auser=user@example.com^Aport=143^Aauth=^A^A
The decoded server error response is: The decoded server error response is:
{ {
"status":"401", "status":"401",
"schemes":"bearer mac",
"scope":"example_scope" "scope":"example_scope"
} }
5.4. Failed Channel Binding 5.4. Failed Channel Binding
This example shows a channel binding failure in an empty request. This example shows a channel binding failure in an empty request.
The channel binding information is empty. Note that line breaks are The channel binding information is empty. Note that line breaks are
inserted for readability. inserted for readability.
S: * CAPABILITY IMAP4rev1 AUTH=OAUTH SASL-IR IMAP4rev1 Server Ready S: * CAPABILITY IMAP4rev1 AUTH=OAUTH SASL-IR IMAP4rev1 Server Ready
S: t0 OK Completed S: t0 OK Completed
C: t1 AUTHENTICATE OAUTH aG9zdD1zZXJ2ZXIuZXhhbXBsZS5jb20BcG9ydD0xND C: t1 AUTHENTICATE OAUTH aG9zdD1zZXJ2ZXIuZXhhbXBsZS5jb20BdXNlcj11
MBYXV0aD0BY2JkYXRhPQEB c2VyQGV4YW1wbGUuY29tAXBvcnQ9MTQzAWF1dGg9AWNiZGF0YT0BAQ==
S: + ewoic3RhdHVzIjoiNDEyIiwKInNjb3BlIjoiZXhhbXBsZV9zY29wZSIKfQ== S: + eyJzdGF0dXMiOiI0MTIiLCJzY2hlbWVzIjoiYmVhcmVyIG1hYyIsInNjb3Bl
IjoiZXhhbXBsZV9zY29wZSJ9
S: t1 NO SASL authentication failed S: t1 NO SASL authentication failed
The decoded initial client response is: The decoded initial client response is:
host=server.example.com^Aport=143^Aauth=^Acbdata=^A^A host=server.example.com^Auser=user@example.com^Aport=143^A
auth=^Acbdata=^A^A
The decoded server response is: The decoded server response is:
{ {
"status":"412", "status":"412",
"schemes":"bearer mac",
"scope":"example_scope" "scope":"example_scope"
} }
6. Security Considerations 6. Security Considerations
This mechanism does not provide a security layer, but does provide a This mechanism does not provide a security layer, but does provide a
provision for channel binding. The OAuth 2 specification provision for channel binding. The OAuth 2 specification
[I-D.ietf-oauth-v2] allows for a variety of usages, and the security [I-D.ietf-oauth-v2] allows for a variety of usages, and the security
properties of these profiles vary. The usage of bearer tokens, for properties of these profiles vary. The usage of bearer tokens, for
example, provide security features similar to cookies. Applications example, provide security features similar to cookies. Applications
skipping to change at page 21, line 9 skipping to change at page 21, line 9
draft-jones-appsawg-webfinger-06 (work in progress), draft-jones-appsawg-webfinger-06 (work in progress),
June 2012. June 2012.
[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.
Appendix A. Document History Appendix A. Document History
[[ to be removed by RFC editor before publication as an RFC ]] [[ to be removed by RFC editor before publication as an RFC ]]
-03
o Added user field into examples and fixed egregious errors there as
well.
o Added text reminding developers that Authorization scheme names
are case insensitive.
-02 -02
o Added the user data element back in. o Added the user data element back in.
o Minor editorial changes. o Minor editorial changes.
-01 -01
o Ripping out discovery. Changed to refer to I-D.jones-appsawg- o Ripping out discovery. Changed to refer to I-D.jones-appsawg-
webfinger instead of WF and SWD older drafts. webfinger instead of WF and SWD older drafts.
 End of changes. 19 change blocks. 
24 lines changed or deleted 42 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/