OK-AS-DELEGATE FLAG setting.

Simo Sorce ssorce at redhat.com
Thu May 8 19:13:30 EDT 2008


On Thu, 2008-05-08 at 18:40 -0400, Jeffrey Altman wrote:
> Paul Moore wrote:
> > The GSS layer should enforce the obedience of this flag. In the current
> > MIT gss code it does not. This is very bad (we have reported this
> > before). The KDC has set a flag saying 'don't forward this' and yet the
> > MIT client code forwards it anyway. We offered a fix (we have it in
> > place already) but were told 'no thanks'. I suspect that the reason the
> > client side code ignores it is because the MIT KDC never sets it and so
> > nobody in MIT has paid much attention to it. MS AD KDC uses it all the
> > time. In fact AD's default mode is to set 'do not forward '
> 
> You have to understand that the creation of this flag changes the
> behavior.  Historically there was no flag indicating whether or not the
> KDC thought it was safe to forward.  So is the absence of the flag an
> indication that it is not safe or that the KDC does not support the flag?
> 
> If you add support for this in the client and I use that client to
> talk to a realm whose KDC does not support the flag, then I lose.
> 
> If you have a realm whose KDC does not support the flag and you
> upgrade to a new version that does, does the upgrade set the flag by
> default to ensure backward compatibility with the previous behavior?
> 
> If not, does the realm administrator know that they need to set the
> flag and on which service principals it is required on?
> 
> These are serious issues and it would be inappropriate for MIT to simply 
> take a patch that enabled the option in the KDC and enforced it in the
> client without working through an appropriate upgrade path.
> 
> In my opinion the flag that should have been added is not OK-AS-DELEGATE
> but DO-NOT-FORWARD and have AD set that flag by default on all 
> principals.  Doing so would have provided an easy upgrade path for other 
> Kerberos KDC and client implementations.
> 
> The way things are, no matter what is done someone is going to have to
> pay a significant price.

If the upgrade path is the issue it is easy to add a [libdefaults]
options to turn on/off obeying the flag, with default set to off.

example:

[libdefaults]
  honor-ok-as-delegate = true|false


But not having at all the option to honor the flag is worst imo.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York




More information about the krbdev mailing list