Subject: [kitten] RFC5801bis: relaxing GS2 requirements

From: Simon Josefsson <[email-masked]>
Date: Mon, 03 Mar 2014 14:04:36 +0100

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.

---

From: Nico Williams <[email-masked]>
Date: Thu, 6 Mar 2014 00:10:12 -0600

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

> 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

Agreed.

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

> better hormonization of GSS-API and SASL, and I have struggled to come

I'm in favor of this change.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 11 Mar 2014 21:33:22 -0500

While we're at it, with the OAuth user= / a= issue in mind, I propose
that we add a notion of authzid to the GSS-API via a naming attribute.
 The initiator calls GSS_Set_name_attribute() on a NAME for itself or
the target (doesn't matter which, but we should decide which) to set
an authzid attribute's value.  The mechanism will return an error if
it cannot handle this, per-RFC6680, but if it can handle it, then it
will make it available to the acceptor as an attribute of the
initiator's name, which it can get with GSS_Get_name_attribute().

Then we modify GS2 to say that the a= attribute in the GS2 header may
be left out when a) the GSS mechanism doesn't support channel binding,
and b) accepts the authzid name attribute.

See http://tools.ietf.org/html/draft-williams-kitten-impersonation-naming-attr-00

Nico
--