TGS granting

[Derek Atkins]

moore moore <moore_chestnut at yahoo.ie> writes:

> This is really helpful and makes alot of sense. Thank you for the detailed
> info.
>
> So in relation to:
> "4) If the service requests updated authentication (401) the proxy can
> refresh by re-running the Application authentication protocol using the
> cached service ticket.  This can continue until the service ticket
> expires."
>
> By "Application authentication protocol", do you mean TGS_REQ/RSP to the KDC?

No, I mean the AP_REQ/AP_REP between the Kerberos Client and the
Kerberized Server.

> On the proxy, there is an application process ( using the kerberos lib) and
> the TGT is cached in kerberos credential cache. All this is fine.
> The service ticket is cached in an application level process.

Right, that would be caching the TGS_REQ/TGS_REP from the KDC.  This
caching should be valid for ~24 hours, depending on how long the service
ticket is valid for.

> But I get very little use out of the cached service ticket, due to the demand
> and frequency of the 401s.
> When the 401 happens, ( in relation to your point 4), a series of TGS_REQ/RSP
> result on the wire between proxy and KDC. If I just use the cached ticket
> here, then it is just a crazy loop of 401s. That's why application process
> goes to KDC for new service ticket, which the kerberized service will accept,
> but then will quickly issue 401s again, thus resulting in having to go back to
> KDC again for new service ticket.

Have you verified that the service ticket is still valid?
Is there a time skew between the proxy (kerberos client) and the service?

> Is this the correct and only way for the proxy to "refresh" the service
> ticket?

No, you should be able to re-use the Service Ticket and just issue a new
AP_REQ/AP_REP between the proxy and the service.  Unless the problem is
that the proxy is caching *THIS* -- in which case yes, you're kind of
screwed.  Note that the AP_REQ/AP_REP is between the client and service,
and NOT with the KDC, so there is no reason that the client would need
to cache this.

> Thank you.

-derek
-- 
       Derek Atkins                 617-623-3745
       derek at ihtfp.com             www.ihtfp.com
       Computer and Internet Security Consultant