[kitten] RFC5801bis: relaxing GS2 requirements

[Simon Josefsson <[e-mail]>]

All,

I've prepared a new version of RFC 5801 to get the GS2bis ball rolling.

http://tools.ietf.org/html/draft-josefsson-kitten-gs2bis-00

So what's the reason for doing that?

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.

This problem came up when RFC 6595 and RFC 6616 was prepared, and as a
resolution those documents contained text on how to resolve the issue --
see the paragraph that starts with "The mutual..." in
<http://tools.ietf.org/html/rfc6595#section-4>.  But the problem is
really with GS2, so the fix should go into GS2.

To review the differences between RFC 5801 and GS2bis, I've published a
HTML side-by-side diff:

http://josefsson.org/sasl-gs2/draft-josefsson-kitten-gs2bis-from-rfc5801.diff.html

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

For simpler commenting on the actual new material, I'm including the new
section below.

Feedback, suggestions, co-authors, etc, all very appreciated.

Thanks,
/Simon

6.  When the mechanism does not support channel binding and/or mutual
    authentication

   Some authentication mechanisms does not offer mutual authentication
   or is unable to provide channel bindings.  This is unfortunate, and
   usually suggests that the authentication mechanism offers limited
   authentication functionality.  However there are situations when the
   lack of this functionality can be mitigated with other protection
   mechanisms, leading to acceptable overall security.  Being able to
   define and use an authentication mechanism as a GSS-API mechanism and
   then use that GSS-API mechanism in the SASL environment using GS2 has
   advantages; for example, being able to re-use existing generic GS2
   implementations.  Further, being able to express all mechanisms that
   can be expressed as a GSS-API mechanisms as a SASL mechanism (and
   vice versa) provides design elegance and framework replacability.
   Therefor, this document relaxes the requirement that the GSS-API
   mechanism support channel bindings and/or mutual authentication.
   Implementing and deploying applications that supports those mechanism
   require some consideration, and this section discuss the relevant
   areas.

   For the discussion it helps to understand what happens with the GS2
   bridge when a GSS-API mechanism does not offer channel bindings or
   mutual authentication.  When channel bindings is not supported by the
   underlying mechanism, GS2 cannot protect its data (essentially: the
   channel binding flag and the SASL authorization identity).  This
   means that the security of the channel binding mode breaks down and
   that the other side cannot trust the SASL authorization identity.
   When mutual authentication is not happening, the client cannot know
   that it sends its data to the intended server.

   It is acceptable to use these mechanisms with GS2 in some situations.
   For example, if the client uses TLS against a server, and the client
   verify the server's certificate properly so that server
   authentication has occured, then authenticating the client to the
   server using a "weak" GSS-API mechanism will technically work.  The
   security properties will not be as good as they would have been if
   the underlying mechanism supported channel binding or mutual
   authentication, however they become as good as possible.

   This document relaxes the requirements on GSS-API mechanism so that
   all GSS-API mechanism can be expressed in GS2.  For these mechanisms,
   the "gs2-cb-flag" value MUST always be "n", and the PLUS-variant of
   the GS2 mechanism name MUST NOT be advertised or negotiated.

   The SAML SASL bridge [RFC6595] and the SAML OpenID bridge [RFC6616]
   are two examples of documents that describe such bridges.  These
   documents did not meet the requirements of the original GS2 bridge,
   but with the update in this document they are conformant.  Note that
   both documents had discussions describing this aspect and sufficient
   requirements for safe implementation and deployment.