Re: gss userauth

[Joseph Galbraith <galb-list%vandyke.com@localhost>]

> 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