Client Principal Selection

[Jeffrey Altman]

Jeffrey Hutzelman wrote:

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

This is true and for these applications there is little that can be done
to prevent the need to evaluate which client principal should be used.
For applications such as e-mail, the ability to avoid the evaluation is
possible.

Jeffrey Altman

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 2707 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20050715/15d6182d/attachment.bin