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

From: Stephen Farrell <[email-masked]>
Date: Sat, 25 Apr 2015 15:05:49 +0100

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?

(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:-)

nitty nits:

- ID nits gets a few reference things wrong, but it's ok

- 3.1 (and elsewhere probably) I'm assuming the ABNF
has been cross-checked, is that a safe assumption?

- 3.1 kvsep with a value of 0x01 - is that commonly used?
But it might be quite common for all I know:-)

- 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?

- Section 4, I also assume the examples have been checked.
(Good set of examples though.)

Cheers,
Stephen.

---

From: Bill Mills <[email-masked]>
Date: Sat, 25 Apr 2015 17:25:10 +0000 (UTC)

Responses inline...

On Saturday, April 25, 2015 7:06 AM, Stephen Farrell <[email-masked]> wrote:

Hiya,

My questions:

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. 

[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:

[wmills] happy to fix them if needed.  Will RFC Ed. do it anyway?

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

[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
[email-masked]
https://www.ietf.org/mailman/listinfo/kitten

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 25 Apr 2015 18:47:07 +0100

Hiya,

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

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

---

From: Bill Mills <[email-masked]>
Date: Sat, 25 Apr 2015 18:14:49 +0000 (UTC)

Inline again... 

     On Saturday, April 25, 2015 10:47 AM, Stephen Farrell <[email-masked]> wrote:
   
Hiya,

[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?

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

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

[wmills] I completely disagree given that SNI is not pervasive, less than 70% of browsers/clients support it last I knew.  SNI doesn't solve for why OAuth 1.0a uses hostname either.

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.

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 25 Apr 2015 21:31:33 +0100

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

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

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

S.

>> - 3.1 (and elsewhere probably) I'm assuming the ABNF has been
>> cross-checked, is that a safe assumption?
>> 
>> 
>> 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 
>> [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.
>> 
>> 
>> [wmills] Ben did make me fix several as iteration happened so they
>> have had at least one review..
>> 
>> 
>> Cheers, Stephen.
>> 
>> _______________________________________________ Kitten mailing
>> list [email-masked] https://www.ietf.org/mailman/listinfo/kitten
>> 
>> 
> 
> 
> 
>

---

From: Bill Mills <[email-masked]>
Date: Sat, 25 Apr 2015 15:28:17 -0700

Sent from Yahoo Mail on Android

From:"Stephen Farrell" <[email-masked]>
Date:Sat, Apr 25, 2015 at 13:31
Subject:Re: [kitten] AD review of draft-ietf-kitten-sasl-oauth-21

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

(WMills) this was internal operational data.  Not published anywhere. 

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

---

From: Bill Mills <[email-masked]>
Date: Mon, 27 Apr 2015 03:37:32 +0000 (UTC)

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 <[email-masked]> wrote:

| 

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

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.

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

>> list [email-masked] https://www.ietf.org/mailman/listinfo/kitten
 |

 |

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 27 Apr 2015 18:23:06 -0400 (EDT)

> issues. Let me try another tack but it may also help if someone

[puts on shepherd hat]
Sorry for the long silence; I was sick last week and didn't get much
of anything done.

Question (1) is about the host and port kvpairs of the initial client
response; Stephen claims that any server software using this SASL
mechanism will know what hostname and port the client is trying to access.
It seems like this is in fact true, but Bill says there is no API for a
SASL mechanism implementation to query this from up the stack (and would
require patching the core SASL implementation, not just a mechanism
implementation).  The natural question to ask, then, is if other SASL
mechanisms are verifying a client-supplied hostname, and if so, how.  In
Kerberos the desired service principal name includes a hostname, and can
be determined by examining the sname field of the presented Ticket.  In
practice, kerberized application servers are generally configured to
either use one specific service principal name, or any for which keys can
be found [optionally, of the given service type].  So, the hostname used
by the client can be determined just from the authentication blob, without
a need to consult the SASL stack.  If other mechanisms are similar to
kerberos, than I guess it makes sense to explicitly include the target
hostname in the initial client response, as is currently done.  This seems
to be the only relevant part of the discussion; I don't think that OAuth
tokens valid for multiple servers are particularly interesting for
answering this question.

Additionally, the SASL application server certainly knows what port it is
receiving traffic on.  But, as Bill notes, if there is a load-balancer or
TLS terminator in between, the port the server is listening on can differ
from the port that the client sent to.  My understanding is that it is not
terribly common for authentication/authorization schemes to be
port-restricted, so it is plausible that the SASL mechanisms currently in
use in such scenarios do not use a port number and thus can succeed
unchanged, whereas OAuth 1.0a does bind to the port number and needs an
explicit hint.

In both cases (hostname and port), my tentative conclusion is that no
change to the draft is needed.

Question (2) relates to the use of TLS.  This document is in a somewhat
awkward position of specifying both a specific (pair of) mechanisms and a
(hopefully) general framework for converting HTTP OAuth mechanisms into
SASL mechanisms.  For all currently specified OAuth (2.0) mechanisms, TLS
is required to protect the bearer token, but we hope that future OAuth
mechanisms can be specified which do not use bearer tokens and thus have a
weaker dependency on TLS.  In particular, we hope that such future OAuth
HTTP mechanisms can be converted to SASL mechanisms using the framework
specified in this document.

So, while TLS MUST be used for the concrete mechanisms this document
specifies [1], there is not a very strong case to say that TLS MUST be
used for all mechanisms compliant to this framework.  This framework for
SASL mechanisms does not provide any security layer for data security, so
if confidentiality of data is required, TLS ought to be used.  But I'm not
sure that's even a SHOULD, let alone a MUST.

I concede Stephen's point that section 3 should say *something* about TLS,
and propose moving (or copying?) text from the security considerations
relating to the two specific mechanisms (MUST for OAUTHBEARER; RECOMMENDED
for OAUTH10A), along with some text giving guidance for future mechanisms
using this framework.  It's not clear to me that sections 4 and 5 are
internally inconsistent, though -- unless the difference between "TLS MUST
be used" and "TLS must be provided" is the concern?

To suggest some concrete text, insert into section 3, after the paragraph
"New extensions may be defined [...] citing this specification for the
further definition.":

%%%%%%%%%%%%%%%%%%%%%%%%

SASL mechanisms using this document as their definition do not provide
a data security layer; that is, they cannot provide integrity or
confidentiality protection for application messages after the initial
authentication.  If such protection is needed, TLS or some similar
solution should be used.  Additionally, for the two mechanisms specified
in this document, TLS MUST be used for OAUTHBEARER to protect the bearer
token; for OAUTH10A the use of TLS is RECOMMENDED.

%%%%%%%%%%%%%%%%%%%%%%%%

The start of the next paragraph could probably also benefit from new
transition text, such as "Mechanisms using this document as a definition
are client initiated [...]".

With respect to the nits:

I only see one valid entry in the idnits output about the references;
draft-ietf-oauth-dyn-reg has had a new version come out in the interim.
It also claims that RFC 5849 (OAuth 1) is obsolete, but we do need to
reference it for the OAUTH10A mechanism.  (I thought I said that in the
shepherd report....)

Alexey looked at an old version of the ABNF and we had to make a couple
tweaks, but I think it's okay, now.

Bill talked about the kvsep of 0x01, so I will say no more.

I think Bill also covered the privacy aspects of (not) including the
authzid as well.

I did some checking of the examples, but they should ideally be checked
again at some point.  (I will probably do it during IETF last call.)
There were several points in time where the examples were internally
inconsistent, so it would be good to make sure that we've stamped those
out.

-Ben

[1] I'm ignoring OAuth 1.0a for this point.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 28 Apr 2015 15:48:59 +0100

Hi Ben, Bill,

(Sorry for the slow response, got distracted yesterday;-)

On 27/04/15 23:23, Benjamin Kaduk wrote:
> It seems like this is in fact true, 

Right. And that means we're duplicating that information. And such
duplication, when the value are not the same, is a time-honoured way
of getting around authorization systems that forget that there are
two copies and who only check one. If you want to keep the duplication
then I think you have to note that.

> but Bill says there is no API for a
> be found [optionally, of the given service type].  

That could be a valid choice, but ought be clear to whoever
is issuing the tickets, (or tokens here) right?

> So, the hostname used

If keeping it, I think you need the warning about duplication. I'm
guessing that that warning won't ever be in other RFCs, as
applications presumably don't need to say which SASL mechanisms are
allowed.

(I wonder if this is just one example of where the first sentence
of 3.2 doesn't have sufficient detail?)

> "New extensions may be defined [...] citing this specification for the

I'd be fine with that change.

S.

---

From: Bill Mills <[email-masked]>
Date: Tue, 28 Apr 2015 15:48:45 +0000 (UTC)

-22 up on Github with the noted changes from below.  
https://github.com/sweetums/idrafts/commit/4f38fc40cf45784f23667c1d792122af572ba779

On Tuesday, April 28, 2015 7:48 AM, Stephen Farrell <[email-masked]> wrote:
>Hi Ben, Bill,>>(Sorry for the slow response, got distracted yesterday;-)>>On 27/04/15 23:23, Benjamin Kaduk wrote:>> On Sat, 25 Apr 2015, Stephen Farrell wrote:>> >>>>>> 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.>> >> [puts on shepherd hat]>> Sorry for the long silence; I was sick last week and didn't get much>> of anything done.>> >> Question (1) is about the host and port kvpairs of the initial client>> response; Stephen claims that any server software using this SASL>> mechanism will know what hostname and port the client is trying to access.>> It seems like this is in fact true, >>Right. And that means we're duplicating that information. And such>duplication, when the value are not the same, is a time-honoured way>of getting around authorization systems that forget that there are>two copies and who only check one. If you want to keep the duplication>then I think you have to note that.
Again I disagree, this is *exactly* the same problem the HTTP host headersolves.  IMAP does not have anything that conveys hostname.  Port number might be known but hostname is not guaranteed. Added "The server SHOULD validate that the host and port values match the expected values for the service." to the end of the paragraph discussing signature base strings where host and port are defined in 3.
>>> but Bill says there is no API for a>> SASL mechanism implementation to query this from up the stack (and would>> require patching the core SASL implementation, not just a mechanism>> implementation).  The natural question to ask, then, is if other SASL>> mechanisms are verifying a client-supplied hostname, and if so, how.  In>> Kerberos the desired service principal name includes a hostname, and can>> be determined by examining the sname field of the presented Ticket.  In>> practice, kerberized application servers are generally configured to>> either use one specific service principal name, or any for which keys can>> be found [optionally, of the given service type].  >>That could be a valid choice, but ought be clear to whoever>is issuing the tickets, (or tokens here) right?
No.  The example is Google's OAuth implementation that uses the same tokenfor both SMTP and IMAP.  Same ticket, different hostnames. 
>>> So, the hostname used>> by the client can be determined just from the authentication blob, without>> a need to consult the SASL stack.  If other mechanisms are similar to>> kerberos, than I guess it makes sense to explicitly include the target>> hostname in the initial client response, as is currently done.  This seems>> to be the only relevant part of the discussion; I don't think that OAuth>> tokens valid for multiple servers are particularly interesting for>> answering this question.>> >> Additionally, the SASL application server certainly knows what port it is>> receiving traffic on.  But, as Bill notes, if there is a load-balancer or>> TLS terminator in between, the port the server is listening on can differ>> from the port that the client sent to.  My understanding is that it is not>> terribly common for authentication/authorization schemes to be>> port-restricted, so it is plausible that the SASL mechanisms currently in>> use in such scenarios do not use a port number and thus can succeed>> unchanged, whereas OAuth 1.0a does bind to the port number and needs an>> explicit hint.>> >> In both cases (hostname and port), my tentative conclusion is that no>> change to the draft is needed.>>If keeping it, I think you need the warning about duplication. I'm>guessing that that warning won't ever be in other RFCs, as>applications presumably don't need to say which SASL mechanisms are>allowed.>>(I wonder if this is just one example of where the first sentence>of 3.2 doesn't have sufficient detail?)>>> >> >> Question (2) relates to the use of TLS.  This document is in a somewhat>> awkward position of specifying both a specific (pair of) mechanisms and a>> (hopefully) general framework for converting HTTP OAuth mechanisms into>> SASL mechanisms.  For all currently specified OAuth (2.0) mechanisms, TLS>> is required to protect the bearer token, but we hope that future OAuth>> mechanisms can be specified which do not use bearer tokens and thus have a>> weaker dependency on TLS.  In particular, we hope that such future OAuth>> HTTP mechanisms can be converted to SASL mechanisms using the framework>> specified in this document.>> >> So, while TLS MUST be used for the concrete mechanisms this document>> specifies [1], there is not a very strong case to say that TLS MUST be>> used for all mechanisms compliant to this framework.  This framework for>> SASL mechanisms does not provide any security layer for data security, so>> if confidentiality of data is required, TLS ought to be used.  But I'm not>> sure that's even a SHOULD, let alone a MUST.>> >> I concede Stephen's point that section 3 should say *something* about TLS,>> and propose moving (or copying?) text from the security considerations>> relating to the two specific mechanisms (MUST for OAUTHBEARER; RECOMMENDED>> for OAUTH10A), along with some text giving guidance for future mechanisms>> using this framework.  It's not clear to me that sections 4 and 5 are>> internally inconsistent, though -- unless the difference between "TLS MUST>> be used" and "TLS must be provided" is the concern?>> >> To suggest some concrete text, insert into section 3, after the paragraph>> "New extensions may be defined [...] citing this specification for the>> further definition.":>> >> %%%%%%%%%%%%%%%%%%%%%%%%>> >> SASL mechanisms using this document as their definition do not provide>> a data security layer; that is, they cannot provide integrity or>> confidentiality protection for application messages after the initial>> authentication.  If such protection is needed, TLS or some similar>> solution should be used.  Additionally, for the two mechanisms specified>> in this document, TLS MUST be used for OAUTHBEARER to protect the bearer>> token; for OAUTH10A the use of TLS is RECOMMENDED.>>I'd be fine with that change.>
This duplicates text from the definition of OAUTHBEARER above, but if it makes you happy it's in.
>S.>>> >> %%%%%%%%%%%%%%%%%%%%%%%%>> >> The start of the next paragraph could probably also benefit from new>> transition text, such as "Mechanisms using this document as a definition>> are client initiated [...]".>> >> >> >> With respect to the nits:>> >> I only see one valid entry in the idnits output about the references;>> draft-ietf-oauth-dyn-reg has had a new version come out in the interim.>> It also claims that RFC 5849 (OAuth 1) is obsolete, but we do need to>> reference it for the OAUTH10A mechanism.  (I thought I said that in the>> shepherd report....)>> >> Alexey looked at an old version of the ABNF and we had to make a couple>> tweaks, but I think it's okay, now.>> >> Bill talked about the kvsep of 0x01, so I will say no more.>> >> I think Bill also covered the privacy aspects of (not) including the>> authzid as well.>> >> I did some checking of the examples, but they should ideally be checked>> again at some point.  (I will probably do it during IETF last call.)>> There were several points in time where the examples were internally>> inconsistent, so it would be good to make sure that we've stamped those>> out.>> >> -Ben>> >> [1] I'm ignoring OAuth 1.0a for this point.>> >>

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 28 Apr 2015 17:47:27 +0100

On 28/04/15 16:48, Bill Mills wrote:
> Again I disagree, this is *exactly* the same problem the HTTP host
> header solves.  

The Host header field solves that problem for HTTP, but creates a
problem for an authorization subsystem - if one piece of server
side code checks an action the client wants to do vs. the Host
header field and another makes that check vs. the new field that
we're defining here then that opens a hole. And that error has
been seen many times, so I don't believe you can just do a plug
and play thing here safely, in general.

> IMAP does not have anything that conveys hostname.
> Port number might be known but hostname is not guaranteed. Added "The
> server SHOULD validate that the host and port values match the
> expected values for the service." to the end of the paragraph
> discussing signature base strings where host and port are defined in
> 3.

I've no problem if you add the above but what I'm asking for is
more like: "The server MUST validate that the host and port values
defined here match any other application protocol data units or
configured values that carry the same information. The details of
how to do that match are application-specific and so cannot defined
here, but implementers integrating these SASL mechanisms with
applications need to ensure that such checks are made, where they
are needed."

Cheers,
S.

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 29 Apr 2015 15:43:01 -0400 (EDT)

> applications need to ensure that such checks are made, where they

In any case, I think the text about validation should be in section 3.2,
not section 3.1 where "[t]he server SHOULD validate that the host and port
values match the expected values for the service" was added for the
version on github.  Section 3.2 is where server validation is discussed,
in the first sentence that Stephen thinks is incomplete.  I think we could
combine expanding that sentence with discussion of validating the supplied
hostname and port.

My strawman text:

%%%%%%%%%%%%%%%%%%%%%%%%%

The server fully validates the client response before generating a server
response; this will necessarily include the validation steps listed in the
specification for the OAuth Access Token Type used.  However, additional
validation steps may be needed, depending on the particular application
protocol making use of SASL.  In particular, values included as kvpairs in
the client response (such as host and port) which correspond to values
known to the application by some other mechanism (such as an application
protocol data unit or pre-configured values) MUST be validated to match
between the initial client response and the the other source(s) of such
information.  As a concrete example, when SASL is used over TLS, the
hostname can be available via the Server Name Indication TLS extension;
this hostname must be validated to match the value sent in the 'host'
kvpair.

%%%%%%%%%%%%%%%%%%%%%%%%%

-Ben

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 29 Apr 2015 22:05:25 +0100

> this hostname must be validated to match the value sent in the 'host'

Yep, that'd work I think.

S.

---

From: Bill Mills <[email-masked]>
Date: Wed, 29 Apr 2015 14:38:11 -0700

Everything up to the concrete example works for me.  The example is vaporware, I'd rather use a concrete one or leave it out.

From:"Stephen Farrell" <[email-masked]>
Date:Wed, Apr 29, 2015 at 14:05
Subject:Re: [kitten] AD review of draft-ietf-kitten-sasl-oauth-21

S.

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 30 Apr 2015 10:39:47 -0400 (EDT)

On Wed, 29 Apr 2015, Bill Mills wrote:

> Everything up to the concrete example works for me.  The example is
> vaporware, I'd rather use a concrete one or leave it out.

I think the SNI example is a concrete example, in that it is very clear
which values are to be compared.  The fact that it is not a comparison
which is performed by any extant software is a different issue.

To continue along those lines, we frequently publish specifications that
have not been (fully) implemented; I see our duty as to publish documents
that say what should be done for correct and secure (inter)operation.  I
recognize that not all checks are always implemeted everywhere, but that
does not free us of our obligation to write documents containing all the
security checks that we believe are relevant.  So, I believe that this
text is useful and correct, and do not see merit in the objection raised
thus far.

However, I am not particularly tied to this particular example, and if you
still wish to replace it with a different example (such as the one Stephen
mentioned off-list, of an IMAP server configured only to serve example.com
that should reject client response claiming to be for example.net), I can
accept that for the goal of moving the document forward.

-Ben

---

From: Bill Mills <[email-masked]>
Date: Thu, 30 Apr 2015 15:50:09 +0000 (UTC)

I prefer the IMAP example because it ties in to the rest of the doc cleanly.  I'll update it that way and get copy out today.  

     On Thursday, April 30, 2015 7:39 AM, Benjamin Kaduk <[email-masked]> wrote:

-Ben

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 30 Apr 2015 16:55:51 +0100

> I prefer the IMAP example because it ties in to the rest of the doc cleanly.  I'll update it that way and get copy out today.  

Great. I'll start the IETF LC as soon as I see that.
(And in case anyone has an issue with that, they can
of course raise such as a LC comment and we'll deal
with it.)

Thanks,
S.

---

From: Bill Mills <[email-masked]>
Date: Thu, 30 Apr 2015 17:53:13 +0000 (UTC)

posted 

     On Thursday, April 30, 2015 8:55 AM, Stephen Farrell <[email-masked]> wrote:

Thanks,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 30 Apr 2015 18:57:13 +0100

> posted 

... and LC requested now.

Cheers,
S