A Set of Simple Authentication and Security Layer (SASL) Mechanisms for OAuth
draft-ietf-kitten-sasl-oauth-23

[Ballot comment]
[All of the comments below have been addressed by the authors]

-- section 1, description of step A:

if the preferred way is different than the diagram, why not show it the preferred way in the diagram in the first place?

-- 1, 2nd to last paragraph

The "SHOULD" means the reference to I-D.ietf-oauth-dyn-reg needs to be be normative.

-- 3: "Such a new SASL OAuth mechanism can be added by simply
  registering the new name(s)"

Register them where?

-- 3.2, 2nd paragraph : "... known to the application."

Known to the "resource server"?

Editorial Stuff:

-- 3.1, "Port":

I assume that means the destination port to which the client connected? (similar to Host?)

-- 3.1.1 "Post": default value is "".

Does "" represent an empty string?

-- 3.2, first sentence"

s/" ... according the specification..." / "... according to the specification..."

- 5: "Lifetime of the appliation sessions"

s/appliation/application

"It is possible that SASL will be authenticating..."

s/"... be authenticating..." / "... be used to authenticate..."

[Ballot comment]
-- section 1, description of step A:

if the preferred way is different than the diagram, why not show it the preferred way in the diagram in the first place?

-- 1, 2nd to last paragraph

The "SHOULD" means the reference to I-D.ietf-oauth-dyn-reg needs to be be normative.

-- 3: "Such a new SASL OAuth mechanism can be added by simply
  registering the new name(s)"

Register them where?

-- 3.2, 2nd paragraph : "... known to the application."

Known to the "resource server"?

Editorial Stuff:

-- 3.1, "Port":

I assume that means the destination port to which the client connected? (similar to Host?)

-- 3.1.1 "Post": default value is "".

Does "" represent an empty string?

-- 3.2, first sentence"

s/" ... according the specification..." / "... according to the specification..."

- 5: "Lifetime of the appliation sessions"

s/appliation/application

"It is possible that SASL will be authenticating..."

s/"... be authenticating..." / "... be used to authenticate..."

