OK-AS-DELEGATE Flag

[Sam Hartman]

I'm not sure what the behavior should be on the client side.

The default behavior clearly needs to be the same because doing
anything else would break existing deployments.

Roughly you have two types of realms.  In the first realm, the KDC is
not in a good position to make trust decisions for the client.  You
only want to delegate if you have an explicit request from the client.
The KDC typically never sets ok-as-delegate.
MIT assumes all realms are in this category today.

Another class of realm is a realm that is in a position to know when
to delegate.  For these realms you can use the flag as a good
indication of when to delegate and unless the client behavior
explicitly requests something else then you trust the flag.

So, we have two problems with fitting this model into the MIT code base.

First, we don't have a good way to know what kind of realm we're
talking to.  Ideally we'd want a way of discovering this.  We could
have some hack, like whether ok-as-delegate is set on the TGT
principal, but really we should have a discovery mechanism in the
protocol.  Probably since we don't have that we need per-realm
configuration defaulting to the old behavior.

Secondly, we're turning delegation into a tri-state on the client:
never delegate, delegate if the KDC says so, and always delegate.  If
you don't have all states available to the client then you are
violating the software engineering principle that you should design
your software for its users.  We don't have a good way to express that
tri-state in our APIs--particularly not in GSSAPI but also not really
in the command line interfaces.  This is very much not ideal but is
probably difficult to fix.

--Sam