Subject: Re: gss userauth

From: Markus Friedl <[email-masked]>
Date: Mon, 1 Sep 2003 11:26:20 +0200

On Tue, Aug 26, 2003 at 11:42:52PM -0400, Joel N. Weber II wrote:
> I dislike the partial authentication approach.  I believe it adds
> significant complexity to an implementation.

I agree, not only because of the implementation complexity.

I don't see a reason why this sould be considered a
'partial authentication'.  Why not treat this as two
different methods and phase out the non-mic version
instead of keeping the less secure version around forever?

---

From: Damien Miller <[email-masked]>
Date: Tue, 02 Sep 2003 12:05:38 +1000

> instead of keeping the less secure version around forever?

Agreed. Abusing partial authentication to fix up a shortcoming in an 
draft auth method is a kludge to fix a mistake, no other auth method 
does (or should) work that way. I agree with Markus' suggested solution too.

-d

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 1 Sep 2003 23:50:16 -0400 (EDT)

> instead of keeping the less secure version around forever?

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?

-- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA

---

From: Markus Friedl <[email-masked]>
Date: Tue, 2 Sep 2003 11:18:35 +0200

On Mon, Sep 01, 2003 at 11:50:16PM -0400, Jeffrey Hutzelman wrote:
> application messages (i.e. gss_GetMIC).

why not negotiate the 'mic' capatibility within the user
authentication method instead of requiring chained methods?

e.g. have the server side insist on the mic message for
GSSAPI mechanims supporting.

> I think we already decided much

i don't know the use of an authentication mechanism without
integrity protection.

---

From: "Joel N. Weber II" <[email-masked]>
Date: Tue, 02 Sep 2003 06:58:02 -0400

> 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?

---

From: Markus Friedl <[email-masked]>
Date: Tue, 2 Sep 2003 13:28:00 +0200

> authentication advocates written?

Simon's code for the partial authentication version is not very
large.  However, I don't like the approach of having a 'chain' of
userauth methods for 'gssapi-mic'.

The same reasoning could be used for a challenge-response based
authentication method:  just add a method for sending a challenge
together with 'partial success' and use the existing password method
for response verification.

-m

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 2 Sep 2003 11:41:23 -0400 (EDT)

> authentication method instead of requiring chained methods?

I had a proposal for doing that, but it was pointed out to me by a couple
of people that relying on a server sending SSH_MSG_UNIMPLEMENTED when it
gets a message it doesn't understand is not safe, since some
implementations don't always do so (last I heard, OpenSSH gets this wrong
between the end of initial key exchange and the start of user
authentication; it's reasonable to assume that other implementations get
it wrong at other times).

> i don't know the use of an authentication mechanism without

So you don't implement password or keyboard-interactive any more?

Ordinarily I'd agree with you, but it seems clear to me that in this
context, it's appropriate to consider such methods.  Suppose someone
builds their site around an authentication system that involves a
challenge-response exchange between the server and a smart card held by
the user.  If they build a GSSAPI mechanism for that system, isn't it
reasonable that they be able to use it with ssh, even though it doesn't
provide any sort of shared secret?

-- Jeff

---

From: Markus Friedl <[email-masked]>
Date: Tue, 2 Sep 2003 18:30:14 +0200

On Tue, Sep 02, 2003 at 12:10:32PM -0400, Jeffrey Hutzelman wrote:
> - Maintaining backward compatibility for the existing deployed base,
>   so that people can transition without a flag day.

that's easy if you use a different name for the method.

> - Maintaining support for GSSAPI mechanisms which are unable to support
>   GSS_GetMIC()
> - Not making gratuitous changes to work that's already been done.

i don't see why this is necessary.

> - Getting this done in a timely manner.
> 
> I know there are implementors who are planning on doing releases in the
> near future which include GSSAPI userauth (you know who you are).  I'd
> like to see those releases include support for the more secure variant, in

OpenSSH 3.7 cannot ship a 'more secure variant'.  It was even
considered replacing "gssapi" userauth with "[email-masked]".

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 2 Sep 2003 12:10:32 -0400 (EDT)

