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

[Benjamin Kaduk <[e-mail]>]

On Tue, 28 Apr 2015, Stephen Farrell wrote:

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

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