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

[Benjamin Kaduk <[e-mail]>]

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