Re: GSS-API channel bindings

[Nicolas Williams <[e-mail]>]

On Mon, Jul 05, 2004 at 09:51:09AM +0200, Simon Josefsson wrote:
> 
> There is a requirement that the GSS-API channel bindings are NULL.
> I'd feel more comfortable if there was a way to somehow make use of
> channel bindings, to link the authentication to the specific channel.
> Does anyone have ideas on whether to add this, and if the answer is
> positive, how it might be done?

1.  Existing GSS-API mechanisms fail to correctly deal with channel
    bindings.  E.g., SPKM is way underspaecified in general, and here
    specifically; also, the Kerberos V mechanism does not have a way for
    the acceptor to prove to the initiator that it too has the same
    channel bindings as the initiator.

2.  We're trying to address this through a stackable pseudo-mechanism
    (CCM-BIND) one of whose purposes is to address this problem.  See:

    draft-ietf-nfsv4-ccm-03.txt

3.  The whole subject of channel bindings needs further specification.
    I'm about to submit a new version of

    draft-ietf-nfsv4-channel-bindings (-01.txt)

    that does this and which describes what goes into the channel
    bindings for SSHv2, TLS and IPsec channels, and then I'll submit

    draft-williams-gssapi-channel-bindings-00.txt

    for the KITTEN BoF (and, hopefully, WG), which fills in the details
    of how to use channel bindings to SSHv2, TLS and IPsec channels with
    the GSS-API.  The deadline for filing new I-Ds has passed though, so
    this won't get posted to the I-D repository until after this
    meeting.

4.  Given CCM-BIND and the two other drafts it should be possible to use
    SASL with GSS-API channel bindings; SASL APIs will have to be
    modified so the application can provide the necessary channel
    information.

5.  I have proposed a set of interfaces for determining the features of
    GSS mechs, as part of a framework for stackable pseudo-mechanisms,
    which should help GSS apps avoid having to hardcode mechanism OIDs
    and information about them (e.g., "channel bindings work well with
    this mechanism, but not with that one").

    See:

    draft-williams-gssapi-stackable-pseudo-mechs-00.txt

As you can see, there's a lot of activity around this topic.

> I understand that the simplest "solution", from the SASL mechanism
> point of view, might simply be to consider GSS-API mechanisms, that
> doesn't link gss_wrap/gss_get_mic tokens with one specific
> authentication, as broken.  However, channel bindings are provided by
> GSS-API to enable applications to close this hole, hence these GSS-API
> mechanisms can probably not be viewed as broken in general.  So it is
> unfortunate that the SASL wrapping of GSS-API forbid channel bindings.
> I'd say this warrant a paragraph in the security section, unless the
> text about channel bindings is loosened up.

The SASL handling of GSS-API mechanisms does need some tweaking, both,
in light of the above and to provide for re-keying (GSS-API contexts can
expire, after all) by reestablishing GSS security contexts for the
principals involved.

Cheers,

Nico
--