gss_acquire_cred with GSS_C_BOTH usage option

[Moore, Patrick]

My reading of RFC1964, where it says . . .

   "However, when the Kerberos 5 mechanism attempts to obtain initiating
   credentials for a service principal which are not available in a
   credentials cache, and the key for that service principal is
   available in a Kerberos 5 key table, the mechanism should use the
   service key to obtain initiating credentials for that service."

... implies that Heimdal has the right approach.

What we sometimes do here as a workaround is run a cron job or a
background process that continually acquires a cred cache from a keytab.
Then our keytab-based gssapi initiators work when asking for an
'initiator' or 'both' cred. 

>>sam> I see your point and I agree the Heimdal behavior is useful in
the
>>sam> case you describe.
>>sam> 
>>sam> However it seems to violate the principle of least surprise.  If
I
>>sam> change my application to start requesting initiator credentials
>>sam> instead of both credentials then initiator credentials can stop
>>sam> working if I don't have a current cache.
>>sam> 

nathan> Actually with Heimdal's code I don't think it will since it
tries to
nathan> fall back to the keytab whether you ask for initiator creds or
for 
nathan> both.  The application should still behave the same. 
  
>>sam> I'm not sure how to resolve these requirements.
>>sam> 
>>sam> --Sam
>>sam> 

-- 
Nathan Huff                            Nathan.Huff at ndsu.edu
<https://mailman.mit.edu/mailman/listinfo/krbdev> 
Information Technology Services        (701) 231-6145 (Voice)
Room 242H, IACC Building
North Dakota State University, Fargo, ND 58105-5164