[krbdev.mit.edu #3206] gss_acquire_cred with GSS_C_BOTH or GSS_C_INITIATE should work with keytab creds

[pcmoore@sandia.gov via RT]

Sam Hartman (see below) suggested I report this as a bug. It has been
there
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
fourth paragraph.

Severity:  
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:hartmans at mit.edu] 
> Sent: Tuesday, October 04, 2005 3:15 PM
> To: Moore, Patrick
> Cc: krbdev at MIT.EDU
> Subject: Re: gss_acquire_cred with GSS_C_BOTH usage option
> 
> >>>>> "Moore," == Moore, Patrick <pcmoore at sandia.gov> 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 krb5-bugs at mit.edu.  Please 
> include a RFC 1964 reference.
> 
> --Sam
> 
> 
>