Difference between revisions of "Projects/GSS mechanism selection"

Revision as of 16:25, 8 July 2015

This page contains design notes covering multiple issues related to GSS mechanism selection. The proposals here may not reflect a wide consensus.

Problems

• With no desired_mechs argument, gss_acquire_cred() acquires a cred for every supported mechanism including SPNEGO. SPNEGO will also acquire a cred for every supported mechanism.

• There are four different OIDs for krb5: the real OID, the old pre-RFC OID, the Microsoft OID, and IAKERB. Combined with the above, this means that gss_acquire_cred() with no desired_mechs argument performs eight krb5 acquire_cred() operations; see [krbdev.mit.edu #7171].

• The SPNEGO initiator tries IAKERB by default; this can cause pain in some configurations; see [krbdev.mit.edu #8021].

• Acceptors (using SPNEGO, the default credential, or a credential acquired with no desired_mechs argument) process IAKERB tokens by default.

• gss_acquire_cred_with_password() performs up to six AS-REQs, one for each non-IAKERB variant of the krb5 mech outside of SPNEGO, and again inside SPNEGO. Prior to [krbdev.mit.edu #8152] this issue was masked by caching because the krb5 gss_acquire_cred_with_password() made use of the default cache.

Possible solutions

These ideas are mostly independent.

• Omit the old pre-RFC krb5 OID and the Microsoft wrong krb5 OID from gss_indicate_mechs(), and therefore from SPNEGO. Add specific compatibility code in SPNEGO for the Microsoft wrong krb5 OID. (Heimdal has a hack like this in its SPNEGO mechanism, which we could use for reference.)

• Omit SPNEGO from the default set of mechanisms used by gss_acquire_cred(). In the mechglue gss_accept_sec_context(), if a SPNEGO token is received and SPNEGO is not in the acceptor cred, wrap the acceptor cred in a SPNEGO cred and invoke the SPNEGO mechanism. (This solution adds the SPNEGO code to the attack surface of a server which acquires an acceptof cred for an explicit set of mechanisms not including SPNEGO.)

• Omit IAKERB from gss_indicate_mechs(). In the mechglue gss_accept_sec_context(), specifically disallow IAKERB (or any mechanism with a specific mech attribute) when the default acceptor credential is used. Server applications would have to explicitly acquire an acceptor cred with IAKERB in the desired_mechs argument to act as an IAKERB acceptor. Client applications would have to explicitly name IAKERB in order to use it, without assistance from gss_indicate_mechs().

• If the above is not implemented, SPNEGO could explicitly filter out IAKERB from the default list of negotiated mechanisms, either on the initiator side, the acceptor side, or both. As above, a mechanism attribute could be used as an alternative to explicitly special-casing IAKERB.