> partial success flag as you seem to be planning to specify it; the

I don't specify how the partial success flag works; the ssh-userauth
document does.  If you think it's too hard to implement, you should
comment on that issue separately, since that document has already passed
WG last call and gone to the IESG, and time to make changes is running
out.

> which authentication method.

No, I add one new rule: you can only try gssapi-mic when you have an
appropriate context to use.  It's not a very difficult rule to follow; if
you don't have a context, you can't possibly construct the request
message.

> And I really don't see what you buy by requiring that complexity that

I don't see that I'm advocating significant complexity.  For an
implementation of the ssh protocol that already supports gssapi userauth,
adding support for gssapi-mic should be pretty easy.

> without modifying the API that authentication methods use.

I know of no standard API.  I'm not working on an add-on to OpenSSH; I'm
working on an extension to the SSHv2 protocol.  It should not be difficult
to add the method I am proposing to an SSHv2 implementation which
correctly implements the current SSH protocol drafts and the existing
GSSAPI mechanisms.  I know of at least one implementor other than OpenSSH
who is already doing so, and at least three other people have outlined
ways to do so in OpenSSH, including returning partial success from an
authentication method and updating the list of mechanisms listed by the
server.

> authentication advocates written?

I'll pretend you didn't just suggest that somehow your having written some
patches for openssh makes your opinion more valuable or worthwhile than
mine.  This is an IETF working group, Joel -- everyone's opinion counts.

Just to be clear...  I don't really care what final form this takes.
What I do care about is

I know there are implementors who are planning on doing releases in the
near future which include GSSAPI userauth (you know who you are).  I'd
like to see those releases include support for the more secure variant, in
whatever form we end up agreeing on.  Some have already begun to implement
what we discussed last week, which I described formally in my message
yesterday morning.

I'm willing to go with another approach, if you can convince me that it
maintains the goals of backward compatibility and support for
non-integrity-capable mechanisms, that there's a real reason why it's
better (not just that using partial authentication offends your sense of
aesthetics), and that it won't in fact be harder for implementors to get
right.

-- Jeff

---

From: "Joel N. Weber II" <[email-masked]>
Date: Tue, 02 Sep 2003 13:08:30 -0400

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
Markus got into a tangent about SSH_MSG_UNIMPLEMENTED, which you don't
need to get right in order for my proposal to work; and it also gets
rid of the need for partial userauth.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 02 Sep 2003 14:03:27 -0400

> that's easy if you use a different name for the method.

True.  I didn't think that was what you meant by "negotiating within the 
method".

> i don't see why this is necessary.

Well, the key word is "gratuitous".  If a change is necessary, of course 
we'll do it.  But I don't like to do the same work multiple times, and I 
imagine the people implementing this feel the same way.  If it looks like 
the spec is going to keep changing every day, then no one will bother 
implementing it.  I guess part of the source of my concern over this is 
that several people have indicated they want to take care of this quickly; 
it's frustrating to think you have concensus, write up a specification, 
have people starting to implement it, and then discover that the concensus 
is not as strong as you thought.  I know that's not your fault, but perhaps 
it helps explain where I'm coming from.

> considered replacing "gssapi" userauth with "[email-masked]".

Just so I understand...  Regardless of what approach we choose to solving 
this problem, you're not planning on making any changes before 3.7 ships?

-- Jeff

---

From: Markus Friedl <[email-masked]>
Date: Tue, 2 Sep 2003 20:09:39 +0200

> True.  I didn't think that was what you meant by "negotiating within the 

no, but now you can negotiate within the new method whether
the GSSAPI mechanisms supports GSS_GetMIC.

> this problem, you're not planning on making any changes before 3.7 ships?

yes, i'm sorry, but it's too late.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 02 Sep 2003 14:14:31 -0400

> 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).

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.

My argument at this point boils down to not wanting to create unnecessary 
extra work for implementors.  If the other implementors who have been 
involved in this discussion don't think this is a problem, then I'll drop 
my objections.  Note that it will still take me a couple of days to work up 
a revised version of the draft...

