Re: gss userauth

[Nicolas Williams <Nicolas.Williams%sun.com@localhost>]

On Fri, Aug 22, 2003 at 07:22:18PM -0400, Jeffrey Hutzelman wrote:
> 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).

Yes and no.  Raw channel bindings would suffice for this purpose, so CCM
is not applicable, but you could have used CCM (if it'd been available
then and you'd really wanted to and you assumed channel bindings support
everywhere).

(CCM has other benefits besides leveraging IPsec HW acceleration, such
 as reducing the number of active crypto contexts needed on NFS file
 servers.  But that's another story.)

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

Yes.  But you can't do this now w/o breaking compatibility and not all
GSS-API implementations, nor all mechanisms, for that matter, support
channel bindings.

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

This MIC can be sent as soon as the context is GSS_C_PROT_READY, on
whichever side it's PROT_READY first.  Though, it may be easiest to fit
it into the last message from the client.

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

Right.

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

We've seen this as a flaw in RFC2743 and the RFC2744/RFC1964 description
has to be the standard.  SPKM, for example, says nothing about how
channel bindings are built, so CCM proposes that the rfc1964
construction be used with CCM.

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

Yep, and yep.

Nico
--