Re: GSS-API channel bindings

[Nicolas Williams <[e-mail]>]

On Thu, Jul 29, 2004 at 08:21:00PM +0100, Alexey Melnikov wrote:
> 
> Simon Josefsson wrote:
> 
> >Do you have any thoughts on how to modify the SASL GSSAPI mechanism so
> >it is possible for it to use non-NULL channel bindings automatically?
> >
> >The most simplistic solution is to permit non-NULL channel bindings in
> >the specification, and leave everything up to application protocols.
> >
> >However, that approach require application protocol implementations to
> >tell the SASL library what GSSAPI channel bindings it wants.  While
> >this is feasible, perhaps it can be made even better.
> >
> >What I'm trying to understand, is whether the SASL GSSAPI mechanism,
> >by itself, could construct the actual channel binding, and use it at
> >both ends.
> >
> CMU SASL API allows applications to pass IP/port number of the both 
> endpoints to the SASL library. It seems that this is sufficient to 
> construct proper channel binding information? (Just thinking aloud).

No, it's not enough because there's no cryptographic binding there,
direct or indirect.

Throw in authenticated and "latched" IPsec IDs and you've got strong
bindings.

Or, if you're running over a TLS channel, throw in the TLS finished
messages.  Or, if you're running over an SSHv2 channel, throw in the
SSHv2 session ID.

> Also, if either the client or the server end uses non null channel 
> binding and the other end doesn't, will they be able to authenticate?

With the GSS-API?  Technically they shouldn't, though the krb5 mech has
some warts in this area (I won't describe them here).

The point is: GSS-API channel bindings are not negotiated by the GSS
mechanisms, so both peers must know a priori that both have or don't
have channel bindings.  Thus my comments earlier about CCM-BIND and
negotiation of the use of GSS mechanisms specifically designed to signal
and implement the use of channel bindings.

Please see draft-ietf-nfsv4-channel-bindings-02.txt.

Nico
--