> ... Markus got into a tangent about SSH_MSG_UNIMPLEMENTED, which you don't

Yes; that was in relation to a much earlier proposal which I don't think I 
even mentioned on this list, except as a reaction to Markus's comments 
today.  The gssapi-mic method doesn't require any particular behaviour with 
respect to unimplemented messages.

-- Jeff

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 02 Sep 2003 14:20:21 -0400

> the GSSAPI mechanisms supports GSS_GetMIC.

Actually, you can't.  All you can do is try to establish a context, and 
look when you're done to see if integrity protection is supported.  AFAIK 
there is no way in advance to tell whether a mechanism will support 
GSS_GetMIC or not.  But this isn't actually a major problem.

>> Just so I understand...  Regardless of what approach we choose to
>> solving  this problem, you're not planning on making any changes before
>> 3.7 ships?
>

Ok; I just wanted to make sure I understood you correctly.

---

From: Simon Wilkinson <[email-masked]>
Date: Tue, 02 Sep 2003 19:47:36 +0100 (BST)

Quoting Jeffrey Hutzelman <[email-masked]>:

> correctly.

Neither am I. There are several issues with having two different methods
using the same messages, both in OpenSSH and, I would imagine in other 
protocols.

If messages become overloaded, it becomes necessary for the application to 
keep track of the context in which those messages have occured (is this a 
gssapi, or a gssapi-mic message) for the entire exchange. It also doesn't
give us a solution that we can simply extend to key exchange.

There isn't any easy way for a client to decide whether a GSSAPI mechanism 
should be offered via the gssapi-mic or normal methods before it offers it. 
The client requires no particular knowledge of the underlying GSSAPI 
mechanism(s) its linked against, and I'd rather not add any. With mechanisms
that require user interaction (secure tokens, for example), having the same
mechansim tried twice (once with gssapi-mic, then again with gssapi when -mic
fails), would be annoying to say the least.

> It may be easier to do in the openssh server, because it 
> doesn't require filling in whatever support for partial authentication

The 'missing' support for partial authentication requires about 3 lines of
code to add to satisfy the needs of the proposed text. The gssapi-mic 
mechanism works equally well without partial authentication support. 
As Markus has said, the patch to add support for gssapi-mic is relatively
straightforward.

> My argument at this point boils down to not wanting to create
> unnecessary extra work for implementors.  

Its important to realise just _how_ many implementations, and in turn, 
users, we already have out there.  My GSSAPI patches have turned up in 
various forms in a large number of products. The strand supporting GSI are 
widely deployed across the Grid computing community as well.

Personally, I feel that the gssapi-mic proposal is the best one for solving
this problem in a general fashion that I've heard.

Cheers,

Simon.

---

From: Markus Friedl <[email-masked]>
Date: Tue, 2 Sep 2003 20:51:11 +0200

> argument as to _why_ using partial authentication is distasteful.

A server wants to enforce the use of a MIC, but has to offer "gssapi"
instead of "gssapi-mic" as a method.

Now all legacy clients can connect, they will choose "gssapi",
progress until the method succeeds partially.  But now they are
stuck since the server only offers "gssapi-mic", so the complete
"gssapi" is wasted.

If you have distinct methods, then the server initially offers only
"gssapi-mic".  Then legacy clients can connect and choose a different
method without problems.

However, if the server offers "gssapi", they will always choose
"gssapi", even if "gssapi" now means "gssapi"+"gssapi-mic".

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 2 Sep 2003 12:24:58 -0700

> does (or should) work that way. I agree with Markus' suggested solution too.

Partial userauth is useful for and needed to force the use of
keyboard-interactive when you want users to change their passwords -
that way users can't bypass password aging by using pubkey, hostbased or
gss userauth.

Partial userauth is fairly easy to implement for simple cases (such as
password aging or the proposed update to gss and external-keyex userauth
methods).

Partial userauth is harder to implement for some of the cases proposed
on the portable OpenSSH developer list, where userauth method vectors
have been proposed.

