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 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 Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444