Subject: [kitten] WGLC on draft-ietf-kitten-sasl-oauth-12

From: Shawn M Emery <[email-masked]>
Date: Sun, 15 Dec 2013 23:15:01 -0700

This message officially starts the 2nd kitten Working Group Last Call 
for the following document:

A set of SASL Mechanisms for OAuth
http://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-12

The Working Group Last Call for this document starts today on Sunday, 
December 15th and will end on Tuesday, December 31st.

Please send any comments to the kitten mailing list or directly to the 
chairs.  Even if you reviewed this document and found no issues then 
please provide this feed-back.

Thank you,

Shawn Emery
kitten co-chair
--

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Tue, 17 Dec 2013 22:46:57 +0000

On Dec 15, 2013, at 11:15 PM, Shawn M Emery <[email-masked]> wrote:

> 
> This message officially starts the 2nd kitten Working Group Last Call for the following document:
> 
> The Working Group Last Call for this document starts today on Sunday, December 15th and will end on Tuesday, December 31st.
> 
> Please send any comments to the kitten mailing list or directly to the chairs.  Even if you reviewed this document and found no issues then please provide this feed-back.
> 

Here are my current comments on this draft (more might come later):

MAJOR:

* Removing the GS2-header (which was done in revision -11) also removed the ability for the client to specify an authorization identity.  If the lack of an authorization identity is acceptable (and I suspect it is not for some), then the document needs to state these mechanisms do not support authz-id.

* In section 3.2.2. Server Response to Failed Authentication, returning a space-separated list for the "scope" field is NOT RECOMMENDED, but also says the lack of a "scope" (value or field) implies the client SHOULD request tokens that are unscoped (empty list of scopes).  However, RFC 6749 § 3.3 does not permit unscoped tokens; the ABNF does not allow for "scope=" (i.e., the empty list), and the text regarding the lack of scope means the authorization server uses a default scope value (or fails authorization outright).  To me, this seems like a contradiction that would lead to interoperability problems.

MINOR:

* In section 2. Terminology, it does not explicitly state that the reader ought to be familiar with terminology from RFC 4422.  This should be added.

* In section 3.2.2. Server Response to Failed Authentication, the last paragraph still discusses channel binding.  It should be removed.

* All of the examples include a gs2-header, but this was removed from the ABNF.  The examples need to be updated to remove the header.

* In section 8.1. Normative References, there is an entry for RFC 5056, but this reference is no longer used in the document.  It should be removed.

NITS:

* HTTP is mentioned but no citation or definition is included.

* XMPP is mentioned but no citation or definition is included.

* In section 1. Introduction, SMTP is mentioned with a citation but without a definition (unlike SASL and IMAP immediately preceding).

* In section 3. OAuth SASL Mechanism Specifications, the two lists describing success and failure flows are in fact ordered (numbered), but the document presents them as unordered (symbols).

* In section 3.2.2. Server Response to Failed Authentication, replace [[ need registry name ]] with "OAuth Extensions Error Registry".

* In section 4.2. Failed Exchange, the "status" value of "401" is not in the OAuth Extensions Error Registry; "invalid_request" seems appropriate here instead.

* In section 4.3. SMTP Example of a Failed Negotiation, the (encoded) server response uses a "status" value of "401", which is not in the OAuth Extensions Error Registry; "invalid_token" seems appropriate here instead.

* In section 5. Security Considerations, he phrase "This document specifies three SASL mechanisms should be "This document specifies two SASL mechanisms".

* In Appendix A. Acknowledgements, "area directors" should be "area director".

- m&m

Matt Miller < [email-masked] >
Cisco Systems, Inc.

---

From: Bill Mills <[email-masked]>
Date: Tue, 17 Dec 2013 17:24:33 -0800

Inline below.  I need to fix the examples as you note.

-bill

--------------------------------
William J. Mills
"Paranoid" Yahoo!

On Tuesday, December 17, 2013 2:47 PM, Matt Miller (mamille2) <[email-masked]> wrote:

MAJOR:

[wmills] This is addressed in 3.2.1 of -12  authz-id is possible in some OAuth schemes.

[wmills] "scope" is an optional parameter, so if you want an empty value you don't send scope at all.

MINOR:

[wmills] OK

[wmills] OK

[wmills] OK

NITS:

[wmills] OK x2

[wmills] I see "SMTP [RFC5321]" there

[wmills] OK

[wmills] OK

[wmills] Will fix the 2 above (as opposed to OK which indicates I already did the edit)

[wmills] OK

[wmills] OK

- m&m

_______________________________________________
Kitten mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/kitten

---

From: Bill Mills <[email-masked]>
Date: Tue, 17 Dec 2013 18:11:51 -0800

Matt's edits are included in my working copy and viewable/commentable at https://drive.google.com/file/d/0B99YSkxS6ZefdG1fSFFIeWxtNUE/edit?usp=sharing though I don't have the fancy diff version.

-bill

