Date: Wed, 18 Jul 2007 12:55:49 -0400
From: Nalin Dahyabhai <nalin@redhat.com>
To: rt@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #5596] patch for providing a way to set the ok-as-delegate flag
Message-ID: <20070718165548.GA16486@redhat.com>
References: <rt-5596-23966.5.85682965330264@krbdev.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <rt-5596-23966.5.85682965330264@krbdev.mit.edu>
Organization: Red Hat, Inc.
User-Agent: Mutt/1.5.16 (2007-06-09)
RT-Send-Cc: 
Content-Length: 2066

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