So I've committed a GS2 implementation to the Moonshot repository. It's based on Cyrus SASL 2.1.23.
There are two components: a GS2 plugin and changes to Cyrus SASL to support channel binding. In theory it should be possible to use the plugin with regular Cyrus SASL and just not get channel binding support, but I haven't tested this. (The plugin data structures haven't changed thanks to the nice Cyrus folks leaving some spare fields around.)
The GS2 plugin has no knowledge of specific GSS-API mechanisms: instead it uses gss_indicate_mechs_by_attrs() (RFC 5587) to find all mechanisms that support mutual authentication and GSS channel binding, and then calls gss_inquire_saslname_for_mech() (RFC 5587) to find their SASL name. Right now this requires a branch of MIT Kerberos, which you can get at:
On the Cyrus side, there's a new property the caller can pass in:
typedef struct sasl_channel_binding {
const char *name;
int critical;
unsigned long len;
const unsigned char *data;
} sasl_channel_binding_t;
#define SASL_CHANNEL_BINDING 21
If critical is set, the client will fail if the server doesn't advertise channel binding (this is handled by libsasl; the plugin doesn't need to explicitly register -PLUS variants) and the server will fail if the client didn't provide them.
A plugin that supports channel binding must advertise SASL_FEAT_CHANNEL_BINDING and support marshalling the channel binding flag (RFC 5801 s.5) and application data, but beyond than that the rest is handled by libsasl. Of course, if you just build a GSS-API mechanism, it's handled for you by GS2 (as long as you implement RFC 5801/5587).
