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

Responses inline...

On Saturday, April 25, 2015 7:06 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie> 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. 

(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.

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
Kitten@ietf.org
https://www.ietf.org/mailman/listinfo/kitten