Re: gss userauth

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

On Tuesday, September 02, 2003 15:13:32 -0700 Nicolas Williams 
<Nicolas.Williams%sun.com@localhost> wrote:

> I find this convincing.

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.

So now, when a new client talks to a new server with compatibility turned 
on, it sees the server advertise both methods.  If a given GSS mechanism 
doesn't work with gssapi-with-mic, it's not going to work with gssapi 
either.  So the client SHOULD NOT even try it, especially since, as Simon 
points out, there may be user interaction involved.

-- Jeff