Re: [kitten] WGLC on draft-ietf-kitten-sasl-oauth-15

[Benjamin Kaduk <[e-mail]>]

On Fri, 5 Sep 2014, Bill Mills wrote:

> On Friday, September 5, 2014 10:05 AM, Benjamin Kaduk <[e-mail]> wrote:
>
>
> I see that the notation "%x01" is used throughout to indicate the octet
> with value 0x01, and this is used without comment in RFC 7159 (the JSON
> spec).  I guess this is standard in ABNF-land, but section 2 doesn't
> mention that we assume familiarity with such terminology.
>
> ***
> [bill] that's actually HTTP (URI?) entity encoding.
> ***

So we think that familiarity with RFC 6749 (OAuth 2.0) implies an
understanding of this usage?  If so, that's fine by me.


> In section 6, the example is given of "when SASL is used in the context of
> IMAP the resource server may assert the resource owner's email address to
> the IMAP server for usage in an email-based application.".  But isn't the
> IMAP server the resource server here?  Maybe it is the authorization
> server which is making this assertion?
>
> ***
> [bill]  it's the client asserting the email address, this now reads "in the
> context of IMAP the client may assert the resource owner's email address".
> ***

Okay, thanks.

> Also in 3.1, the sentence mandating that the server MUST fail requests
> that do not have host and port values but use keyed message digests could
> be made more clear.  I'm uncertain which sort of requests do require keyed
> message digests, so I don't really have any suggestions.
>
> ***
> [bill]  Changed to: "For OAuth token types such as OAuth 1.0a that use keyed
> message digests"
> ***

That helps some.  I think it was the text which is normative for the
server's actions that left me unsatisfied, though.  Seeing this now, I
suggest "server MUST fail an authorization request requiring keyed message
digests that is not accompanied by host and port values" (so, changing
from "do not have" to "is not accompanied by").  This does slightly change
the assumption of what blob of data is an "authorization request", i.e.,
is it the client response, or the value corresponding to the auth key.  If
it's the former, then my suggestion is probably not correct.

> In 3.2.1, I would be more comfortable if the second paragraph gave me some
> reason to think that doing so is possible.  Is there prior art, or some
> other specification for a similar thing that gives an example?  We don't
> need to enumerate every way it could be done, but it seems useful to give
> an indication that this is not going to end up dropping a heraculean task
> on the developer.
>
> ***
> [bill]  OAuth 1.0a tokens may well (and commonly have in some implementations)
> either carried or has access to the client identity.
>
> For the question of whether both identities can be communicated to the app, it
> would be a new capability you'd have to add to the SASL implementation you're
> using.  Not herculean, but not trivial if you're going to patch something like
> Cyrus SASL and keep it in sync with current releases.
> ***

So, an extension to the SASL library's API?  I'm not immediately coming up
with a good way to include that in the text, so maybe we can leave it
as-is.

> Editorial minutiae:
>
> The first paragraph of page 4 has the sentence "The framework also
> provides a protocol for security subsequent protocol exchanges within a
> data security layer.", which uses the word 'protocol' twice with two
> different usages.  It is probably best to add a qualifier to at least one
> occurrence.
>
> ***
> [bill] IIRC this is lifted from the SASL spec itself.  That said, deleting the
> second usage seems to do the trick, " The framework also provides a protocol for
> securing subsequent exchanges within a data security layer."
> ***

Yup, that seems to work well.

> The end of section 1 notes that "In band discovery is not tenable if
> clients support the OAuth 2.0 password grant."  It would be nice to say
> something about why.
>
> ***
> [bill] Now there's a fun topic.  There are folks that assert that allowing in
> band discovery if the password grant is in play might lead to an effective
> phishing attack.  Other's disagree.  No one hated the current language.  I'm
> really tempted to leave it alone.
> ***

Okay.  I don't want to go from uncontroversial text to controversial text.

> In section 3.1, replace "or may be empty" with "which may be empty".
>
> ***
> [bill]  no, because the empty client response containing only the 0x01 has no GS2
> header, now reads, "header followed by zero or more key/value pairs, or may be
> empty."
> ***

Ah, I see now.  Sorry for the confusion.

-Ben