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

[DEEngert@anl.gov via RT]

Machin at mit.edu wrote:
>> 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 
> 		     }
> 

I like this better then the check_ok_to_delegate I proposed
in the last e-mail.

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