On Tuesday, December 17, 2013 5:25 PM, Bill Mills <[email-masked]> wrote:

 
-bill

 
On Dec 15, 2013, at 11:15 PM, Shawn M Emery <[email-masked]> wrote:

> Please send any comments to the kitten mailing list or directly to the chairs.  Even if you reviewed this document and found no
 issues then please provide this feed-back.

MAJOR:

* In section 3.2.2. Server Response to Failed Authentication, returning a space-separated list for the "scope" field is NOT RECOMMENDED, but also says the lack of a "scope" (value or field) implies the client SHOULD request tokens that are unscoped (empty list of scopes). 
 However, RFC 6749 § 3.3 does not permit unscoped tokens; the ABNF does not allow for "scope=" (i.e., the empty list), and the text regarding the lack of scope means the authorization server uses a default scope value (or fails authorization outright).  To me, this seems like a contradiction that would lead to interoperability problems.

MINOR:

[wmills] OK

[wmills] OK

* All of the examples
 include a gs2-header, but this was removed from the ABNF.  The examples need to be updated to remove the header.

[wmills] OK

NITS:

[wmills] OK x2

[wmills] OK

[wmills] OK

[wmills] OK

[wmills] OK

- m&m

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Wed, 18 Dec 2013 16:25:03 +0000

Thanks for the rapid turnover!

One additional item I just noticed: the reference to [I-D.draft-ietf-oauth-v2-http-mac] is out of date. It should be draft-ietf-oauth-v2-http-mac-04, not -01.

More inline, stripping all but what I'm responding to:

> [wmills] This is addressed in 3.2.1 of -12  authz-id is possible in some OAuth schemes.

Section 3.2.1. talks about authentication identities (authn-id), not authorization identities (authz-id).  The two are different: authn-id is who holds the credentials (such as they are in OAuth) and authz-id is whom the authn-id is acting as.

The more I read that section, the less convinced I am that it meets the requirements for SASL mechanisms (RFC 4422 § 5).  Identities (at least authn-id, and often authzid) are provided for all other SASL mechanisms, and all of the SASL-using protocols I'm familiar with rely on an identity coming out of the SASL exchange.

I understand that the access token itself is not guaranteed to contain this information, but at some level the resource server needs to be able to associate the SASL authentication credentials (OAuth access token) with an authentication and/or authorization identity.  From what I've seen of existing OAuth software, there is some way to determine an identity -- if not encoded directly in the access token, then by agreement between the resource server and the authorization server (e.g., REST APIs specific to the authorization server).

I suppose one possible transposition is for the authn-id to be the OAuth client identity and the authz-id to be the OAuth resource owner identity.  I personally don't find this mapping interesting or appropriate, and doesn't account for the resource owner acting as a different identity within the context of the SASL-using application.

A possible starting point for text (not sure where in 3.2.1. to place it):

""""
The authentication identity is determined by the resource server using information associated with the access token. This information might be encoded within the access token itself, or the resource server might obtain the information from the authorization server through other means. The specific method is outside the scope of this work.
""""

This still doesn't account for the authorization identity. This could be handled by adding a new kvpair (e.g., "authzid") and maybe some language about how the resource server might validate/verify its use against the provided credentials.

Or, I'm just tilting at windmills.

> [wmills] "scope" is an optional parameter, so if you want an empty value you don't send scope at all.

My apologies for not being clear.

As I read the document, there are two ways I can see how to interpret the term "unscoped":

1. scope of "" during the authorization request
2. omit the scope from the authorization request

The first is clearly in violation of RFC 6749 (the ABNF requires at least one scope-token, and the scope-token requires at least one printable non-whitespace ACII character).  The second, however, seems to invite failure because the authorization server MUST either use the default scope (if it has one) or fail authorization.

According to this document, the resource server providing a scope of something other than "" is NOT RECOMMENDED.  That means (as I interpret from RFC 2119) that "I can try to return a non-empty scope, but it will likely cause problems in most cases".

This document states that clients that receive an error response with an empty scope (or no scope at all) SHOULD omit the scope from the authorization request (since, again, specifying a scope of "" violates RFC 6749).  SHOULD means (as I interpret from RFC 2119) that "I can try to specify a scope anyway, but it will likely cause problems in most cases".

I am then balancing all this against what I've experienced with already deployed OAuth frameworks: not specifying a scope results in a failure from the authorization server.  Many -- if not most -- OAuth client libraries won't send an authorization request with a scope specified.

This is the interoperability problem I see in this document.  It seems (to me) that it is destined to cause confusion and at best, and non-functioning (if following the SHOULDs and NOT RECOMMENDEDs) or non-compliant (ignoring the SHOULDs and NOT RECOMMENDEDs) code at worst.

I think this could be fixed by either removing the NOT RECOMMENDED about presenting a space-separated list for scope, or by changing the SHOULD to a MAY regarding what the client sends for the authorization request. I think it would also help to define what unscoped means, or not use the term at all.

