TGS granting

[moore moore]

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

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

Thank you.


    On Wednesday 31 October 2018, 22:20:21 GMT, Derek Atkins <derek at ihtfp.com> wrote:  
 
 Hi,

The fact that the kerberized service itself is asking for refreshes isn't
important.  The proxy can cache the TGT and/or the service ticket on
behalf of the user session and can use that ticket for as long as it is
valid.. That service ticket can be valid for much longer than the
kerberized service will cache its session.  When that happens, the proxy
would re-submit the same service ticket with an updated authenticator
(proof-of-possession of the secret key in the ticket) to the kerberized
service.

The proxy will only need to refresh the service ticket when *IT* expires,
which can be set at the KDC or by the proxy its acquisition.  It's not
unusual for tickets to have lifetimes on the order of 24 hours or more.

So the way I see this process:

1) User "logs in" to proxy and presents their kerberos credentials (or the
proxy already has them, somehow).

2) Proxy goes to KDC, obtains TGT and Service Ticket for Kerberized Service

3) Proxy uses service ticket for as long as required.

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.

5) When the service ticket expires, the client session is destroyed and
only THEN would the proxy ask the user to re-authenticate.

Hope this helps!

-derek

On Wed, October 31, 2018 6:02 pm, moore moore wrote:
>  Thanks for reply and info.I follow you in relation to the TGT being
> required at the TGS on the KDC.So I think you are indicating that there
> is no short cut available.
>
> Just to note that the clients are not using kerberos. Hence the
> intermediate process on the proxy having a user enabled for delegation.
> The proxy can cache the service tickets ( it has sessions associated with
> the clients), but the kerberized server on the backend, will force re
> authentications (too) frequently by issuing of the 401s.
> btw, does it take multiple TGS_REQs/TGS_RSPs to establish a security
> context? Or should it happen with a single TGS_REQ/TGS_RSP?
> Thank you.
>
>
>
>    On Wednesday 31 October 2018, 16:00:50 GMT, Benjamin Kaduk
> <kaduk at mit.edu> wrote:
>
>  On Wed, Oct 31, 2018 at 02:36:39PM +0000, moore moore wrote:
>> Hello,I hope I have the correct forum for some guidance.
>> I have the following scenario:
>> Clients(generally web based), linux proxy and windows server farm.The
>> proxy is configured with a user that is configured for kerberos
>> constrained delegation.A TGT is granted for this user with delegation
>> enabled.
>>
>> TGS are also granted and everything works OK.
>>
>> However I have a resource utilization problem on the proxy where the
>> windows servers are frequently requesting re authorization with 401
>> Negotiate.
>>
>> This causes and intermediate process on the proxy to contact the KDC for
>> new TGS.
>> Is there a way for the intermediate process to generate service tickets
>> without having to go to the KDC? It already has the TGT.
>> Or is a round trip to the KDC ( Windows AD) always required to get
>> service tickets?
>
> The TGT is used to authenticate to the TGS so that the TGS can issue
> service tickets; the TGT alone is not enough to produce service tickets.
>
>> Due to the connection behavior, there are very many TGS_REQs on the
>> wire.
>> Is there any way to optimize this behavior and avoid so much traffic
>> back and forth to the KDC for TGS_REQ/TGS_RSP.
>
> Are the 401 Negotiates doing credential delegation or just authentication?
> For authentication the clients should be able to cache service tickets and
> reuse them, without need for a TGS exchange for every HTTP authentication.
>
> -Ben
>
> _______________________________________________
> krbdev mailing list            krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev
>


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