Client Principal Selection

[Jeffrey Hutzelman]

On Monday, July 11, 2005 04:56:32 PM -0400 Jeffrey Altman <jaltman at mit.edu> 
wrote:

> The way I see it, if a service does not accept Kerberos authentication
> then it should not be offering it.   If the users are being prompted
> when they should not be, its a server administrators responsibility to
> fix it.

I'm afraid it's not that simple.  For example, consider SSH with 
GSSAPI-based key exchange.  The SSH protocol begins with each side sending 
a banner followed by a KEXINIT message which contains a list of algorithms 
supported by that side.  The KEXINIT messages are sent simultaneously, and 
a client that waits to receive the server's message before sending its own 
risks deadlock.

Thus, the SSH client needs to know whether to claim support for the gssapi 
keyex method without waiting to see if the server supports it.  Further, if 
the gssapi keyex method is chosen and then the user has no credentials, the 
connection will fail.  Therefore, current ssh clients generally make the 
first gss_init_sec_context call before the negotation even starts, to see 
whether they are likely to be able to authenticate to this particular 
server.

So, in this case we cannot use the service's support for Kerberos 
authentication or lack thereof to decide whether to obtain credentials, 
because we need to know whether we can/should use Kerberos before we ever 
get that information from the server.