Subject: empty user name in gsskeyex

From: David Leonard <[email-masked]>
Date: Sat, 08 Apr 2006 22:38:53 +1000

I have some concerns with this under-discussed paragraph in gsskeyex-10

  The user name may be an empty string if it can be deduced from the
  results of the GSSAPI authentication. If the user name is not empty,
  and the requested user does not exist, the server MAY disconnect, or
  MAY send a bogus list of acceptable authentications but never accept
  any.  This makes it possible for the server to avoid disclosing
  information about which accounts exist.  In any case, if the user
  does not exist, the authentication request MUST NOT be accepted.

The first sentence mentions a server capability (deducing user names 
when passed as blank) the status of which isn't clearly described. If 
the feature isn't useful enough to be included properly, then that 
sentence should just be deleted.

I think that deducing user names /is/ a convenient feature, so I instead 
suggest that the first sentence be replaced with:

  If the user name is an empty string, the server MAY deduce the user
  name from the results of the GSSAPI authentication.

And a corresponding provision should also be added to the gssapi-keyex 
method section (i.e. repeat the above sentence for keyex)

This is a pretty useful feature for users in my view. But I am worried 
that it has too many problems. The current GSSAPI does not provide a way 
to portably deduce an account name from credentials. (I'm thinking about 
querying credentials to get a GSS_C_NT_USER_NAME name). Maybe one day it 
will? But for now, a server must talk magic to its favourite mechanisms. 
In short, the feature encourages non-standard implementation. That 
sounds bad to me.

I also noticed an interoperability problem. A good client, not provided 
with a username, will try the empty-username first, and if it fails, 
assume the server is old and try to deduce a username itself. However, 
openssh servers prohibit a client from changing the username during 
authentication. The server immediately disconnects. Is that cause for 
concern?

In short, I don't know if permitting user name deduction is such a great 
idea with the problems it may cause. But, it would certainly be nice to 
have.

David Leonard

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Sat, 08 Apr 2006 12:37:00 -0400

On Saturday, April 08, 2006 10:38:53 PM +1000 David Leonard 
<[email-masked]> wrote:

> The first sentence mentions a server capability (deducing user names when
> passed as blank) the status of which isn't clearly described. If the
> feature isn't useful enough to be included properly, then that sentence
> should just be deleted.
>

I don't think this is a substantive change in the protocol; it simply 
describes the existing feature in a way that doesn't suggest the client 
should be able to guess at the server's capabilities.

> method section (i.e. repeat the above sentence for keyex)

Just that sentence, without the other three paragraphs about user names 
from section 3.2?

> will?

I doubt it.  The GSS-API is largely about authentication; it doesn't make 
authorization decisions for applications, including things like which 
credentials have what access to what "accounts".  The form and meaning of 
usernames is up to the application, and in SSH, it is specific to the 
server implementation.

> But for now, a server must talk magic to its favourite mechanisms.

Not magic.  A GSS-API acceptor can query a context in a portable way to 
discover the name of the initiator.  And, as Nico points out, there is work 
in progress to define ways to find out additional information.  However, 
making authorization decisions in inherently application-specific, and in 
the case of SSH usernames, also implementation-specific.

> In short, the feature encourages non-standard implementation. That sounds
> bad to me.

It encourages servers to define a mapping, or allow the administrator to do 
so.  Since such mappings cannot be standardized in the general case, this 
is not a problem.

> authentication. The server immediately disconnects. Is that cause for

I don't think so.  The SSH specification allows a server to disconnect when 
a client changes usernames, if the alternative (flushing all authentication 
state) is too hard for it.  So, clients that want to change usernames need 
to be prepared to establish a new connection if the server terminates the 
connection on a username change.

Note that in the real world, a "normal" client is unlikely to fall back to 
deducing a username from whatever credentials GSS-API is using.  Instead, 
it is likely to use a name based on the user's local identity on the client 
system (for example, the value of $USER on a UNIX system).

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Sat, 8 Apr 2006 12:37:22 -0500

>  name from the results of the GSSAPI authentication.

OK, so you want RFC2119 language.  I think that's reasonable, if a bit
late.

> method section (i.e. repeat the above sentence for keyex)

Sure.

> to portably deduce an account name from credentials. (I'm thinking about 

I doesn't have to.  This can be a local matter.  And in at least one
implementation it is.

> will? But for now, a server must talk magic to its favourite mechanisms. 

Not so.

Things one can do: maintain a database of exported name token to
username mappings.  Nothing mechanism-specific there.  Other portable
alternatives exist also, but I don't think this RFC should mandate or
even recommend any of them.

> In short, the feature encourages non-standard implementation. That 

Local matter.

> assume the server is old and try to deduce a username itself.

Really?  For what definition of good?  Some clients simply default to
whatever the username is on the client side, or in a configuration file.

>                                                               However, 

I don't think it is much of a concern because I think clients should
require that the user explicitly choose to assert the empty username.

Besides, servers could allow switching from the empty username to one
non-empty username.

> idea with the problems it may cause. But, it would certainly be nice to 

I think it's a great idea and it does work.

Nico
--

---

From: Simon Wilkinson <[email-masked]>
Date: Sun, 9 Apr 2006 13:49:18 +0100 (BST)

> I doesn't have to.  This can be a local matter.  And in at least one

For the record, patches existed for OpenSSH which provided this 
feature (for Kerberos and GSI, at least). It was included in the original
code drop that was provided to the OpenSSH folks, but was one of the 
features removed in the interests of simplifying the code when GSS 
userauth was integrated.

It was implemented in the same way as storage of delegated credentials is 
implemented - by providing mechanism specific routines.

S.