[Ballot comment]
Another excellent, informative shepherd writeup, which helped with my review of the document.  (And, I'll say, most of the really useful writeups, as this one, seem to use the "essay" format, rather than the Q&A format.)  Thanks, Ben, for the writeup.

-- Section 1 --

  way to use the Simple Authentication and Security Layer (SASL)
  [RFC4422] to gain access to resources when using non-HTTP-based
  protocols, such as the Internet Message Access Protocol (IMAP)
  [RFC3501] and the Simple Mail Transfer Protocol (SMTP) [RFC5321],
  which is what this memo uses in the examples.

When I first read this, I thought the last phrase was bound to SMTP... but then I see that both IMAP and SMTP are used in the examples.  So, a small thing, but I'd end the sentence after the 5321 reference, and make the last phrase into another sentence, like, "This document gives examples of use in IMAP and SMTP."

-- Section 2 --

  Note that the IMAP SASL specification requires base64 encoding, see
  Section 4 of [RFC4648], not this memo.

Nit: That seems kind of an odd way to put it, in addition to its having a comma splice.  Why not this?:

NEW
  Note that the IMAP SASL specification requires base64 encoding, as
  specified in Section 4 of [RFC4648].
END

-- Section 3.2 --
Nit: "vaialble" -> "available"

-- Section 3.2.2 --

      scope (OPTIONAL):  An OAuth scope which is valid to access the
        service.  This may be omitted which implies that unscoped
        tokens are required.  If a scope is specified then a single
        scope is preferred, use of a space separated list of scopes is
        NOT RECOMMENDED.

Why is it "NOT RECOMMENDED"?  What interoperability or security issue is in play here that makes this "SHOULD NOT"?

        The server MAY return different URLs for users in
        different domains and the client SHOULD NOT cache a single
        returned value and assume it applies for all users/domains that
        the server suports.  The returned discovery document SHOULD
        have all data elements required by the OpenID Connect Discovery
        specification populated.

Similar questions for the SHOULD NOT and SHOULD here.  In this case, I don't understand why they aren't "MUST NOT" and "MUST": for the first, I don't understand how a client can interoperate with a server if it violates this, and for the second, if they data elements are "required", why isn't including them a "MUST"?

(Nit: The "if available" at the end of the paragraph is unnecessary; if one is not available, it certainly can't be used.)

-- Section 4.1 --

  The
  underlying TLS establishment is not shown but is required for using
  Bearer Tokens per that specification.

  S: * OK IMAP4rev1 Server Ready
  C: t0 CAPABILITY
  S: * CAPABILITY IMAP4rev1 AUTH=OAUTHBEARER SASL-IR
  S: t0 OK Completed

The problem with this is that if the underlying TLS establishment is done through STARTTLS on port 143, that would come between the first line ("S: * OK IMAP4rev1 Server Ready") and the second.  And that makes the example a bit odd.  The easiest way out of that is simply to remove the first line.  Or, better, to replace the first line with something like "[Initial connection and TLS establishment...]".  (This applies to the subsequent sections as well.)

I wonder why you don't wrap the decoded payload here the same way you do in Section 4.2 (or there the same as here).  I suggest that there'd be less room for any confusion if you did them all (4.3 also) the same way (I don't care which way you choose).

In the SMTP part, you say this:

  Note
  that line breaks are inserted for readability, and that the SMTP
  protocol terminates lines with CR and LF characters (ASCII values
  0x0D and 0x0A), these are not displayed explicitly in the example.

The same is true for the IMAP protocol and example, but you don't say this there.  Actually, I don't think you need to say it in either place, and suggest simply removing it here (and in Section 4.4).

-- Section 4.4 --
In the SMTP protocol, you should have "[Negotiate TLS...]" before the SMTP AUTH command, as you do in Section 4.1.

[Ballot comment]
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.

Can someone explain to me situation were intergrity protection is not desirable (possibly rhetorical). it seems like it might be better to clarify what the exception is and use a blanket must for everything else.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-kitten-sasl-oauth-22. Please report any inaccuracies and respond to any questions as soon as possible.

IANA's reviewer has the following comments:

IANA understands that, upon approval of this document, there is a single action which IANA must complete.

In the SASL Mechanisms registry under the Simple Authentication and Security Layer (SASL) Mechanisms heading at

https://www.iana.org/assignments/sasl-mechanisms/

two new SASL mechanisms will be registered as follows:

Mechanism: OAUTHBEARER
Usage: COMMON
Reference: [ RFC-to-be ]
Owner: IESG

Mechanism: OAUTH10A
Usage: COMMON
Reference: [ RFC-to-be ]

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (A set of SASL Mechanisms for OAuth) to Proposed Standard


The IESG has received a request from the Common Authentication Technology
Next Generation WG (kitten) to consider the following document:
- 'A set of SASL Mechanisms for OAuth'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-05-14. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

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
  (SASL) to access a protected resource at a resource serve.  Thereby,
  it enables schemes defined within the OAuth framework for non-HTTP-
  based application protocols.

  Clients typically store the user's long-term credential.  This does,
  however, lead to significant security vulnerabilities, for example,
  when such a credential leaks.  A significant benefit of OAuth for
  usage in those clients is that the password is replaced by a shared
  secret with higher entropy, i.e., the token.  Tokens typically
  provide limited access rights and can be managed and revoked
  separately from the user's long-term password.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-kitten-sasl-oauth/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-kitten-sasl-oauth/ballot/


No IPR declarations have been submitted directly on this I-D.

This defines a way to use the obsolete OAUTH1.0a mechanism
as well an OAUTH2 mechanism. That is deliberate and reasonable.

1. Summary

The document shepherd is Benjamin Kaduk.  The responsible Area Director
is Stephen Farrell.

This document specifies the OAuth protocol exchange between client
and resource server over SASL.  The core OAuth protocol specifies
only interactions between the client and the resource owner, and the
client and the authorization server, leaving interactions between
the client and resource server to be specified as part of the
specification of a token format, such as HTTP bearer tokens.  The
existing specified OAuth token types only consider interactions
between client and resource server which occur over HTTP; this
document provides a scheme by which the interactions specified
for HTTP can instead be performed over SASL.  In particular the
OAUTHBEARER and OAUTH10A SASL profiles are created, which correspond
to wrapped versions of the HTTP bearer token and OAuth 1.0a token
formats.  The wrapping scheme is sufficiently general that it
should be reusable for future token formats defined for HTTP.  The
ability to perform the OAuth exchange between client and resource
server over SASL allows OAuth to be used to authorize access
for non-HTTP protocols, such as IMAP and SMTP, as shown in the examples.

The SASL messages are specified to include a GS2 header to facilitate
potential future extension to a GSS-API mechanism, but no GSS-API
mechanism is specified at this time.  (The GS2 header also conveys
some information which is needed even for a pure SASL mechanism and
thus does not need to be duplicated explicitly in this specification.)

This document presents SASL mechanisms, and as such its intended
status is Proposed Standard.


2. Review and Consensus

The review process for this document was very long and complicated;
the document went through many substantive changes during the
process, which included four working group last call periods
(on versions -08, -12, -15, and -18) over the nearly five years since
the original submission.  The protocol went back and forth on a few
issues during its review and development, so in order to understand
the level of consensus for the current text, some discussion of its
history is needed.

At the time of the initial proposal, there was some resistance
to adding a new SASL mechanism that provided neither channel binding
nor a security layer, with the argument that there was not much
utility in such a mechanism.  This kicked off a long discussion
about channel bindings and what they mean in three-party protocols
such as OpenID and OAuth, but really, they can only apply to the
single connection between the two parties in a given exchange;
here, that is the two parties using SASL, the client and the
resource server.

The initial call for WG adoption presented an option that approval be
conditional on inclusion of a channel binding option.  At the time,
it was believed that channel binding was feasible with OAuth
based on HMAC signatures, but a CB requirement for adoption was
not made.  CB was added for mechanisms with a shared
secret and signed messages in draft-mills-kitten-sasl-oauth-02, but
the document was not adopted until later, after the WG was
rechartered in 2011 to explicitly include SASL/OAuth work.
Channel binding was later split off into a separate -PLUS variant
of the mechanisms for which it was believed possible, to simplify
implementations.

During some of the early discussions it seems that many people were
assuming that the SASL mechanism would be incorporating the GS2 bridge
so as to also be a GSS-API mechanism, since that's just what was done
for all new SASL mechanisms at that time.  This assumption ended up
causing a great deal of trouble and frustration later on in the
document's progression.

It was recognized at an early stage that the usability of this
mechanism for a generic client (i.e., a desktop mail client that
can work against gmail and yahoo and everything else, as opposed
to just a gmail client) would require some means to discover the
necessary OAuth endpoints, but agreement over how much text
to include in this document (as opposed to a separate document) was
not achieved until after the third WGLC period.  That resurgence of
discovery discussion was particularly contentious: Two individuals
(one of whom is a coauthor of the document!) requested some
controversial changes regarding dynamic registration of the
corresponding author in off-list correspondence, and the corresponding
author disagreed with the proposed changes.  One of the two
individuals did bring their arguments to the list, but the other never
did so.  In the subsequent discussion, agreement was reached on the
text in section 3.2.2.  In particular, the agreed-upon text is in the
description of the openid-configuration element and the final
paragraph of section 3.2.2.

One of the motivations for this work is the existing XOAUTH2 mechanism
in use by Google.  (Google plans to update their deployment to the
final spec once it is published.)  In that deployment, a routing hint
is needed for the initial endpoint to know which mail server to route
the request to.  XOAUTH2 uses a user=xxx key/value pair to supply this
routing hint; this key was first added in the -02.  There were at
least three separate discussions of whether this "routing hint" is in
fact just the SASL authorization identity and whether it needed its
own key/value pair or could be transmitted as the authorization
identity in the GS2 header.  The discussion also covered whether the
authentication identity was what was wanted, magnifying the confusion.
This issue was basically resolved during the discussion after the
second WGLC: the routing hint is an authorization identity, and per
the SASL semantics, it is optional, and is carried in the GS2 header
when present.  Nonetheless, there is some impedance mismatch between
SASL, which ~always expects the mechanism to emit at least an
authentication id and frequently an authorization id as well, and
OAuth, which is at its core an authorization protocol and not an
authentication scheme.  This mismatch is acknowledged with the text
"It is worth noting that application protocols are allowed to require
an authzid [in the GS2 header], as are specific server
implementations."

The addition of channel binding to the mechanism allowed the
introduction of the GS2 bridge making it a GSS-API mechanism as
well.  However, there were some nagging issues about the channel
bindings: most notably, that Oauth 1.0 has three underlying
mechanisms, including PLAINTEXT which offers no real secure
signature, and an RSA scheme that was underspecified.  Only the
HMAC-SHA1 form survived as feasible (and it is still the only
OAuth 1.0 scheme permitted by the current version of the document),
but much later on, even that CB scheme was found to not actually
provide the security properties needed from channel binding,
and was also removed.  (Bearer tokens cannot provide integrity
protection for channel bindings, period.)

In addition to the discussion around channel binding and its
(non)feasibility, the addition of the GS2 bridge to the spec brought
into scope all the requirements of a GSS mechanism, including export
name formats (and naming in general for both parties!).  This, in
turn, rekindled the authorization identity vs. routing hint debate,
and whether there were more names needed by the SASL mechanism than
could be accomodated by the GSS-API.

The GSS-API requirements led to a slow-moving train wreck, which
affected not only this spec but also some which had already been
published.  At it's core, the issue is that the GS2 specification
requires both channel binding and mutual authentication to be provided
by the mechanism.  Since the OAuth mechanism cannot provide
channel binding, it is therefore unusable with the RFC 5801 GS2
bridge.  The really bad part is that this mechanism and others were
claiming to provide mutual authentication without actually doing so.
Attempting to enforce a requirement on the application using this
mechanism that it use TLS to secure the channel and also verify the
server certificate is both a layering violation and also not the
mechanism performing mutual authentication.  As it was noted during
the second WGLC, if the mechanism claims to have provided mutual
authentication, the application uses that output as an indicator that
it does not need to perform the TLS server certificate verification!

A couple of consensus calls were made in 2013, on allowing for GS2
mechanisms that do not provide mutual authentication (a change to the
GS2 spec), which did not get much discussion, and for removing GS2
support entirely from the OAuth mechanism, which did get support.  The
implementation of that removed the GS2 header as well, which was
needed to convey the authorization identity, rekindling the
authorization identity debate yet again.  The debate is resolved by
always including the GS2 header, and using the authorization identity
there, so that a future extension could specify a compatible GSS-API
mechanisms that does not require any changes to this specification.
Along with the removal of GS2, channel binding and the corresponding
-PLUS mechanism variants were removed.  Work on the GS2 update was
paused for some time, but the document has recently obtained an editor
who will help push it forward.

The third WGLC found some minor issues regarding the details of the
protocol for the server response to failed authentication, and using
'status' values from the correct registry, but also brought the
dynamic registration issue back to the forefront, as mentioned
previously.

The fourth WGLC achieved consensus with support from both kitten and
the oauth working groups.  It did result in a few clarifications to
the document, fixing the ABNF and examples, noting the generic SASL
cancellation token functionality, and reiterating the TLS requirements
for using this mechanism, but these changes were not controversial.


3. Intellectual Property

Each author has confirmed conformance with the IPR declaration
requirement.

There are no IPR declarations against this document.


4. Other Points

idnits reports an obsolete normative reference to RFC 5849, but
that is the OAuth 1.0 spec, and needs to be explicitly referenced
as distinct from OAuth 2.0, for the OAUTH10A mechanism.