Re: gss userauth

["Joel N. Weber II" <ietf-secsh%joelweber.com@localhost>]

> Eliminating the non-mic version means eliminating any support for GSSAPI
> mechanisms which are unable to provide integrity protection for
> application messages (i.e. gss_GetMIC).  I think we already decided much
> earlier in the development of this specification that we didn't want to do
> that; are you suggesting we revisit that decision?
>
> Also, inventing a new method doesn't eliminate the need for something like
> gssapi-mic to be used in conjunction with GSSAPI-based key exchange.  Why
> solve the same problem twice?

Jeff, I think I sent mail to this list last week suggesting that we
could leave the gssapi mechanism exactly the way it is for the
theoretical gssapi mechanisms that don't support integrity, and create
a new mechanism called gssapi-mic which does both context
establishment and a mic, and then create another mechanism called
gssapi-keyex which does a mic over the context established during
keyex.

I think that would address all of your concerns except perhaps the one
of ``solving the same problem twice'', but I think that's really a red
herring; you can have a set of message definitions and then a list of
which message types are used with which userauth methods.

And while I had claimed last week to have implemented the partial
userauth approach last week and found it to not have significant
complexity, that was before I'd seen the mail you'd sent off the list
yesterday saying that the partial authentication flag needs to be set
by the server, and interpreted by the client; I simply had gssapi
always returning failure without any partial success.

I'm concerned about the complexity that would be required to add the
partial success flag as you seem to be planning to specify it; the
obvious ways of dealing with it that I can think of involve adding
another member to the structure that defines an authentication method,
which involves changes to the code that calls the authentication
methods, as well as potentially requiring minor changes to each
non-gssapi authentication method to deal with initialization.

Your proposal also has a bunch of new rules about when you can try
which authentication method.  If you go with my proposal of having a
gssapi-mic method that does both context establishment and a mic, and
a gssapi-keyex method that does just a mic, I believe the only thing
you have to worry about at all wrt choosing which method to run when
to add gssapi to an existing implementation is that you need to make
sure that gssapi-keyex is fairly early in the list.

And I really don't see what you buy by requiring that complexity that
you're advocating.

I'd really like to see something that can easily be implemented
without modifying the API that authentication methods use.

We have two openssh maintainers opposed to the partial authentication
approach.  And I have a preference against the partial authentication
method; I've been working on an implementation of the gssapi-mic
authentication method, and I've also written a patch for gnupg support
of significant size.

How much code for an ssh implementation have the partial
authentication advocates written?