Re: empty user name in gsskeyex

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

On Saturday, April 08, 2006 10:38:53 PM +1000 David Leonard 
<David.Leonard%quest.com@localhost> wrote:

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

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.


> And a corresponding provision should also be added to the gssapi-keyex
> 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?




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

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.

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

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