Re: [kitten] RFC5801bis: relaxing GS2 requirements

[Nico Williams <[e-mail]>]

On Mon, Mar 3, 2014 at 7:04 AM, Simon Josefsson <[e-mail]> wrote:
> I've prepared a new version of RFC 5801 to get the GS2bis ball rolling.

Thank you, and thanks for posting the diff URL, it made it very easy
to review your changes.

I'm very much in favor of this revision.  I have only agreement and
nits to contribute (spelling and number agreement corrections).

> The problem is that RFC 6595 (SAML), RFC 6616 (OpenID) and the OAuth
> SASL mechanism does not really meet the GS2 requirements: in particular,
> they don't offer channel bindings or mutual authentication.  Or more
> generically stated, the problem was that we hoped that all future
> authentication mechanisms would provide channel binding and mutual
> authentication, and as a result GS2 was too narrowly defined.

Yes, we had so hoped.  As a result we made GS2's scope too narrow indeed.

> [...]  But the problem is
> really with GS2, so the fix should go into GS2.

Agreed.

> As you can see, I've only added one section describing the problem and
> some new MUST wording.  Clearly, this is not sufficient, and other
> sections must be modified, in particular the security considerations.

Indeed.  For example, we must say that a client that could pick a
-PLUS offered by a server SHOULD take it, no?  And/or we should
explain that it should only take a non-PLUS GS2 mechanism (or non-GS2
mechanism with similar properties) when TLS (or similar) was used to
authenticate the server to the client's satisfaction.

I don't think there's much we can do to characterize the security of
using a mechanism with channel binding and mutual authentication
versus TLS and a mechanism that does not provide mutual auth and/or
channel binding.  To do more than hand-wave we'd have to get into the
specifics of the mechanism and the TLS server authentication
functionality and PKI and so on.  All we should say is that if the
client doesn't use a -PLUS mechanism with channel binding then it must
have used TLS with a ciphersuite that authenticates the server to the
client, and that it must do so to the client's satisfaction, whatever
that might mean.

> Before doing that, I think it would be good to get the WG to think about
> this issue and see that the overall idea is acceptable.  I can't say
> that I like the text, but I think it is a compromise that will result in
> better hormonization of GSS-API and SASL, and I have struggled to come
> up with anything better.

I'm in favor of this change.

Nico
--