On 15 Mar 2011, at 13:57, Luke Howard wrote:

> I also managed to get OpenSSH working. This did require some changes to OpenSSH (and, as it happened, to Moonshot). I'll summarise below:
> 
> * OpenSSH checks that for GSS_C_MUTUAL_FLAG in the acceptor's returned flags.

This is required by RFC4462 - it should be the case for all implementations of GSSAPI support in SSH.

> * OpenSSH parses the exported name token and verifies that the encoded mechanism OID matches the negotiated mechanism.

We have to parse the exported name, because it's the only way of going from a GSSAPI name back into something that can be passed into krb5_kuserok. We can't use the display name, because there's no guarantee that that matches the principal used to initiate the connection. The rather paranoid set of checks here was required by the extensive security review that the code underwent before making it into OpenSSH.
> 
> * OpenSSH's set of supported mechanisms is hard-coded. Adding a new one involves adding a dispatch table entry similar to the following:
> 
> ssh_gssapi_mech* supported_mechs[]= {
> #ifdef KRB5
>         &gssapi_kerberos_mech,
>         &gssapi_eap_aes128_mech,
>         &gssapi_eap_aes256_mech,
> #endif
>         &gssapi_null_mech,
> };
> 

This is true on the server side. At the point that this code was written, there was no GSSAPI-based support for checking whether an identity was permitted to become a particular username on the system, or of exporting credentials delegated credentials from the application into a system wide credential cache. The latter is now possible, but it's deployment is currently far from widespread. As a result, the server uses mechanisms specific code to acheive these tasks, hence the requirement for the dispatch table.

The client should be capable of using any GSSAPI mechanism that you throw of it. In fact, if your library is ABI compatible, you should just be able to change the linker path under an existing binary.

> * It would be possible to integrate EAP credentials acquisition with OpenSSH's prompting, but the way that it optimistically generates initial context tokens for each supported mechanism makes this less useful (because the user would need to enter their password multiple times).

This is a real pain - its what's led some vendors to disable GSSAPI support out of the box when they ship OpenSSH. However, it's very hard to avoid - how else do you determine what mechanisms you should be offering to the peer? It's even more of an issue with key exchange, where you only get one chance to get it right - you can't perform any form of mechanism fallback once negotiation is complete.

[ and, in another message ... ]

> It's possible that we want to pass the SSH client identity to gss_acquire_cred()

My GSSAPI patches for OpenSSH (which add key exchange, and numerous other GSSAPI based features) include support for a GSSAPIClientIdentity option which lets the user select the identity that they wish to pass to gss_acquire_cred()

Cheers,

Simon.