[krbdev.mit.edu #3206] gss_acquire_cred with GSS_C_BOTH or GSS_C_INITIATE should work with keytab creds
Sam Hartman (see below) suggested I report this as a bug. It has been
for a long time, and I understand Heimdal does not have this problem.
Synopsis: When a cred cache is not available, and a keytab cred is
available, gss_acquire_cred should obtain an initiator cred cache
based on the keytab cred when GSS_C_BOTH or GSS_C_INITIATE flag is set.
See RFC 1964, June 1996, Section 3
Probably not high, because there is
a somewhat kludgy workaround that many of us use:
run a cron or background process that repeatedly generates a
cred cache from a keytab.
(e.g., "kinit -k -t" or API equivilent)
> -----Original Message-----
> From: Sam Hartman [mailto:[hidden email]]
> Sent: Tuesday, October 04, 2005 3:15 PM
> To: Moore, Patrick
> Cc: [hidden email] > Subject: Re: gss_acquire_cred with GSS_C_BOTH usage option
> >>>>> "Moore," == Moore, Patrick <[hidden email]> writes:
> Moore,> My reading of RFC1964, where it says . . .
> Moore,> "However, when the Kerberos 5 mechanism attempts to
> Moore,> obtain initiating credentials for a service principal
> Moore,> which are not available in a credentials cache, and the
> Moore,> key for that service principal is available in a Kerberos
> Moore,> 5 key table, the mechanism should use the service key to
> Moore,> obtain initiating credentials for that service."
> Moore,> ... implies that Heimdal has the right approach.
> You're completely right. Would you mind opening a bug by
> describing the problem in mail to [hidden email]. Please
> include a RFC 1964 reference.