TGS granting

[Derek Atkins]

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