draft-ietf-kitten-sasl-oauth-21.txt   draft-ietf-kitten-sasl-oauth-22.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: October 19, 2015 Expires: November 1, 2015
H. Tschofenig H. Tschofenig
ARM Ltd. ARM Ltd.
April 17, 2015 April 30, 2015
A set of SASL Mechanisms for OAuth A set of SASL Mechanisms for OAuth
draft-ietf-kitten-sasl-oauth-21.txt draft-ietf-kitten-sasl-oauth-22.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 October 19, 2015. This Internet-Draft will expire on November 1, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 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
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 . . . . . . . . 9 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 . . 11
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Successful Bearer Token Exchange . . . . . . . . . . . . 12 4.1. Successful Bearer Token Exchange . . . . . . . . . . . . 12
4.2. Successful OAuth 1.0a Token Exchange . . . . . . . . . . 13 4.2. Successful OAuth 1.0a Token Exchange . . . . . . . . . . 13
4.3. Failed Exchange . . . . . . . . . . . . . . . . . . . . . 13 4.3. Failed Exchange . . . . . . . . . . . . . . . . . . . . . 14
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 . . . . . . . . . . . . . . . . . . . 16
6. Internationalization Considerations . . . . . . . . . . . . . 16 6. Internationalization Considerations . . . . . . . . . . . . . 17
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
7.1. SASL Registration . . . . . . . . . . . . . . . . . . . . 17 7.1. SASL Registration . . . . . . . . . . . . . . . . . . . . 17
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.1. Normative References . . . . . . . . . . . . . . . . . . 18 8.1. Normative References . . . . . . . . . . . . . . . . . . 18
8.2. Informative References . . . . . . . . . . . . . . . . . 19 8.2. Informative References . . . . . . . . . . . . . . . . . 19
Appendix A. Acknowlegements . . . . . . . . . . . . . . . . . . 19 Appendix A. Acknowlegements . . . . . . . . . . . . . . . . . . 20
Appendix B. Document History . . . . . . . . . . . . . . . . . . 20 Appendix B. Document History . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 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.
skipping to change at page 6, line 30 skipping to change at page 6, line 30
resource server. resource server.
OAUTH10A: OAuth 1.0a MAC tokens (using the HMAC-SHA1 keyed OAUTH10A: OAuth 1.0a MAC tokens (using the HMAC-SHA1 keyed
message digest), as described in Section 3.4.2 of [RFC5849]. message digest), as described in Section 3.4.2 of [RFC5849].
New extensions may be defined to add additional OAuth Access Token New extensions may be defined to add additional OAuth Access Token
Types. Such a new SASL OAuth mechanism can be added by simply Types. Such a new SASL OAuth mechanism can be added by simply
registering the new name(s) and citing this specification for the registering the new name(s) and citing this specification for the
further definition. further definition.
SASL mechanisms using this document as their definition do not
provide a data security layer; that is, they cannot provide integrity
or confidentiality protection for application messages after the
initial authentication. If such protection is needed, TLS or some
similar solution should be used. Additionally, for the two
mechanisms specified in this document, TLS MUST be used for
OAUTHBEARER to protect the bearer token; for OAUTH10A the use of TLS
is RECOMMENDED.
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 authentication 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
skipping to change at page 8, line 38 skipping to change at page 8, line 49
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
The server validates the response according the specification for the The server validates the response according the specification for the
OAuth Access Token Types used. If the OAuth Access Token Type OAuth Access Token Types used. If the OAuth Access Token Type
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 fully validates the client response before generating a
server response; this will necessarily include the validation steps
listed in the specification for the OAuth Access Token Type used.
However, additional validation steps may be needed, depending on the
particular application protocol making use of SASL. In particular,
values included as kvpairs in the client response (such as host and
port) which correspond to values known to the application by some
other mechanism (such as an application protocol data unit or pre-
configured values) MUST be validated to match between the initial
client response and the the other source(s) of such information. As
a concrete example, when SASL is used over IMAP to an IMAP server for
a single domain the hostname can be vaialble via configuration; this
hostname must be validated to match the value sent in the 'host'
kvpair.
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 authzid is specified by the resource. Note that the semantics of the authzid is specified by the
SASL framework [RFC4422]. SASL framework [RFC4422].
3.2.1. OAuth Identifiers in the SASL Context 3.2.1. OAuth Identifiers in the SASL Context
 End of changes. 9 change blocks. 
11 lines changed or deleted 35 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/