Re: [kitten] AD review of draft-ietf-kitten-sasl-oauth-21

[Stephen Farrell <[e-mail]>]

Hiya,

On 25/04/15 18:25, Bill Mills wrote:
> Responses inline...
> 
> 
> On Saturday, April 25, 2015 7:06 AM, Stephen Farrell <[e-mail]> wrote:
> 
> 
> Hiya,
> 
> Sorry for the bit of delay here but I've done my AD evaluation
> of this. I have to questions I'd like to understand the answers
> for before starting IETF LC. I'm not sure if those will or will
> not cause any revisions to be needed before LC. Please consider
> the other nits along with any IETF LC comments that turn up.
> 
> My questions:
> 
> (1) 3.1 - I'm not getting why the host and port number are
> needed - won't the server know those anyway? (At least the
> port number for sure.) And if not, then I'm not clear what's
> going on, or it at least needs more explanation. Can you
> 
> explain?
> 
> [wmills] To allow support of things like OAuth 1.0a that need
> the host and port to construct the signature base string.  No
> the host may not know what name the client used to connect to
> it given that the same IMAP server (for example) might have N
> different names if it's a provider serving multiple companies
> each with their own domain name. 

In principle the client might use a hostname that the server
doesn't know about, or can't determine. However, were it the
case that the SASL mechanism has to tell the server, then the
application protocol would not work for multiple server
identities with other SASL mechanisms, right? In which case
the server has to know already or is broken. Or can you provide
me with the details of a protocol that uses SASL where this is
a real issue?

I also don't see any case where the server does not know on
which port it received data.

And if the client could use authorization information for
server1 at what the server thinks is server2 then that would seem
to raise some significant vulnerabilities that are not discussed
at all.

Perhaps we're trying too hard to cover the issues faced when
OAuth1.0a was used over http without tls? Nowadays, that is
handled via SNI within TLS.

> (2) MUST TLS be provided or used? Section 4 said STARTTLS
> MUST be used, in section 5 you say provided. Either way, I
> think you should include a definitive statement in section 3
> 
> about that. (And I'd prefer MUST use of course:-)
> 
> [wmills] The must here is because it's Bearer tokens which require 
> TLS.  "The Bearer Token examples assume 
> encrypted transport; if the underlying connection is not already TLS 
> then STARTTLS MUST be used as TLS is required in the Bearer Token 
> specification."  OAuth 1.0a may be used safely without TLS, but of
> course the underlying data should probably have TLS for privacy etc.

All of that is fine, but does not explain why section 3 doesn't
clearly say when TLS must be used, nor why sections 4 and 5 are
not quite saying the same thing about that. So I think my question
isn't really answered yet, sorry.

S.

> 
> nitty nits:
> 
> 
> - ID nits gets a few reference things wrong, but it's ok
> 
> [wmills] happy to fix them if needed.  Will RFC Ed. do it anyway?
> 
> - 3.1 (and elsewhere probably) I'm assuming the ABNF
> has been cross-checked, is that a safe assumption?
> 
> 
> [wmills]  I believe so.  I'm aware of multiple interoperable 
> implementations, Google and Outlook.com are major providers who
> have implemented.
> - 3.1 kvsep with a value of 0x01 - is that commonly used?
> But it might be quite common for all I know:-)
> 
> 
> [wmills] Control character separators are common in many systems.
> I chose it because we're handling things that might otherwise be
> in HTTP headers and 0x01 isn't valid there so we don't have to 
> worry about escaping.
> 
> - 3.1, is there a real privacy benefit in omitting the
> authzid (where it works to omit that)? If not, this
> question is probably moot. But if there is, I wonder if
> the way you've stated the MAY there will result in people
> always including that if they can, which might not be what
> we want. In any case, the guidance here is a bit vague
> (and maybe it has to be) so would it be possible to be
> more concrete about in/ex-clusion of authzid?
> 
> 
> [wmills] In the end whether authzid is required is based on 
> server policy.  I suspect you are right that clients will 
> include it even when it's not needed because servers might
> require it and a generic client won't know.  The existing 
> implementations all have data in the protocol (IMAP, SMTP) that 
> mirror the authzid anyway.
> 
> 
> - Section 4, I also assume the examples have been checked.(Good set of examples though.)
> 
> 
> [wmills] Ben did make me fix several as iteration happened
> so they have had at least one review..
> 
> 
> Cheers,
> Stephen.
> 
> _______________________________________________
> Kitten mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/kitten
> 
>