ok-as-delegate and GSS-API

Background

To forward your Kerberos credential from a gss-api client to a server you turn on the flag GSS_C_DELEG_FLAG. This will, as part of the authentication, forward your tickets to the server.

The problem is that you don't want to turn on this just for every server your what to authenticate to, because most of them should probably not be trusted with your tickets.

To solve this Microsoft added an extention to the Kerberos, that was added to RFC4120 (The Kerberos protocol RFC). The extention is called ok-as-delegate and is a ticket flag. Using the flag the client can determine that the system administrator thinks about the host, if it should be delegated too or not.

Non Microsoft sites have been using GSS-API implementations that doesn't honor the flag ok-as-delegate and most of them never has set the ok-as-delegate flag. In some cases the sites are using Kerberos implementations that doesn't even support setting the ok-as-delegate flag in the Kerberos database.

Users at these sites have grown accustomed to the behavior ok GSS_C_DELEG_FLAG and changing the GSS-API implementation behind them to make GSS_C_DELEG_FLAG honor the ok-as-delegate flag will only make people upset.

New flag

What we can do it introduce a new flag GSS_C_DELEG_POLICY_FLAG that is defined to honor the flag ok-as-delegate.

The flag GSS_C_DELEG_POLICY_FLAG is a local flag that is never seen on the wire. And, its only used by the initator, the acceptor never see the flag.

There are four cases where GSS_C_DELEG_POLICY_FLAG and GSS_C_DELEG_FLAG interact with each other and the resulting return flags.

• Neither flag set
  do nothing with regard to delegation


• GSS_C_DELEG_FLAG set
  always try go delegate and set GSS_C_DELEG_FLAG in the return flags if successful


• GSS_C_DELEG_POLIY_FLAG set
  try to delegate if ok-as-delegate is set, delegate and set GSS_C_DELEG_FLAG and GSS_C_DELEG_POLICY_FLAG in the return flags if successful


• GSS_C_DELEG_FLAG and GSS_C_DELEG_POLIY_FLAG setalways try to delegate, set GSS_C_DELEG_FLAG if successful in the return flags if successful. Also, if successful and ok-as-delegate was set on the service ticket, set GSS_C_DELEG_POLICY_FLAG in the return flags.

Cross realm ?

What is missing is how ok-as-delegate and GSS_C_DELEG_POLICY_FLAG should work in the cross realm case. RFC4120 is quiet on this issue, the flag on ok-as-delegate doesn't mean anything on the cross realm tgt. The question is how this should be dealt with.

The obvious answer is define a meaning on the cross realm tgt ticket for ok-as-delegate, but how will that interact with existing deployments.

Current behavior is for released MIT and heimdal is that the flag is ignored. For Microsoft clients is that they honor the flag for windows domains, and to external realms they allow delegation is a flag is set on the realm configuration on the client.

Any good ideas out there ?