Forwarded credentials are cached and reused on Mac - is it acceptable?
Greg Hudson
ghudson at MIT.EDU
Tue Feb 4 11:02:17 EST 2014
I have removed krbdev at mit.edu from the CC line. The krbdev list is for
discussion of MIT krb5 development only, and this question has to do
with Heimdal/OSX code. Also, please do not send mail to krbdev and
kerberos at the same time.
On 02/04/2014 08:04 AM, Srinivas Cheruku wrote:
> kret = krb5_cc_get_config(context, ccache,
> name, "gss-forward-cache", fwd_data);
> if (kret) {
This code appears to be specific to OS X; the string "gss-forward-cache"
doesn't appear in upstream Heimdal. I would suggest opening a support
request with Apple.
If I were them, I would think about caching the to-be-forwarded ticket,
but making a new KRB-CRED message each time, since that part doesn't
require a KDC request.
> The user is able to authenticate and forward the credentials when Mozilla on
> Redhat is used (which is using MIT Kerberos) and we found that the forwarded
> credentials are requested every time as per RFC.
I will note that this can be pretty slow if you're making a lot of HTTP
requests for the same web page.
> Does anybody know how to make Mac OSX work better with HTTP Negotiate
> protocol ?
Do you actually need to delegate a TGT to the web server? Does the web
server only need to authenticate the user, or does it need to be able to
act on the user's behalf to anothe server? If it only needs to
authenticate the server, turn off delegation on the client. You'll get
better performance, better security, and you'll work around this caching
problem.
> Do you think it is acceptable to reuse the forwarded credentials?
Reusing the whole KRB-CRED message is probably not a good idea. Not
only does it expire after five minutes, but some server implementations
will throw a replay cache failure if you reuse one.
It's not clear whether it's okay to reuse the to-be-forwarded ticket.
In theory, if you're delegating TGTs to multiple different servers, you
get might some benefit out of each one having a different session key,
so that one server can't eavesdrop on or modify another server's
AP-REQs. But it's not clear whether this benefit is worthwhile, since
you're giving each server the ability to act on your behalf in arbitrary
ways anyway.
More information about the Kerberos
mailing list