OK-AS-DELEGATE Flag

[Wachdorf, Daniel R]

See below- 

-----Original Message-----
From: owner-ietf-krb-wg at mailhost.anl.gov
[mailto:owner-ietf-krb-wg at mailhost.anl.gov] On Behalf Of Sam Hartman
Sent: Monday, March 13, 2006 7:53 AM
To: Wachdorf, Daniel R
Cc: krbdev at MIT.EDU; ietf-krb-wg at anl.gov
Subject: Re: OK-AS-DELEGATE Flag

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.

DAN: I think the ok-as-delegate flag in the TGT is a good model.  It's
centrally managed.  Additionally, I think you should have a per realm
entry in the krb5.conf with a list of regex defining who you should
delegate to.  The client can check the ok-as-delegate flag in the
x-realm TGT first, then check the config file. 

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.

DAN: I don't think you need this control in the API level, I think it
should sit higher (a krb5.conf config value) In a lot of cases, to
delegate or not to delegate doesn't ever get translated to the end user
- it's handled "internal" to the program.  If this "third state" is
outside of the API it gives the end user control of the issue.  In this
paradigm, the application delegates as often as possible through the API
(ie - openSSH delegates whenever it can).  The user can control
delegation by editing a config value or accept to trust the
ok-as-delegate flag if they want to trust centralized control.  

DAN: In my option you need two configuration parameters.   One says
trust the ok-as-delegate flag (per realm).  The other privides a regex
saying delegate to these principals (checked after the ok-as-delegate
flag is checked). This way a user can configure, in the krb5.conf file,
to ignore the ok-as-delegate or add to it though a regex.  

DAN: I see one other problem with integrating this functionality in the
MIT code base its backwards compatibility.  If I upgrade versions, I
would either need to immediately set the ok-as-delegate flag in the kdc
on all the necessary principals or push out a new krb5.conf file.  A
solution to this might be a config parameter within the kdc.conf file
might help in provided a default ok-as-delegate regex, but that's hacky.

--Sam