Client Principal Selection
jaltman at MIT.EDU
Fri Jul 15 07:30:44 EDT 2005
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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 2707 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20050715/15d6182d/attachment.bin
More information about the krbdev