logo_kerberos.gif

Difference between revisions of "Projects/GSS mechanism selection"

From K5Wiki
Jump to: navigation, search
(New page: {{project-early}} This page contains design notes covering multiple issues related to GSS mechanism selection. The proposals here may not reflect a wide consensus. ==Problems== * With ...)
 
(Problems)
Line 12: Line 12:
   
 
* Acceptors (using SPNEGO, the default credential, or a credential acquired with no desired_mechs argument) process IAKERB tokens by default.
 
* 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 {{bug|8152}} this issue was masked by caching because the krb5 gss_acquire_cred_with_password() made use of the default cache.
   
 
==Possible solutions==
 
==Possible solutions==

Revision as of 17:25, 8 July 2015

This is an early stage project for MIT Kerberos. It is being fleshed out by its proponents. Feel free to help flesh out the details of this project. After the project is ready, it will be presented for review and approval.


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.