Simo Sorce ssorce at redhat.com
Thu May 8 15:11:08 EDT 2008

On Thu, 2008-05-08 at 10:08 -0700, Henry B. Hotz wrote:
> On May 8, 2008, at 9:16 AM, krbdev-request at mit.edu wrote:
> > Message: 3
> > Date: Wed, 07 May 2008 16:23:27 -0400
> > From: Simo Sorce <ssorce at redhat.com>
> > Subject: RE: OK-AS-DELEGATE FLAG setting.
> > To: JC Ferguson <jc at F5.com>
> > Cc: Ken Raeburn <raeburn at mit.edu>, krbdev at mit.edu,	"Douglas E. Engert"
> > 	<deengert at anl.gov>
> > Message-ID: <1210191807.32052.44.camel at localhost.localdomain>
> > Content-Type: text/plain
> >
> > On Wed, 2008-05-07 at 12:37 -0400, JC Ferguson wrote:
> >> FWIW: microsoft sets this when a principal is "trusted for  
> >> delegation"
> >> in Active Directory.  When a microsoft client is connecting to a
> >> CIFS-based service and the OK_AS_DELEGATE flag is set, the microsoft
> >> client fetches a forwardable TGT and wraps that up in the  
> >> authentication
> >> material along with the service ticket.
> >
> > It would be very useful to have a flag like that to mark trusted
> > services.
> > Being able to forward TGTs is very useful in some cases, but the
> > downside is that then you end up forwarding it just to everybody.  
> > Being
> > able to say, at the KDC level, whom the client should fully trust or  
> > not
> > would be a major improvement.
> >
> > Simo.
> I hope I don't need to say this to this crowd, but I will anyway.
> This flag does *not* actually aid security.  This is an advisory  
> flag.  There is nothing that requires the clients to respect it.  In  
> fact (as this discussion demonstrates) everything works just fine if  
> clients forward tgt's regardless of the flag setting.  This means in  
> turn that there is nothing that prevents evil servers from making use  
> of such a forwarded tgt.
> Unless things have changed in the last 6 months or so, neither  
> Firefox, nor Safari pay any attention to the flag.  Only IE, AFAIK.

This is understood, but once we have the flag from the KDC we can start
doing that, at least the client will have a way to know what it should
do. Currently you would have to manually configure the list of trusted
services per application, not something that scale in any reasonable use

Also being able to enforce respect of such flag in the kerberos/gssapi
libraries would be a big advantage, but I am not sure that is always


Simo Sorce * Red Hat, Inc * New York

More information about the krbdev mailing list