draft-ietf-kitten-sasl-oauth-07.txt   draft-ietf-kitten-sasl-oauth-08.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: March 17, 2013 Expires: March 21, 2013
H. Tschofenig H. Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
September 13, 2012 September 17, 2012
A set of SASL and GSS-API Mechanisms for OAuth A set of SASL and GSS-API Mechanisms for OAuth
draft-ietf-kitten-sasl-oauth-07 draft-ietf-kitten-sasl-oauth-08
Abstract Abstract
OAuth enables a third-party application to obtain limited access to a OAuth enables a third-party application to obtain limited access to a
protected resource, either on behalf of a resource owner by protected resource, either on behalf of a resource owner by
orchestrating an approval interaction, or by allowing the third-party orchestrating an approval interaction, or by allowing the third-party
application to obtain access on its own behalf. application to obtain access on its own behalf.
This document defines how an application client uses credentials This document defines how an application client uses credentials
obtained via OAuth over the Simple Authentication and Security Layer obtained via OAuth over the Simple Authentication and Security Layer
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 17, 2013. This Internet-Draft will expire on March 21, 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 3, line 14 skipping to change at page 3, line 14
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. OAuth SASL Mechanism Specifications . . . . . . . . . . . . . 8 3. OAuth SASL Mechanism Specifications . . . . . . . . . . . . . 8
3.1. Initial Client Response . . . . . . . . . . . . . . . . . 9 3.1. Initial Client Response . . . . . . . . . . . . . . . . . 9
3.1.1. Reserved Key/Values . . . . . . . . . . . . . . . . . 10 3.1.1. Reserved Key/Values . . . . . . . . . . . . . . . . . 10
3.1.2. Use of the gs2-header . . . . . . . . . . . . . . . . 10 3.1.2. Use of the gs2-header . . . . . . . . . . . . . . . . 10
3.2. Server's Response . . . . . . . . . . . . . . . . . . . . 10 3.2. Server's Response . . . . . . . . . . . . . . . . . . . . 10
3.2.1. Mapping to SASL Identities . . . . . . . . . . . . . . 11 3.2.1. OAuth Identities in the SASL Context . . . . . . . . . 11
3.2.2. Canonicalization . . . . . . . . . . . . . . . . . . . 11 3.2.2. Canonicalization . . . . . . . . . . . . . . . . . . . 11
3.2.3. Server response to failed authentication. . . . . . . 11 3.2.3. Server response to failed authentication. . . . . . . 11
3.2.4. Completing an error message sequence. . . . . . . . . 12 3.2.4. Completing an error message sequence. . . . . . . . . 12
3.3. Use of Signature Type Authorization . . . . . . . . . . . 12 3.3. Use of Signature Type Authorization . . . . . . . . . . . 12
3.4. Channel Binding . . . . . . . . . . . . . . . . . . . . . 13 3.4. Channel Binding . . . . . . . . . . . . . . . . . . . . . 13
4. GSS-API OAuth Mechanism Specification . . . . . . . . . . . . 15 4. GSS-API OAuth Mechanism Specification . . . . . . . . . . . . 15
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.1. Successful Bearer Token Exchange . . . . . . . . . . . . . 17 5.1. Successful Bearer Token Exchange . . . . . . . . . . . . . 17
5.2. OAuth 1.0a Authorization with Channel Binding . . . . . . 18 5.2. OAuth 1.0a Authorization with Channel Binding . . . . . . 18
5.3. Failed Exchange . . . . . . . . . . . . . . . . . . . . . 19 5.3. Failed Exchange . . . . . . . . . . . . . . . . . . . . . 19
skipping to change at page 11, line 9 skipping to change at page 11, line 9
In a "-PLUS" mechanism the server examines the channel binding data, In a "-PLUS" mechanism the server examines the channel binding data,
extracts the channel binding unique prefix, and extracts the raw extracts the channel binding unique prefix, and extracts the raw
channel biding data based on the channel binding type used. It then channel biding data based on the channel binding type used. It then
computes it's own copy of the channel binding payload and compares computes it's own copy of the channel binding payload and compares
that to the payload sent by the client in the cbdata key/value. that to the payload sent by the client in the cbdata key/value.
Those two must be equal for channel binding to succeed. Those two must be equal for channel binding to succeed.
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 mechanism is the identity which the mechanism has securely by the SASL mechanism is the identity securely established for the
established for the client with the OAuth credential. client with the OAuth credential. The application, not the SASL
mechanism, based on local access policy determines whether the
3.2.1. Mapping to SASL Identities identity reported by the mechanism is allowed access to the requested
resource. Note that the semantics of the authz-id is specified by
the SASL framework [RFC4422].
Note that the semantics of the authz-id are specified by the SASL 3.2.1. OAuth Identities in the SASL Context
framework [RFC4422]. A SASL application is, of course, free to apply
mappings of the OAuth authcid to authz-ids as per-SASL, and it is
free to apply mappings common to non-SASL OAuth applications.
Some OAuth schemes can carry both a user identity and a "proxy" Some OAuth schemes can carry both an owner or resource identity and a
identity, for example an OAuth 1.0a [RFC5849] mechanism where the "proxy" identity, for example an OAuth 1.0a [RFC5849] mechanism where
consumer key (oauth_consumer_key) identifies the entity using the the consumer key (oauth_consumer_key) identifies the entity using the
token and the token itself identifies the user. If both identities token and the token itself identifies the owner or resouce. If both
are needed by an application the developer will need to provide a way identities are needed by an application the developer will need to
to communicate that from the SASL mechanism back to the application provide a way to communicate that from the SASL mechanism back to the
such as a GS2 [RFC2473] named type like GSS_C_NT_USER_NAME or a application such as a GSS-API [RFC2473] named type like
comparable newly defined GS2 attribute. GSS_C_NT_USER_NAME or a comparable newly defined GSS-API name type or
name attribute [RFC6680].
3.2.2. Canonicalization 3.2.2. Canonicalization
The identity asserted by the OAuth authorization server is canonical The identity asserted by the OAuth authorization server is canonical
for display. The server MAY provide a different canonical form based for display. The server MAY provide a different canonical form based
on local data. on local data.
3.2.3. Server response to failed authentication. 3.2.3. Server response to failed authentication.
For a failed authentication the server returns a JSON [RFC4627] For a failed authentication the server returns a JSON [RFC4627]
skipping to change at page 18, line 29 skipping to change at page 18, line 29
5.2. OAuth 1.0a Authorization with Channel Binding 5.2. OAuth 1.0a Authorization with Channel Binding
This example shows channel binding in the context of an OAuth 1.0a This example shows channel binding in the context of an OAuth 1.0a
signed authorization request. Note that line breaks are inserted for signed authorization request. Note that line breaks are inserted for
readability. readability.
S: * CAPABILITY IMAP4rev1 AUTH=OAUTH10A-PLUS SASL-IR IMAP4rev1 Server S: * CAPABILITY IMAP4rev1 AUTH=OAUTH10A-PLUS SASL-IR IMAP4rev1 Server
Ready Ready
S: t0 OK Completed S: t0 OK Completed
C: t1 AUTHENTICATE OAUTH10A-PLUS cCxhPXVzZXJAZXhhbXBsZS5jb20BaG9zdD1zZ C: t1 AUTHENTICATE OAUTH10A-PLUS cD10bHMtdW5pcXVlLGE9dXNlckBleGFtcGxlL
XJ2ZXIuZXhhbXBsZS5jb20BcG9ydD0xNDMBYXV0aD1PQXV0aCByZWFsbT0iRXhhb mNvbQFob3N0PXNlcnZlci5leGFtcGxlLmNvbQFwb3J0PTE0MwFhdXRoPU9BdXRoI
XBsZSIsb2F1dGhfY29uc3VtZXJfa2V5PSI5ZGpkajgyaDQ4ZGpzOWQyIixvYXV0a HJlYWxtPSJFeGFtcGxlIixvYXV0aF9jb25zdW1lcl9rZXk9IjlkamRqODJoNDhka
F90b2tlbj0ia2trOWQ3ZGgzazM5c2p2NyIsb2F1dGhfc2lnbmF0dXJlX21ldGhvZ nM5ZDIiLG9hdXRoX3Rva2VuPSJra2s5ZDdkaDNrMzlzanY3IixvYXV0aF9zaWduY
D0iSE1BQy1TSEExIixvYXV0aF90aW1lc3RhbXA9IjEzNzEzMTIwMSIsb2F1dGhfb XR1cmVfbWV0aG9kPSJITUFDLVNIQTEiLG9hdXRoX3RpbWVzdGFtcD0iMTM3MTMxM
m9uY2U9IjdkOGYzZTRhIixvYXV0aF9zaWduYXR1cmU9IlNTZHRJR0VnYkdsMGRHe jAxIixvYXV0aF9ub25jZT0iN2Q4ZjNlNGEiLG9hdXRoX3NpZ25hdHVyZT0iU1Nkd
GxJSFJsWVNCd2IzUXUiAXFzPWNiZGF0YT10bHMtdW5pcXVlOlNHOTNJR0pwWnlCc ElHRWdiR2wwZEd4bElIUmxZU0J3YjNRdSIBcXM9Y2JkYXRhPXRscy11bmlxdWU6U
GN5QmhJRlJNVXlCbWFXNWhiQ0J0WlhOellXZGxQd289AQE= 0c5M0lHSnBaeUJwY3lCaElGUk1VeUJtYVc1aGJDQnRaWE56WVdkbFB3bz0BAQ==
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
lines wrapped for readability) is: lines wrapped for readability) is:
p,a=user@example.com^A p=tls-unique,a=user@example.com^A
host=server.example.com^A host=server.example.com^A
port=143^A port=143^A
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 oauth_signature="SSdtIGEgbGl0dGxlIHRlYSBwb3Qu"^A
qs=cbdata=tls-unique:SG93IGJpZyBpcyBhIFRMUyBmaW5hbCBtZXNzYWdlPwo=^A^A qs=cbdata=tls-unique:SG93IGJpZyBpcyBhIFRMUyBmaW5hbCBtZXNzYWdlPwo=^A^A
skipping to change at page 19, line 35 skipping to change at page 19, line 35
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=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 bixhPXVzZXJAZXhhbXBsZS5jb20BaG9zdD C: t1 AUTHENTICATE OAUTHBEARER cD10bHMtdW5pcXVlLGE9dXNlckBleGFtcG
1zZXJ2ZXIuZXhhbXBsZS5jb20BcG9ydD0xNDMBYXV0aD0BAQ== xlLmNvbQFob3N0PXNlcnZlci5leGFtcGxlLmNvbQFwb3J0PTE0MwFhdXRoP
QFjYmRhdGE9AQE=
S: + ewoic3RhdHVzIjoiNDAxIgoic2NvcGUiOiJleGFtcGxlX3Njb3BlIgp9 S: + ewoic3RhdHVzIjoiNDAxIgoic2NvcGUiOiJleGFtcGxlX3Njb3BlIgp9
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:
skipping to change at page 20, line 29 skipping to change at page 20, line 29
Ready Ready
S: t0 OK Completed S: t0 OK Completed
C: t1 AUTHENTICATE OAUTH10A-PLUS cCxhPXVzZXJAZXhhbXBsZS5jb20BaG9z C: t1 AUTHENTICATE OAUTH10A-PLUS cCxhPXVzZXJAZXhhbXBsZS5jb20BaG9z
dD1zZXJ2ZXIuZXhhbXBsZS5jb20BcG9ydD0xNDMBYXV0aD0BY2JkYXRhPQEB dD1zZXJ2ZXIuZXhhbXBsZS5jb20BcG9ydD0xNDMBYXV0aD0BY2JkYXRhPQEB
S: + ewoic3RhdHVzIjoiNDEyIiwKInNjb3BlIjoiZXhhbXBsZV9zY29wZSIKfQ== S: + ewoic3RhdHVzIjoiNDEyIiwKInNjb3BlIjoiZXhhbXBsZV9zY29wZSIKfQ==
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:
p,a=user@example.com,^Ahost=server.example.com^A p=tls-unique,a=user@example.com,^Ahost=server.example.com^A
port=143^Aauth=^Acbdata=^A^A port=143^Aauth=^Acbdata=^A^A
The decoded server response is: The decoded server response is:
{ {
"status":"412", "status":"412",
"scope":"example_scope" "scope":"example_scope"
} }
The client responds with the required dummy response. The client responds with the required dummy response.
skipping to change at page 26, line 28 skipping to change at page 26, line 28
for TLS", RFC 5929, July 2010. for TLS", RFC 5929, July 2010.
[RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010. [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509 within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer (PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, March 2011. Security (TLS)", RFC 6125, March 2011.
[RFC6680] Williams, N., Johansson, L., Hartman, S., and S.
Josefsson, "Generic Security Service Application
Programming Interface (GSS-API) Naming Extensions",
RFC 6680, August 2012.
8.2. Informative References 8.2. Informative References
[I-D.ietf-oauth-v2-http-mac] [I-D.ietf-oauth-v2-http-mac]
Hammer-Lahav, E., "HTTP Authentication: MAC Access Hammer-Lahav, E., "HTTP Authentication: MAC Access
Authentication", draft-ietf-oauth-v2-http-mac-01 (work in Authentication", draft-ietf-oauth-v2-http-mac-01 (work in
progress), February 2012. progress), February 2012.
[I-D.jones-appsawg-webfinger] [I-D.jones-appsawg-webfinger]
Jones, P., Salgueiro, G., and J. Smarr, "WebFinger", Jones, P., Salgueiro, G., and J. Smarr, "WebFinger",
draft-jones-appsawg-webfinger-06 (work in progress), draft-jones-appsawg-webfinger-06 (work in progress),
skipping to change at page 28, line 9 skipping to change at page 28, line 9
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, and Nico Williams. Lodderstadt, Ryan Troll, and Nico Williams.
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 ]]
-08
o Fixed the channel binding examples for p=$cbtype
o More tuning of the authcid language and edited and renamed 3.2.1.
-07 -07
o Struck the MUST langiage from authzid. o Struck the MUST langiage from authzid.
o o
-06 -06
o Removed the user field. Fixed the examples again. o Removed the user field. Fixed the examples again.
 End of changes. 14 change blocks. 
33 lines changed or deleted 45 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/