Message-ID: <469E5571.1000406@anl.gov>
Date: Wed, 18 Jul 2007 13:01:21 -0500
From: "Douglas E. Engert" <deengert@anl.gov>
User-Agent: Thunderbird 1.5.0.12 (Windows/20070509)
MIME-Version: 1.0
To: rt@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #5596] patch for providing a way to set the	ok-as-delegate flag
References: <rt-5596-23967.17.4629938561882@krbdev.mit.edu>
In-Reply-To: <rt-5596-23967.17.4629938561882@krbdev.mit.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
RT-Send-Cc: 
Content-Length: 3351


nalin@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@mit.edu
> https://mailman.mit.edu/mailman/listinfo/krb5-bugs
> 
> 

-- 

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