RE: gss userauth

["Joseph Salowey" <jsalowey%cisco.com@localhost>]

Hi Jeff,

Okay, You reminded me of all the reasons why I don't like GSSAPI channel
bindings.  My only issue with MIC is that it might add an extra round
trip. I think that this is outweighed by the fact that MIC would
probably lead to more consistent implementations.  

In any case I agree that we do not want to bind addresses.

Joe

> -----Original Message-----
> From: ietf-ssh-owner%NetBSD.org@localhost 
> [mailto:ietf-ssh-owner%NetBSD.org@localhost] On Behalf Of Jeffrey Hutzelman
> Sent: Friday, August 22, 2003 4:22 PM
> To: ietf-ssh%NetBSD.org@localhost
> Cc: 'Love'
> Subject: RE: gss userauth
> 
> 
> 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
>