OK-AS-DELEGATE FLAG setting.
jaltman at secure-endpoints.com
Thu May 8 18:40:29 EDT 2008
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.
Secure Endpoints Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3355 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20080508/9d521846/attachment.bin
More information about the krbdev