OK-AS-DELEGATE Flag

[Wachdorf, Daniel R]

See below:

-----Original Message-----
From: Douglas E. Engert [mailto:deengert at anl.gov] 
Sent: Wednesday, March 08, 2006 2:44 PM
To: Wachdorf, Daniel R
Cc: krbdev at mit.edu
Subject: Re: OK-AS-DELEGATE Flag



Wachdorf, Daniel R wrote:

> 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.

A windows client will look at the registry. A user could always change
the client code to ignore this so it should be treated as advisory.

DAN:  I'm not necessarily trying to emulate the windows functionality.
I think our implementation allows for the most flexibility in terms of
allowing centralized delegation control and giving the users the ability
to not delegate if they don't want to.  I don't think you could
necessarily "stop" an application or user from delegating who really
want's to.  The goal would be to have a centralized management used to
tell clients it is ok to delegate.  This is especially helpful when you
talk about delegating credentials when authenticating to web servers.  
When you say the windows client will look at the registry - is that
internal to the SSPI - or are clients required to do that before they
indicate when then want to delegate or not? 

> 
> 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?

Should the cross realm TGTs also have this bit set?

DAN:  So, if the cross realm TGT has OK_AS_DELEGATE set, then trust the
OK_AS_DELEGATE flag on the cross realm service tickets.  This would give
administrators control of the ability - but it would be an all or
nothing decision.  Our implementation allows you to specify a value
(regex) in the krb5.conf file which overrides the OK_AS_DELEGATE flag.  

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

The way Windows does this, if the client registry has:

HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Domains\<Realm-name>\
RealmFlags
= 4, then every one in the realm is trusted. i.e. ignore the advise of
the KDC. It implies this is for non Windows realms only, but I think it
applies to domains too.

ksetup can set these for you.

So this appears to be advisory only. A client could ignore the
advice of the KDC.

(Also note that to be able to set the bit on the account in AD requires
special privilages on the AD machine with the KDC.)

> 
> 
> Thanks in advance.
> 
> -dan
> 
> -------------------------------------- 
> Daniel Wachdorf 
> drwachd at sandia.gov 
> Sandia National Laboratories 
> Cyber Security Technologies 
> 505-284-8060 
> 
> 

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444