Subject: OK-AS-DELEGATE Flag

From: "Wachdorf, Daniel R" <[email-masked]>
Date: Wed, 8 Mar 2006 13:56:06 -0700

Sandia currently has a working implementation of the OK_AS_DELEGATE flag
running on the MIT code base.  I would like to get this running on the
most current code base and submit a patch back to MIT.  

I doing this, I think the OK_AS_DELEGATE brings up a few questions worth
discussing:

1- Should the clients have influence over this?  

Our implementation requires clients attempt delegation and the
OK_AS_DELEGATE flag be set on the service ticket in order for delegation
to occur.  This sits in the Kerberos code, so it applies to GSSAPI as
well.

2- How should cross-realm delegation be handled?  

Do you want to trust the delegation flag from a cross realm service?
Also - not all Kerberos realms will support OK_AS_DELEGATE, so should
you be able to override this.  Should the flag only be relevant for the
local realm?

3- Should there be a configuration option to control the functionality?

Thanks in advance.

-dan

-------------------------------------- 
Daniel Wachdorf 
[email-masked] 
Sandia National Laboratories 
Cyber Security Technologies 
505-284-8060

---

From: Sam Hartman <[email-masked]>
Date: Mon, 13 Mar 2006 09:53:01 -0500

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