Re: gss userauth

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

> On Tuesday, September 02, 2003 13:08:30 -0400 "Joel N. Weber II" 
> <ietf-secsh%joelweber.com@localhost> wrote:
>
> > Jeff, could you please comment on what you don't like about my
> > proposal to have a gssapi-mic method that does all of the messages
> > gssapi currently does, followed by sending a mic, and then having a
> > gssapi-keyex method that does a mic using the keyex context?  I've
> > sent two messages suggesting this before, but it's not at all clear
> > that you've acknowleged that I've even proposed this; your reaction to
>
>
> Er, sorry.  Yes, of course I've seen this proposal.  I think Markus is 
> proposing essentially the same thing, and I assume it's the leading 
> alternative to the gssapi-mic we've already discussed and specified (can 
> you please use some other name; having two proposals which use the same 
> method name is confusing).

Might I propose, for the time being, "gssapi-with-mic".

> I'm not convinced that what you describe is actually easier to implement 
> correctly.  It may be easier to do in the openssh server, because it 
> doesn't require filling in whatever support for partial authentication 
> is missing, but openssh is not the only implementation by any means.  
> I'd like to hear from implementors other than you on this question.
>
> I'm also not convinced that it's better than what we already have.  The
> only real improvement seems to be that it doesn't require using partial
> authentication, which Markus finds distasteful.  I've yet to see any
> argument as to _why_ using partial authentication is distasteful.

I originally was in support of the partial auth method... it seemed
like a really elegant solution.

However, after having taken a first pass at implementing it,
I have to say the "gssapi-with-mic" has several advantages:

o In order to implement compatability using "gssapi-mic" the server
  must use out-of-band information to determine whether the client
  can do "gssapi-mic".  I.e., if the client can't do "gssapi-mic",
  the server can't send partial success on the "gssapi" and be
  backwards compatible.

  Using "gssapi-with-mic", the clients sending "gssapi-with-mic" implies
  it can do it.

o Our software is highly modular C++.  With "gssapi-mic", the object
  that implements "gssapi" and the object that implements gssapi key exchange
  must find someplace to put the token.  Previously, we hadn't a much more
  limited form of this problem supporting "external-keyx".

o "gssapi-mic" turned out to be much more complicated to specify than
  I had been thinking.  In particular, specifying which context could
  be used was more complicated.

  Complex specifications are hard to implement correctly.

If we were to go the "gssapi-with-mic" route, I would propose
that we deprecate "gssapi" userauth, and do something like:

  "Integrity MUST be specified as an input to gss_init_sec_context().
  If the resulting context supports integrity, the output of
  gss_getMic on <some data> must be included.  Otherwise the
  "mic" string MUST be empty.

  It is a site policy descision for the server whether or not
  to accept for authentication gss mechanisms that do not
  support integrity.  The server MAY fail the otherwise valid
  gssapi-with-mic authentication if integrity is not supported.

Now we end up with only one authentication method, and it handles
(securely, I believe) both the integrity and the non integrity
cases.

The problem with continuing to support both "gssapi" and
"gssapi-with-mic" is that we are subject to downgrade attacks.
Implementators that choose to support older clients will have
this problem-- but, again, I believe that should be a site
policy decision.  And I think "gssapi-with-mic" may make it
easier to implement this as a site policy.

I'm also one of those looking for a solution quick -- I'm bumping
up against an upcoming ship-date.  So, I'm also in favor of a solution
quickly-- so I'm willing to support "gssapi-mic" if it gets
to a resolution quickly.

Thanks,

- Joseph