Here's a short description of how one might modify OpenSSH to support
simple partial userauth, in case it might help you accept the proposed
partial userauth fix to the gss draft issues:

 - add a boolean flag to the Authmethod structure to express userauth
   requirements (if set, the method MUST succeed before userauth
   succeeds)

    - initialize this flag to false for all methods (meaning that a
      single [enabled] method MUST succeed for userauth to succeed)

 - add a boolean function that indicates whether any enabled methods are
   marked as required

 - change authmethods_get() to return the list of required and enabled
   methods only, when there are any required and enabled methods

 - change userauth_finish() to reset the required flag of successful
   userauth methods

 - change userauth_finish() to determine that partial userauth failure
   occurs when a method succeeds but there remain required userauth
   methods

Cheers,

Nico
--

---

From: "Joel N. Weber II" <[email-masked]>
Date: Tue, 02 Sep 2003 16:35:23 -0400

> gssapi, or a gssapi-mic message) for the entire exchange.

Doesn't this happen with privsep already, in a different sense?

In the openssh implementation, this is probably what
authctxt->methoddata is for...

> code to add to satisfy the needs of the proposed text.

Looking at the code, I don't see how you can do that with 3 lines in a
non-hackish fashion, but shrug.  I haven't seen your patch, and I'm
not sure that it's anywhere that I can see it.

> The gssapi-mic 

It does work fine, as I've observed, but it also violates the spec
Jeff is writing, unless what you're wrote is sufficiently ambiguous
that we're thinking about two different things.

---

From: Damien Miller <[email-masked]>
Date: 03 Sep 2003 07:04:29 +1000

> that way users can't bypass password aging by using pubkey, hostbased or

My criticism is not a partial userauth (which is useful), but its abuse
to fix the shortcomings of GSSAPI auth.

-d

---

From: Joseph Galbraith <[email-masked]>
Date: Tue, 02 Sep 2003 15:47:48 -0600

> method name is confusing).

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

> 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 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

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 2 Sep 2003 15:13:32 -0700

I find this convincing.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 02 Sep 2003 19:35:49 -0400

> 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

---

From: Joseph Galbraith <[email-masked]>
Date: Tue, 02 Sep 2003 18:46:03 -0600

> 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.
> 
> 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).
> 
> 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

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 2 Sep 2003 18:12:11 -0700

Is there a list of GSS-API mechanisms that *don't* support integrity
protection?  Could you please post it?

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 2 Sep 2003 21:35:40 -0400 (EDT)

> protection?  Could you please post it?

I don't believe there's even a list of GSSAPI mechanisms.
Since they're named by OID's, there's no registration requirement.

---

From: "Joseph Salowey" <[email-masked]>
Date: Tue, 2 Sep 2003 19:33:59 -0700

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: [email-masked] 
> [mailto:[email-masked]] 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; [email-masked]; [email-masked]
> Subject: Re: gss userauth
> 
> 
> > Unfortunately, that creates a problem.  There is an 
> unavoidable lack 
> > of
> has been completed-- but I'm not even sure this is strictly necessary.
> 
> - Joseph
>

---

From: "Joel N. Weber II" <[email-masked]>
Date: Tue, 02 Sep 2003 22:56:59 -0400

> protection?  Could you please post it?

I believe that the SRP GSSAPI mechanism that I've seen an
internet-draft for but not an RFC doesn't do integrity protection, but
it does do some kind of key generation.  If you wanted to use that
mechanism as it is currently specified, you'd probably actually want
to either find some other GSSAPI mechanism that provides integrity
protection to use with it, or specify the use of that key generation
somehow.  Or perhaps the mechanism could be modified to provide
integrity somehow.

But I'm not aware of anyone ever having any actual intent to use
anything other than krb5 and gsi with ssh-gssapi.

(Also, while SASL and GSSAPI are different, many of the obvious SASL
mechanisms that don't do integrity are things for which there is
already an ssh userauth mechanism that does some approximation of the
same thing.)

---

From: "Joel N. Weber II" <[email-masked]>
Date: Tue, 02 Sep 2003 23:02:10 -0400

