[krbdev.mit.edu #5596] patch for providing a way to set the ok-as-delegate flag

[Machin@MIT.EDU]

> It does not require the client to delegate!  The Sandia mods 
> are enforcing a local policy that will only delegate if the 
> KDC says the server is trusted, and the client requests 
> delagation, i.e. called krb5_fwd_tgt_creds() 

Doug is correct.  We do have an override for those realms who cannot set
the OK-AS-DELEGATE flag in the service ticket.   This is done through
the krb5.conf file, using the ok_to_delegate attribute, which set on a
per realm basis.

[realms]
        REALM = {
                 ok_to_delegate = host/clustersystem*@REALM 
		     }


Glenn





> -----Original Message-----
> From: krb5-bugs-bounces at mit.edu 
> [mailto:krb5-bugs-bounces at mit.edu] On Behalf Of 
> DEEngert at anl.gov via RT
> Sent: Wednesday, July 18, 2007 12:02 PM
> Subject: Re: [krbdev.mit.edu #5596] patch for providing a way 
> to set the ok-as-delegate flag
> 
> 
> 
> nalin at redhat.com via RT wrote:
> > On Wed, Jul 18, 2007 at 10:50:43AM -0400, Sam Hartman via RT wrote:
> >> Here's the current Sandia patch.  I'm sorry for sitting on this so 
> >> long.
> > 
> > No worries.
> > 
> >> My recommendation is that if possible you use the same flag and 
> >> kadmin option that they do.  I'm a bit confused by the client 
> >> support.  As far as I can tell the new function they add 
> is static so 
> >> I'm not sure how you'd ever use it.
> > 
> > Both patches toggle the same bit in the kdb entry, and as 
> far as the 
> > kadmin-specific changes go, the only real difference is the 
> > user-visible strings.  I'm not wedded to the values I used there.
> > 
> > But I think there's a meaningful difference in how the flag 
> (which is 
> > the same attribute bit in both versions) is used in the two patches.
> > 
> > If I'm reading it right, the Sandia patch appears to use 
> the flag to 
> > control whether or not the client library actually attempts 
> to obtain 
> > a forwardable TGT when the application calls krb5_fwd_tgt_creds().  
> > That doesn't match my reading of how the flag is expected 
> to be used.  
> > FWIW, I don't see a way to call the new static function 
> with different 
> > flags, either.
> > 
> > In the case I've been looking at (gss_init_sec_context() 
> called with 
> > GSS_C_DELEG_FLAG unset, but the realm admin wants credentials to be 
> > delegated), I don't think we get as far as calling 
> krb5_fwd_tgt_creds().
> > 
> > My reading of the spec is that if the flag is set in the 
> credentials 
> > we use for authenticating to a service, we should delegate 
> credentials 
> > to that service.
> 
> Thats not the way I read it. It is advisory information from 
> the KDC to the client. RFC 4120 section 2.8 says:
> "The OK-AS-DELEGATE provides a way for the KDC to communicate 
> local realm policy to a client regarding whether an 
> intermediate server is trusted to accept such credentials."
> 
> It does not require the client to delegate!  The Sandia mods 
> are enforcing a local policy that will only delegate if the 
> KDC says the server is trusted, and the client requests 
> delagation, i.e. called krb5_fwd_tgt_creds() In effect doing 
> what Windows clients and AD do by default.
> 
> Even in Windows the "ksetup /SetRealmFlags <realm> Delegate" 
> can be used to tell the client assume the OK-AS-DELAGATE is 
> always on. In effect overriding the local client policy. I 
> thing this only applies to non-AD realms, as not all KDC have 
> this feature, so this command can be used until they do.
> 
> 
>   For example, in krb5_gss_init_sec_context(), if the
> > credential which get_credentials() returns has the 
> > TKT_FLG_OK_AS_DELEGATE bit set, we should force 
> GSS_C_DELEG_FLAG to be 
> > on.  (For completeness, I guess similar changes would be 
> desirable in 
> > the telnet/rsh/rlogin clients, though I haven't looked at 
> the sources 
> > for those with this in mind.)
> > 
> > We could use some of the matching code in the patch to 
> fine-tune that 
> > behavior, but when I think about it some more, I can't come 
> up with a 
> > really good reason that I shouldn't just be trusting the 
> KDC's (and by 
> > extension the realm admin's) judgement.
> > 
> > _______________________________________________
> > krb5-bugs mailing list
> > krb5-bugs at mit.edu
> > https://mailman.mit.edu/mailman/listinfo/krb5-bugs
> > 
> > 
> 
> -- 
> 
>   Douglas E. Engert  <DEEngert at anl.gov>
>   Argonne National Laboratory
>   9700 South Cass Avenue
>   Argonne, Illinois  60439
>   (630) 252-5444
> 
> _______________________________________________
> krb5-bugs mailing list
> krb5-bugs at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krb5-bugs
> 
>