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

[Bill Mills <[e-mail]>]

-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 <[e-mail]> 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.>> >>