> gssapi-with-mic authentication if integrity is not supported.

I like the general idea behind this proposal.

The only concern I have is that the language ought to specify that if
you're supporting some mechanisms that do integrity and some that
don't, you should not force the site policy to turn off the mic for
the mechanisms that do support integrity.  I'm not sure if gssapi
gives you a better way to do this than allowing this to be configured
on a per-mechanism basis.

---

From: Markus Friedl <[email-masked]>
Date: Wed, 3 Sep 2003 11:49:04 +0200

> backwards compatibility, then it MAY advertise

I agree, "gssapi" should only be offered for backward
compatibility and legacy clients.

During a transition period server can offer both
"gssapi" and "gssapi-mic".

> and SHOULD NOT be used anymore.  I.e., reserve the name

I agree.

---

From: Markus Friedl <[email-masked]>
Date: Wed, 3 Sep 2003 12:02:24 +0200

> gssapi, or a gssapi-mic message) for the entire exchange.

I don't think this is the case, the state information
of the client/server should keep track of the
userauth method is in progress, so
	if (options.enforce_mic)
becomes
	if (context->method == with_mic)

-m

---

From: Markus Friedl <[email-masked]>
Date: Wed, 3 Sep 2003 11:45:12 +0200

> that way users can't bypass password aging by using pubkey, hostbased or

yes, partial userauth is useful, and i had it working similar to
what you suggest, but it never went into an openssh release.  the
question is not whether partial user authentication is good or bad
or easy to implement.  to me, partial authentication is inapproriate
in this gss/mic context.

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 3 Sep 2003 07:16:13 -0700

> somehow.  Or perhaps the mechanism could be modified to provide

My reading of draft-burdis-cat-srp-sasl-08 is that it does provide
integrity protection.

> anything other than krb5 and gsi with ssh-gssapi.

Sun has a mechanism called DH (OIDs 1.3.6.4.1.42.2.26.2.4 and
1.3.6.4.1.42.2.26.2.5).

Microsoft has NTLMSSP.

> already an ssh userauth mechanism that does some approximation of the

Right.  Same with EAP.  Basically, anything which can't generate session
keys with which to sign an SSHv2 session ID should be used with
keyboard-interactive or should have its own userauth method.

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 03 Sep 2003 11:32:38 -0400

> keyboard-interactive or should have its own userauth method.

No, I don't think that follows.  There's no reason to invent a separate 
userauth method for a technology for which a GSSAPI mechanism already 
exists.  The whole point of this exercise, and indeed of GSSAPI, is that 
you can use any GSS mechanism with any GSS-using application, without 
having to write n*m specifications and shepard them through the standards 
process.  When someone invents a new GSSAPI mechanism, SSH automatically 
supports it.

Application of this sort of modularity down at the network layer is one of 
the things that had made the Internet so successful - it was no longer 
necessary to specify how to run each application on top of each link layer. 
What would have happened if someone had said "any link later which can't 
provide reliable, ordered delivery of datagrams should have its own network 
layer, instead of using IP" ?

---

From: Joseph Galbraith <[email-masked]>
Date: Thu, 04 Sep 2003 16:29:47 -0600

All right-- so the big question is--
have we reached consensus for reals
this time?

Thanks,

- Joseph

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 4 Sep 2003 16:58:09 -0700

> have we reached consensus for reals

What's the consensus?  That gssapi and external-keyex userauth are to be
deprecated and replaced with forms that correctly bind the context to
the session?

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 04 Sep 2003 20:22:07 -0400

> deprecated and replaced with forms that correctly bind the context to

Yes.  Particularly:

- Obsolete external-keyex; it should not be used.
- Replace 'gssapi' with 'gssapi-with-mic'
- Add 'gssapi-keyex' to send a MIC using the context established during key 
exchange.

I will send some text for the latter two sometime tomorrow morning.

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 4 Sep 2003 17:22:44 -0700

> - Add 'gssapi-keyex' to send a MIC using the context established during key 

So, obsolete and replace the two gss-related userauths.  I agree.

Cheers,

Nico
--