Suggested starting point for text (replacing all of section 3.2.2):

""""
For a failed authentication the server returns a JSON [RFC4627] formatted error result, and fails the authentication. The error result consists of the following values:

    status (REQUIRED):
        The authorization error code. Valid error codes are defined in the IANA "OAuth Extensions Error Registry" specified in the OAuth 2 core specification. 
    scope (OPTIONAL):
        An OAuth scope which is valid to access the service. This may be empty or a space separated list. Use of a space separated list is NOT RECOMMENDED. 

If the resource server provides a scope value that is not the empty string then the client MUST always request scoped tokens from the token endpoint. If the resource server provides no scope to the client then the client MAY omit the scope from the authorization request.
""""

> [wmills] I see "SMTP [RFC5321]" there

What I see:

* Simple Authentication and Security Layer (SASL) [RFC4422]
* Internet Message Access Protocol (IMAP) [RFC3501]
* SMTP [RFC5321]

One of these things is not like the others (-:

This is very clearly a nit.  The lack of consistency erks me somewhat, but I doubt it truly matters.

- m&m

---

From: Bill Mills <[email-masked]>
Date: Wed, 18 Dec 2013 10:24:25 -0800

We went around a number of times on the SASL identities.  The problem I see is that the assertion of authz-id if it's specified separately in protocol just has to be matched/confirmed by the token anyway so the value should just be derived from that.

Not sure why the MAC token draft number is wrong.  I'm using the xml2rfc format and referring to <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-oauth-v2-http-mac.xml' ?> so I'm not sure what to fix.

On scopes, I'm not liking your changes but see the problem.  The current text is:

"An OAuth scope which is valid to access the service. This may be empty which implies that unscoped tokens are required, or a space separated list. Use of a space separated list is NOT RECOMMENDED."

I propose:

"An OAuth scope which is valid to access the service. This may be empty which implies that unscoped tokens are required, or a scope value.  If a scope is specified then a single scope is preferred, use of a space separated list of scopes is NOT RECOMMENDED."
 
-bill

P.S. Nits...  "erk" is actually a sound made when you drop something on your foot, "irk" is indicative of the reaction to excessive pedantry. :)

On Wednesday, December 18, 2013 8:25 AM, Matt Miller (mamille2) <[email-masked]> wrote:

""""

""""

    status (REQUIRED):

What I see:

- m&m

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Wed, 18 Dec 2013 19:09:59 +0000

> We went around a number of times on the SASL identities.  The problem I see is that the assertion of authz-id if it's specified separately in protocol just has to be matched/confirmed by the token…

I still think you're still conflating authn-id and authz-id here.

An example: let's say we have an XMPP service, where a session is long-lived and have a strong identity (effectively, the sender address cannot be anything other than what the user logged in with).  Our resource owner has multiple identities on this service ("[email-masked]", "[email-masked]", "[email-masked]"), but one set of credentials on the authorization server.

In this case, what should the XMPP service use for the identity?

For most other SASL mechanisms, this is where authz-id is used.  It still absolutely requires the resource server to confirm the authz-id is appropriate for the given credentials (token).  If there were only one possible identity, then the client shouldn't even specify an authz-id (IMO).  But where there are multiple possible identities, the user might want to pick one other than the default.

Now, it could very well be that the above is not something that ought to be supported for SASL-OAuth.  It could be that the resource owner needs to choose the specific identifier to use as part of the OAuth authorization flow before the token is even granted.  If this is the most desired case, then the mechanisms need to specifically state that they do not transfer authorization identity strings.

> Not sure why the MAC token draft number is wrong.  I'm using the xml2rfc format and referring to <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-oauth-v2-http-mac.xml'…

Hrm.  Maybe there is an overly aggressive caching proxy between you and xml.resource.org, or an overly aggressive local cache?

I would suggest using "https://", but it looks like the cert isn't valid for xml.resource.org!

/me notes to follow up on that...

> "An OAuth scope which is valid to access the service. This may be empty which implies that unscoped tokens are required, or a scope value.  If a scope is specified then a single scope is preferred,…

That works for me, and I think that's what most deployments will want to do.

- m&m

> P.S. Nits...  "erk" is actually a sound made when you drop something on your foot, "irk" is indicative of the reaction to excessive pedantry. :)

I said erk out loud when i saw it, does that count (-:

---

From: Bill Mills <[email-masked]>
Date: Thu, 19 Dec 2013 10:20:49 -0800

I've included the language change for scope.

On Authz-ID we ended up with some kind of fuzzy language there and we knew it.  The problem being that it will depend on the specific implementation.  It's possible to do OAuth 1.0a without any useful client authentication for example.  I'm not in love with the current language, but I can't see a better way without forcing some set of reasonable implementations into non-compliance.

-bill

On Wednesday, December 18, 2013 11:10 AM, Matt Miller (mamille2) <[email-masked]> wrote:

- m&m