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

[Bill Mills <[e-mail]>]

Sorry, that was from my phone and it's impossible to read.
The port and hostname a there in the mechanism primarily to make sure that the client and server can both easily agree on what data was used in the signature.  If we need more language there to specify that the server should validate these things then that can happen but I'd really rather not take it out because it will mean writing code to get that passed through the stack by the server app.  Trying to get that info into the mechanism so that can be used by the server is custom code you have to stuff into the SASL stack. 
Section 3 explicitly requires TLS on one mechanism as I quoted, so I don't see why you're saying it's silent on TLS.  This matches the reuirements for the token specs themselves.  Bearer speakes to TLS and OAuth 1.0 has no requirement for TLS.  The mechanisms need to match the requirements for the token specs for this to make sense, and this is what the opening paragraph of Security Considerations is intended to address.
If you still think changes are needed perhaps proposed language would help us get on common ground?
Regards,
-bill

     On Saturday, April 25, 2015 3:31 PM, Bill Mills <[e-mail]> wrote:
   

 
| 

Sent from Yahoo Mail on Android 
|  From:"Stephen Farrell" <[e-mail]>
Date:Sat, Apr 25, 2015 at 13:31
Subject:Re: [kitten] AD review of draft-ietf-kitten-sasl-oauth-21

 
I'm sorry but we seem to be talking past one another for both
issues. Let me try another tack but it may also help if someone
else chimes in.


On 25/04/15 19:14, Bill Mills wrote:
> Inline again...
> 
> 
> On Saturday, April 25, 2015 10:47 AM, Stephen Farrell
> <[e-mail]> wrote:
> 
> 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?
> 
> [wmills]  Yes the server might validate for known hostnames, asHTTP
> servers can but it you specify an unknown host in the hostheader it
> falls through to default.  This is specific to the case wherethe
> mechanism supporting OAuth 1.0a requires hostname, so Idon't see how
> this would break some other SASL mechanism?

Let's stick with just IMAP for a moment.

If an IMAP server has to support many server identities then that
has to work for all the SASL mechanisms it supports. That means
that identifying the correct server name has to be done by IMAP,
or, possibly, via TLS, since most SASL mechanisms will not specify
which server identity is in question, or if they do, it is too
late in the overall client-server interaction. Otherwise, something
is broken already in IMAP.

If IMAP is not broken in that way, then I don't see any need for
additional mechanism to support IMAP mutli-tenancy (or whatever
one wants to call it) that has to be provided here, as part of
any of these SASL mechanisms.

And if I'm wrong and there is such a need, (quite possible, I'm
often wrong) then that calls for discussion of the possible
mismatches that may ensue.

Or, if there is some reason to want some special handling for
just these mechanisms (e.g. if the authorization is really for
something else but we want to re-use that for e.g. IMAP), then
that clearly calls for additional security considerations.

> 
> I also don't see any case where the server does not know on which
> port it received data.
> 
> [wmills] at ${previousjob} there were IMAP servers that had a
> TLSaccellerator in front of them and the back end IMAP server lived
> on the same port whether it got a direct connect or a proxied one.Not
> ideal perhaps, but an example.

Not convinced tbh. That's an issue for the weird middlebox isn't
it. Same as passing on possible client cert information.(Wmills) why is this a problem worth arguing? This was done to allow support of Oauth 1 so that all the required info is in the mechanism payload and both sides know exactly what was used to construct the signature.   The server certainly should be making sure that it is valid/correct.

> 
> 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.
> 
> [wmills] OAuth tokens might or might not be bound ot a singledomain
> and certainly cane be used at N hostnames withing a given TLD.
> Where/how tokens might be valid is outside this scope.
> 
> 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.
> 
> [wmills] I completely disagree given that SNI is not pervasive, less
> than 70% of browsers/clients support it last I knew. 

Those are surprising numbers. Do you have a reference?(WMills) this was internal operational data.  Not published anywhere. 
> SNI doesn't
> solve for why OAuth 1.0a uses hostname either.

My point in any case is that this either is not an issue or else
if you do want potential duplication of data sent from client to
server, then you have to account for the security considerations.

>> (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. [wmills] Section 3 defines this per
> mechanism and says: "OAUTHBEARER: OAuth 2.0 bearer tokens, as
> described in [RFC6750].        RFC 6750 uses Transport Layer
> Security (TLS) [RFC5246] to secure the protocol interaction between
> the client and the resource server." This is derived from the
> explicit requirements in the Bearer spec, but there was a problem
> there in that there was an existing Bearer implementation (FB) that
> didn't use TLS and they didn't want to be declared out of spec so I
> think the language isSHOULD instead of MUST.  We were aware of a
> possible mismatch and didn't want be in conflict with the language
> from there. Do we need something clearer than that?  Do we need to
> add something explicit about new mechanisms being required to define
> whether encryption is required?  [/wmills] S.
> 

Sorry, I remain none the wiser. Yes, other RFCs make statements
about support or use of TLS. My point is this draft makes two
different statements on the topic, and says nothing at all in
section 3. The inconsistency is within this single draft in this
case and needs fixing I think.
(wmills) my quote above is from section 3 so I don't get why you say it's silent on this?  TLS is mandatory for Bearer token.  Other mechanisms using this same model have to specify the TLS requirement just like the token definition spec.
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
>> 
>> 
> 
> 
> 
> 
 |

 |


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