Forwarded credentials are cached and reused on Mac - is it acceptable?

[Srinivas Cheruku]

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.

[Srinivas Cheruku] Sorry, I included krbdev thinking that some apple
Kerberos developers might be looking at this list and might realize that the
code needs to be improved.

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.

[Srinivas Cheruku] According to http://pondini.org/OSX/BugReport.html in
order to report a bug you need to be a registered OSX developer. I am not a
registered OSX developer, as I don't think I  need to be. I am just trying
to use OSX as a client with my web server and find this issue and wanted to
get this issue to a large number of people, so that they can advise me.
Hopefully, some one from apple might have seen this.

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.

[Srinivas Cheruku] yes, that's the way to go forward if you are very much
concerned about getting forwarded tgt each time over the network. Generally
the forwarded tgt is needed on the initial authentication and later in most
web applications an application specific cookie would be used to identify
that the user has authenticated.

> 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.

[Srinivas Cheruku] The authentication is done once on the initial request
and on successful authentication a cookie is created which is then used in
each request. But if you close the browser and open the browser again, the
HTTP Negotiate authentication takes place which requires getting forwarded
tgt but this is ok as the user would close only when he is done with his
work.

> 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.

[Srinivas Cheruku] I need to delegate the user credentials so that webserver
in turn can act on the user's behalf and so I need to forward the
credentials.

> 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.

[Srinivas Cheruku] Glad to know that you are also of the same opinion.

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.

 [Srinivas Cheruku] I have seen many programs/applications getting the
forwarded ticket whenever it is required and didn't see any application
until now that reuses the KRB_CRED message. 
There can be some benefit to reuse the forwarded ticket if the application
has to send the ticket many times in a day. I am not very sure that you
could modify other server's AP-REQ if you have use the same forwarded ticket
as AP-REQ are not encrypted using the session key from the forwarded ticket
but use the session key from the service ticket from that server - maybe I
might be overlooking something??
Anyway, I don't see any major issues in using the forwarded ticket as such,
but you cannot reuse the same KRB_CRED structure.
Thank you very much for your time and reply.