--- 1/draft-ietf-kitten-sasl-oauth-21.txt 2015-04-30 11:14:57.215643863 -0700 +++ 2/draft-ietf-kitten-sasl-oauth-22.txt 2015-04-30 11:14:57.263645030 -0700 @@ -1,21 +1,21 @@ KITTEN W. Mills Internet-Draft Microsoft Intended status: Standards Track T. Showalter -Expires: October 19, 2015 +Expires: November 1, 2015 H. Tschofenig ARM Ltd. - April 17, 2015 + April 30, 2015 A set of SASL Mechanisms for OAuth - draft-ietf-kitten-sasl-oauth-21.txt + draft-ietf-kitten-sasl-oauth-22.txt Abstract OAuth enables a third-party application to obtain limited access to a protected resource, either on behalf of a resource owner by orchestrating an approval interaction, or by allowing the third-party application to obtain access on its own behalf. This document defines how an application client uses credentials obtained via OAuth over the Simple Authentication and Security Layer @@ -38,21 +38,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -66,34 +66,34 @@ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. OAuth SASL Mechanism Specifications . . . . . . . . . . . . . 6 3.1. Initial Client Response . . . . . . . . . . . . . . . . . 7 3.1.1. Reserved Key/Values . . . . . . . . . . . . . . . . . 8 3.2. Server's Response . . . . . . . . . . . . . . . . . . . . 8 3.2.1. OAuth Identifiers in the SASL Context . . . . . . . . 9 3.2.2. Server Response to Failed Authentication . . . . . . 9 3.2.3. Completing an Error Message Sequence . . . . . . . . 10 - 3.3. OAuth Access Token Types using Keyed Message Digests . . 10 - 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 3.3. OAuth Access Token Types using Keyed Message Digests . . 11 + 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1. Successful Bearer Token Exchange . . . . . . . . . . . . 12 4.2. Successful OAuth 1.0a Token Exchange . . . . . . . . . . 13 - 4.3. Failed Exchange . . . . . . . . . . . . . . . . . . . . . 13 - 4.4. SMTP Example of a Failed Negotiation . . . . . . . . . . 14 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 - 6. Internationalization Considerations . . . . . . . . . . . . . 16 + 4.3. Failed Exchange . . . . . . . . . . . . . . . . . . . . . 14 + 4.4. SMTP Example of a Failed Negotiation . . . . . . . . . . 15 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 + 6. Internationalization Considerations . . . . . . . . . . . . . 17 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 7.1. SASL Registration . . . . . . . . . . . . . . . . . . . . 17 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 8.1. Normative References . . . . . . . . . . . . . . . . . . 18 8.2. Informative References . . . . . . . . . . . . . . . . . 19 - Appendix A. Acknowlegements . . . . . . . . . . . . . . . . . . 19 + Appendix A. Acknowlegements . . . . . . . . . . . . . . . . . . 20 Appendix B. Document History . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 1. Introduction OAuth 1.0a [RFC5849] and OAuth 2.0 [RFC6749] are protocol frameworks that enable a third-party application to obtain limited access to a protected resource, either on behalf of a resource owner by orchestrating an approval interaction, or by allowing the third-party application to obtain access on its own behalf. @@ -239,20 +239,29 @@ resource server. OAUTH10A: OAuth 1.0a MAC tokens (using the HMAC-SHA1 keyed message digest), as described in Section 3.4.2 of [RFC5849]. New extensions may be defined to add additional OAuth Access Token Types. Such a new SASL OAuth mechanism can be added by simply registering the new name(s) and citing this specification for the 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 always replying to a client message. In the case where the client has and correctly uses a valid token the flow is: 1. Client sends a valid and correct initial client response. 2. Server responds with a successful authentication. In the case where authentication fails the server sends an error result, then client MUST then send an additional message to the @@ -339,20 +348,35 @@ qs (RESERVED): The HTTP query string, the default value is "". 3.2. Server's Response The server validates the response according the specification for the OAuth Access Token Types used. If the OAuth Access Token Type utilizes a keyed message digest of the request parameters then the client must provide a client response that satisfies the data 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 completing the SASL negotiation. The authenticated identity reported by the SASL mechanism is the identity securely established for the client with the OAuth credential. The application, not the SASL mechanism, based on local access policy determines whether the identity reported by the mechanism is allowed access to the requested resource. Note that the semantics of the authzid is specified by the SASL framework [RFC4422]. 3.2.1. OAuth Identifiers in the SASL Context