RE: gss userauth

[Jeffrey Hutzelman <jhutz%cmu.edu@localhost>]

On Friday, August 22, 2003 14:41:38 -0700 Joseph Salowey 
<jsalowey%cisco.com@localhost> wrote:

> I'm in favor of using channel bindings for this purpose.
>
> CCM could be one approach to do this.
> http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-ccm-01.txt
>
> At first glance it seems a little complex, but I need to actaully read
> the spec.

CCM actually isn't what we want.  It's a way of taking an app that uses 
GSSAPI's integrity and/or encryption features, and a mechanism that 
provides them, and essentially ripping out the mechanism's authentication 
and encryption and replacing them with that provided by some lower-layer 
protocol such as IPsec, on the theory that hardware acceleration is more 
likely to be available there.  We don't need that functionality -- we don't 
ever use GSSAPI encryption features, and we currently send exactly one 
integrity-protected message (during key exchange).

What we need is a way to bind user authentication to our application 
protocol's existing cryptographic context, not to some lower-layer 
protocol.  We don't need a special GSS mechanism for that -- all we need to 
to require the client to send an integrity-protected copy (or checksum) of 
the exchange hash, just as we do in other user auth mechanisms, and as we 
do in the reverse direction during key exchange.

I can think of two ways of doing this:
(1) Use GSSAPI channel bindings.  Unfortunately, some mechanisms require 
bindings to take a particular format, as described in RFC2744 section 3.11. 
In our case, we would want to use address types of GSS_C_AF_NULLADDR, since 
we very much do _not_ want to bind this authentication to network protocol 
addresses (that would gain nothing, and make it not work through NAT's). 
We could then include the session ID as "application data".

(2) Add an additional step in which the client is required to send a MIC of 
the session ID before authentication can succeed.  This is essentially the 
same as what we do in key exchange, but in the reverse direction.

I find myself preferring option (2) for several reasons:
- By my reading, RFC2743 does not appear to actually require that GSSAPI 
mechanisms _do_ anything with channel bindings.  A mechanism could just 
choose to ignore them.
- RFC2743 _does_ allow mechanisms to require bindings to take a particular, 
mechanism-dependent form.  It does not specify what the behaviour might be 
if the provided bindings are not in a format acceptable to the mechanism.
- Some mechanism might be unable or unwilling to provide integrity 
protection for channel bindings, and there is no way for them to signal 
this to the application.  While it may be the case that a mechanism cannot 
support gss_get_mic, at least there is a flag to indicate that, and we can 
write appropriate requirements.
- Using a separate message means we can maintain some amount of backward 
compatibility for sites that have already deployed earlier versions of this 
draft.  Particularly, it allows for situations in which the client 
implements the new message, but the server does not.

-- Jeff