Heimdal

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 ?

We can implement referrals support for Kerberos mk_req API or do it for GSS-API. For me its an easy choice, most consumers uses GSS-API, lets go for that.

DNS canonicalition happens when we pass in a GSS_C_NT_HOSTBASED_SERVICE based name into gss_import_name(), so its only that case we really need to care about. DNS canonlisation is done by krb5_sname_to_principal(), see documentation in Heimdal trunk.

The simple solution is that in gss_import_name() we the hostname to krb5_sname_to_principal(), instead we mark up the principal as magic-unresolved. Now there are some places where we should return the name in its native form, and that is after gss_init_sec_context() is done by gss_inquire_context(), and gss_canonicalize_name(). We also need to deal with these magic-unresolved names in gss_acquire_cred() and gss_export_name().

So lets go over the four cases when we have a magic-unresolved.

gss_init_sec_context(), we try first to get Kerberos credentials using TGS-REQ using the sort name and hope that its an valid alias, if no, we call back to the old way with krb5_sname_to_principal(). Right, we update the name in the context to what we used.

gss_acquire_cred() same thing here, first try literal, then krb5_sname_to_principal().

gss_inquire_context(), this is simple gss_init_sec_context() will have solve the problem for us, just copy out the string.

gss_canonicalize_name() here we don’t have a chance, so I guess, we want to have the canonicalized name, so I used the krb5_sname_to_principal() to canonicalize the name.

So where to store this magic-unresolved bit ? Well it happens to be so that the Kerberos gss-api mech uses Kerberos principals (krb5_principal) so there no extra bit where we can save the info. So, instead we hook the krb5_principal name type field and misuse that. Any time we will export or use the principal, we’ll convert back to KRB5_NT_SRV_HST that it would have been if we used krb5_sname_to_principal().

I have started to merge the Samba GSS-API change from Andrew Bartlet and Stefan Metzmacher. As part of that work I have completed most of the basic work of my clone of gssmaggot/gssmaster that David Christansson (Microsoft) have written.

 The problem with gssmaster is that its not released in source-code format, so I wrote my own client (gssmask) and server (gssmaestro). gssmaestro is not as complete that I wish, but test most of the context and token functionallity in the gss-space.

I plan to use gssmask/gssmaestro to test with gssmaggot, this way I can make sure I don’t break anything, and at the same time still work with Microsofts and MIT gssapi implementations. This is what we do for the interrop events, but usually with new and shiny code.

There is also a new regression test that uses the gssmask/gssmaestro test program in heimdal/tests/gss directory and its hooked up to the regular automake regression tests, so hopefully I wont break the basic gss-api functions ever again.