RE: gss userauth

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

I agree with Joseph on this, I think 'gssapi' should be deprecated and
its use discouraged except for a transitional period.  Servers need to
have the capability to remove 'gssapi' from the list when
'gssapi-with-mic' is implemented.



> -----Original Message-----
> From: ietf-ssh-owner%NetBSD.org@localhost 
> [mailto:ietf-ssh-owner%NetBSD.org@localhost] On Behalf Of Joseph Galbraith
> Sent: Tuesday, September 02, 2003 5:46 PM
> To: Jeffrey Hutzelman
> Cc: Nicolas Williams; Markus Friedl; Joel N. Weber II; Love 
> Hörnquist Åstrand; ietf-ssh%NetBSD.org@localhost; jhutz+%cmu.edu@localhost
> Subject: Re: gss userauth
> 
> 
> > I think I do, too.  However, I think if we do this, we need to
> > effectively deprecate "gssapi" and make sure that we can use 
> > "gssapi-with-mic" even with contexts that can't support 
> integrity, as 
> > Joseph described.  Otherwise you run into the negotiation 
> problem that 
> > Simon mentioned, where you might try the same mechanism twice.
> > 
> > Now, the question is, who should advertise what?
> > 
> > If a new server wants to insist on a MIC when possible, it should
> > advertise only gssapi-with-mic, which makes the client's 
> decision easy.
> > 
> > If it wants to support authentication without a MIC, then you may as
> > well always use gssapi, in which case the server could choose to 
> > advertise only that method (as older servers will).
> > 
> > Unfortunately, that creates a problem.  There is an 
> unavoidable lack 
> > of
> > interoperability between an older implementation which 
> doesn't support 
> > gssapi-with-mic and a newer one which chooses (through site 
> policy or 
> > implementor choice) not to support gssapi.  But we don't 
> want to break 
> > interoperability between new clients which choose not to 
> support gssapi 
> > and new servers which happen to be operating in 
> compatibility mode.  So 
> > a server running in compatibility mode MUST also advertise 
> gssapi-mic, 
> > so it will work with new clients.
> 
> Precisely.  I believe a new server should alway
> advertise gssapi-with-mic.  If it wishes to offer
> backwards compatibility, then it MAY advertise
> the older "gssapi".
> 
> However, I'm not even sure we need to document "gssapi"
> in the new draft, other than to say it once existed,
> and SHOULD NOT be used anymore.  I.e., reserve the name
> string as unused.
> 
> New clients that choose to support both "gssapi" and 
> "gssapi-with-mic" will need to be smart enough to prefer 
> "gssapi-with-mic"  The server, of course, should probably 
> remove "gssapi" from the method list once "gssapi-with-mic" 
> has been completed-- but I'm not even sure this is strictly necessary.
> 
> - Joseph
>