Re: empty user name in gsskeyex

[Nicolas Williams <Nicolas.Williams%Sun.COM@localhost>]

On Sat, Apr 08, 2006 at 10:38:53PM +1000, David Leonard 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.

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

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

Sure.

> 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 

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

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

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 
> sounds bad to me.

Local matter.

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

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, 
> openssh servers prohibit a client from changing the username during 
> authentication. The server immediately disconnects. Is that cause for 
> concern?

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.

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

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

Nico
--