TGS granting

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

TGS granting

moore moore
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?
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.
Appreciate any guidance.

Thank you.






_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: TGS granting

Benjamin Kaduk-2
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             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: TGS granting

moore moore
 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 <[hidden email]> 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             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: TGS granting

Derek Atkins-2
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
> <[hidden email]> 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             [hidden email]
> https://mailman.mit.edu/mailman/listinfo/krbdev
>


--
       Derek Atkins                 617-623-3745
       [hidden email]             www.ihtfp.com
       Computer and Internet Security Consultant

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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
> <[hidden email]> 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            [hidden email]
> https://mailman.mit.edu/mailman/listinfo/krbdev
>


--
      Derek Atkins                617-623-3745
      [hidden email]            www.ihtfp.com
      Computer and Internet Security Consultant

 
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: TGS granting

Derek Atkins-2
moore moore <[hidden email]> 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
       [hidden email]             www.ihtfp.com
       Computer and Internet Security Consultant
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: TGS granting

moore moore
 Hello Derek,Thanks again for the helpful information..
Time skew is not present and the service ticket is cached.

OK, so at the moment, everytime there is a 401 from the kerberised windows server, the application process (on the proxy), goes to the KDC.
In wireshark, this always shows as a TGS-REQ/TGS-RSP
I never see a AP-REQ/AP-RSP in the trace/wireshark.BUT, but looking the kerberos library logs, I see it mentioned there.And then I checked tcpdump and I see AP-REQ as a value in some of the TGS-REQs.

Sample kerb log below.

Here there is
- AS-REQ and pre auth requested for [hidden email] user.
- AS-REQ and RSP  for [hidden email] user.
- Sample TGS-REQ/RSP for [hidden email] ( can see AP-REQ) in log.
This is between proxy and KDC.So not sure, if I can get some data/token from this? and use between proxy and service.Which is over HTTP SPNEGO.

Is the sample code/api documentation you could refer me to so I could try understand how to build and use the AP-REQ?
Thank you for your time.


[14791] 1538167075.224560: Getting initial credentials for [hidden email]
[14791] 1538167075.225189: Looked up etypes in keytab: rc4-hmac
[14791] 1538167075.225577: Sending request (177 bytes) to TEST.COM
[14791] 1538167075.225915: Resolving hostname 172.21.162.211
[14791] 1538167075.226408: Sending initial UDP request to dgram 172.21.162.211:88
[14791] 1538167075.227366: Received answer (214 bytes) from dgram 172.21.162.211:88
[14791] 1538167075.228299: Response was not from master KDC
[14791] 1538167075.228471: Received error from KDC: -1765328359/Additional pre-authentication required
[14791] 1538167075.228653: Processing preauth types: 16, 15, 19, 2
[14791] 1538167075.228829: Selected etype info: etype rc4-hmac, salt "", params ""
[14791] 1538167075.229021: Retrieving [hidden email] from FILE:/etc/krb5.keytab (vno 0, enctype rc4-hmac) with result: 0/Success
[14791] 1538167075.229146: AS key obtained for encrypted timestamp: rc4-hmac/2163
[14791] 1538167075.229309: Encrypted timestamp (for 1538167075.859690): plain 301AA011180F32303138303932383230333735355AA10502030D1E2A, encrypted 717BCF6554C1F514AB6D86FB08D00E9BEA7EF1B56C6996DA76E0AB5D9812D5E0C4233E6DC88A7EEA6582FA5FDC22ADB86F95D178
[14791] 1538167075.229428: Preauth module encrypted_timestamp (2) (real) returned: 0/Success
[14791] 1538167075.229520: Produced preauth for next request: 2
[14791] 1538167075.229625: Sending request (251 bytes) to TEST.COM
[14791] 1538167075.229750: Resolving hostname 172.21.162.211
[14791] 1538167075.229923: Sending initial UDP request to dgram 172.21.162.211:88
[14791] 1538167075.230849: Received answer (98 bytes) from dgram 172.21.162.211:88
[14791] 1538167075.231488: Response was not from master KDC
[14791] 1538167075.231613: Received error from KDC: -1765328332/Response too big for UDP, retry with TCP
[14791] 1538167075.231736: Request or response is too big for UDP; retrying with TCP
[14791] 1538167075.231832: Sending request (251 bytes) to TEST.COM (tcp only)
[14791] 1538167075.231927: Resolving hostname 172.21.162.211
[14791] 1538167075.232095: Initiating TCP connection to stream 172.21.162.211:88
[14791] 1538167075.232374: Sending TCP request to stream 172.21.162.211:88
[14791] 1538167075.233225: Received answer (1548 bytes) from stream 172.21.162.211:88
[14791] 1538167075.233701: Response was not from master KDC
[14791] 1538167075.233829: Salt derived from principal: TEST.COMproxy
[14791] 1538167075.233933: AS key determined by preauth: rc4-hmac/2163
[14791] 1538167075.234083: Decrypted AS reply; session key is: rc4-hmac/FAF6
[14791] 1538167075.234202: FAST negotiation: unavailable
[14791] 1538167075.234328: Initializing FILE:/tmp/krb5cc_0 with default princ [hidden email]
[14791] 1538167075.234524: Removing [hidden email] -> krbtgt/[hidden email] from FILE:/tmp/krb5cc_0
[14791] 1538167075.234629: Storing [hidden email] -> krbtgt/[hidden email] in FILE:/tmp/krb5cc_0
[14791] 1538167075.234885: Storing config in FILE:/tmp/krb5cc_0 for krbtgt/[hidden email]: pa_type: 2
[14791] 1538167075.235039: Removing [hidden email] -> krb5_ccache_conf_data/pa_type/krbtgt\/TEST.COM\@TEST.COM@X-CACHECONF: from FILE:/tmp/krb5cc_0
[14791] 1538167075.235143: Storing [hidden email] -> krb5_ccache_conf_data/pa_type/krbtgt\/TEST.COM\@TEST.COM@X-CACHECONF: in FILE:/tmp/krb5cc_0
[14791] 1538167075.241199: Getting credentials [hidden email] -> [hidden email] using ccache FILE:/tmp/krb5cc_0
[14791] 1538167075.241446: Retrieving [hidden email] -> [hidden email] from FILE:/tmp/krb5cc_0 with result: -1765328243/Matching credential not found
[14791] 1538167075.241571: Getting credentials [hidden email] -> krbtgt/[hidden email] using ccache FILE:/tmp/krb5cc_0
[14791] 1538167075.241755: Retrieving [hidden email] -> krbtgt/[hidden email] from FILE:/tmp/krb5cc_0 with result: 0/Success
[14791] 1538167075.241886: Get cred via TGT krbtgt/[hidden email] after requesting [hidden email] (canonicalize on)
[14791] 1538167075.241986: Generated subkey for TGS request: rc4-hmac/86EA
[14791] 1538167075.242096: etypes requested in TGS request: aes256-cts, aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts
[14791] 1538167075.242257: Encoding request body and padata into FAST request
[14791] 1538167075.242433: Sending request (2176 bytes) to TEST.COM
[14791] 1538167075.242534: Resolving hostname 172.21.162.211
[14791] 1538167075.242729: Initiating TCP connection to stream 172.21.162.211:88
[14791] 1538167075.243002: Sending TCP request to stream 172.21.162.211:88
[14791] 1538167075.244768: Received answer (1842 bytes) from stream 172.21.162.211:88
[14791] 1538167075.245459: Response was not from master KDC
[14791] 1538167075.245556: Decoding FAST response
[14791] 1538167075.245748: FAST reply key: rc4-hmac/F069
[14791] 1538167075.245871: TGS reply is for [hidden email] -> [hidden email] with session key rc4-hmac/AEF0
[14791] 1538167075.245967: Got cred; 0/Success
[14791] 1538167075.246061: Resolving unique ccache of type MEMORY
[14791] 1538167075.246144: Initializing MEMORY:sAA7vI4 with default princ [hidden email]
[14791] 1538167075.246270: Removing [hidden email] -> krbtgt/[hidden email] from MEMORY:sAA7vI4
[14791] 1538167075.246347: Storing [hidden email] -> krbtgt/[hidden email] in MEMORY:sAA7vI4
[14791] 1538167075.246444: Removing [hidden email] -> krb5_ccache_conf_data/pa_type/krbtgt\/TEST.COM\@TEST.COM@X-CACHECONF: from MEMORY:sAA7vI4
[14791] 1538167075.246520: Storing [hidden email] -> krb5_ccache_conf_data/pa_type/krbtgt\/TEST.COM\@TEST.COM@X-CACHECONF: in MEMORY:sAA7vI4
[14791] 1538167075.246613: Storing config in MEMORY:sAA7vI4 for : proxy_impersonator: [hidden email]
[14791] 1538167075.246737: Removing [hidden email] -> krb5_ccache_conf_data/proxy_impersonator@X-CACHECONF: from MEMORY:sAA7vI4
[14791] 1538167075.246813: Storing [hidden email] -> krb5_ccache_conf_data/proxy_impersonator@X-CACHECONF: in MEMORY:sAA7vI4
[14791] 1538167075.246891: Removing [hidden email] -> [hidden email] from MEMORY:sAA7vI4
[14791] 1538167075.246963: Storing [hidden email] -> [hidden email] in MEMORY:sAA7vI4
[14791] 1538167075.247319: Getting credentials [hidden email] -> [hidden email] using ccache FILE:/tmp/krb5cc_0
[14791] 1538167075.247489: Retrieving [hidden email] -> [hidden email] from FILE:/tmp/krb5cc_0 with result: -1765328243/Matching credential not found
[14791] 1538167075.247576: Getting credentials [hidden email] -> krbtgt/[hidden email] using ccache FILE:/tmp/krb5cc_0
[14791] 1538167075.247758: Retrieving [hidden email] -> krbtgt/[hidden email] from FILE:/tmp/krb5cc_0 with result: 0/Success
[14791] 1538167075.247863: Get cred via TGT krbtgt/[hidden email] after requesting [hidden email] (canonicalize on)
[14791] 1538167075.247953: Generated subkey for TGS request: rc4-hmac/F169
[14791] 1538167075.248043: etypes requested in TGS request: aes256-cts, aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts
[14791] 1538167075.248184: Encoding request body and padata into FAST request
[14791] 1538167075.248353: Sending request (2176 bytes) to TEST.COM
[14791] 1538167075.248448: Resolving hostname 172.21.162.211
[14791] 1538167075.248605: Initiating TCP connection to stream 172.21.162.211:88
[14791] 1538167075.248931: Sending TCP request to stream 172.21.162.211:88
[14791] 1538167075.250602: Received answer (1842 bytes) from stream 172.21.162.211:88
[14791] 1538167075.251358: Response was not from master KDC
[14791] 1538167075.251478: Decoding FAST response
[14791] 1538167075.251629: FAST reply key: rc4-hmac/E50D
[14791] 1538167075.251805: TGS reply is for [hidden email] -> [hidden email] with session key rc4-hmac/F1B4
[14791] 1538167075.251901: Got cred; 0/Success
[14791] 1538167075.251999: Resolving unique ccache of type MEMORY
[14791] 1538167075.252080: Initializing MEMORY:2zEVGbO with default princ [hidden email]
[14791] 1538167075.252202: Removing [hidden email] -> krbtgt/[hidden email] from MEMORY:2zEVGbO
[14791] 1538167075.252276: Storing [hidden email] -> krbtgt/[hidden email] in MEMORY:2zEVGbO
[14791] 1538167075.252371: Removing [hidden email] -> krb5_ccache_conf_data/pa_type/krbtgt\/TEST.COM\@TEST.COM@X-CACHECONF: from MEMORY:2zEVGbO
[14791] 1538167075.252448: Storing [hidden email] -> krb5_ccache_conf_data/pa_type/krbtgt\/TEST.COM\@TEST.COM@X-CACHECONF: in MEMORY:2zEVGbO
[14791] 1538167075.252538: Storing config in MEMORY:2zEVGbO for : proxy_impersonator: [hidden email]
[14791] 1538167075.252614: Removing [hidden email] -> krb5_ccache_conf_data/proxy_impersonator@X-CACHECONF: from MEMORY:2zEVGbO
[14791] 1538167075.252721: Storing [hidden email] -> krb5_ccache_conf_data/proxy_impersonator@X-CACHECONF: in MEMORY:2zEVGbO
[14791] 1538167075.252802: Removing [hidden email] -> [hidden email] from MEMORY:2zEVGbO
[14791] 1538167075.252873: Storing [hidden email] -> [hidden email] in MEMORY:2zEVGbO
[14791] 1538167075.253224: Getting credentials [hidden email] -> [hidden email] using ccache FILE:/tmp/krb5cc_0
[14791] 1538167075.253394: Retrieving [hidden email] -> [hidden email] from FILE:/tmp/krb5cc_0 with result: -1765328243/Matching credential not found
[14791] 1538167075.253482: Getting credentials [hidden email] -> krbtgt/[hidden email] using ccache FILE:/tmp/krb5cc_0
[14791] 1538167075.253634: Retrieving [hidden email] -> krbtgt/[hidden email] from FILE:/tmp/krb5cc_0 with result: 0/Success
[14791] 1538167075.253798: Get cred via TGT krbtgt/[hidden email] after requesting [hidden email] (canonicalize on)
[14791] 1538167075.253893: Generated subkey for TGS request: rc4-hmac/0FA7
[14791] 1538167075.253985: etypes requested in TGS request: aes256-cts, aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts
[14791] 1538167075.254128: Encoding request body and padata into FAST request
[14791] 1538167075.254285: Sending request (2176 bytes) to TEST.COM
[14791] 1538167075.254380: Resolving hostname 172.21.162.211
[14791] 1538167075.254531: Initiating TCP connection to stream 172.21.162.211:88
[14791] 1538167075.254767: Sending TCP request to stream 172.21.162.211:88
[14791] 1538167075.256452: Received answer (1842 bytes) from stream 172.21.162.211:88
[14791] 1538167075.257177: Response was not from master KDC
[14791] 1538167075.257272: Decoding FAST response
[14791] 1538167075.257422: FAST reply key: rc4-hmac/F998
[14791] 1538167075.257538: TGS reply is for [hidden email] -> [hidden email] with session key rc4-hmac/6958
[14791] 1538167075.257633: Got cred; 0/Success
[14791] 1538167075.257759: Resolving unique ccache of type MEMORY
[14791] 1538167075.257845: Initializing MEMORY:mhj20wl with default princ [hidden email]
[14791] 1538167075.257968: Removing [hidden email] -> krbtgt/[hidden email] from MEMORY:mhj20wl
[14791] 1538167075.258044: Storing [hidden email] -> krbtgt/[hidden email] in MEMORY:mhj20wl
[14791] 1538167075.258140: Removing [hidden email] -> krb5_ccache_conf_data/pa_type/krbtgt\/TEST.COM\@TEST.COM@X-CACHECONF: from MEMORY:mhj20wl
[14791] 1538167075.258224: Storing [hidden email] -> krb5_ccache_conf_data/pa_type/krbtgt\/TEST.COM\@TEST.COM@X-CACHECONF: in MEMORY:mhj20wl
[14791] 1538167075.258330: Storing config in MEMORY:mhj20wl for : proxy_impersonator: [hidden email]
[14791] 1538167075.258407: Removing [hidden email] -> krb5_ccache_conf_data/proxy_impersonator@X-CACHECONF: from MEMORY:mhj20wl
[14791] 1538167075.258478: Storing [hidden email] -> krb5_ccache_conf_data/proxy_impersonator@X-CACHECONF: in MEMORY:mhj20wl
[14791] 1538167075.258552: Removing [hidden email] -> [hidden email] from MEMORY:mhj20wl
[14791] 1538167075.258623: Storing [hidden email] -> [hidden email] in MEMORY:mhj20wl
[14791] 1538167075.258994: Getting credentials [hidden email] -> [hidden email] using ccache FILE:/tmp/krb5cc_0
[14791] 1538167075.259163: Retrieving [hidden email] -> [hidden email] from FILE:/tmp/krb5cc_0 with result: -1765328243/Matching credential not found
[14791] 1538167075.259251: Getting credentials [hidden email] -> krbtgt/[hidden email] using ccache FILE:/tmp/krb5cc_0
[14791] 1538167075.259403: Retrieving [hidden email] -> krbtgt/[hidden email] from FILE:/tmp/krb5cc_0 with result: 0/Success
[14791] 1538167075.259503: Get cred via TGT krbtgt/[hidden email] after requesting [hidden email] (canonicalize on)
[14791] 1538167075.259593: Generated subkey for TGS request: rc4-hmac/1E3B
[14791] 1538167075.259709: etypes requested in TGS request: aes256-cts, aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts
[14791] 1538167075.259860: Encoding request body and padata into FAST request
[14791] 1538167075.260017: Sending request (2176 bytes) to TEST.COM
[14791] 1538167075.260113: Resolving hostname 172.21.162.211
[14791] 1538167075.260264: Initiating TCP connection to stream 172.21.162.211:88
[14791] 1538167075.260492: Sending TCP request to stream 172.21.162.211:88
[14791] 1538167075.262157: Received answer (1842 bytes) from stream 172.21.162.211:88
[14791] 1538167075.263296: Response was not from master KDC
[14791] 1538167075.263396: Decoding FAST response
[14791] 1538167075.263545: FAST reply key: rc4-hmac/C06A
[14791] 1538167075.263659: TGS reply is for [hidden email] -> [hidden email] with session key rc4-hmac/A45B
[14791] 1538167075.263783: Got cred; 0/Success
[14791] 1538167075.263873: Resolving unique ccache of type MEMORY
[14791] 1538167075.263951: Initializing MEMORY:KH07w0C with default princ [hidden email]
[14791] 1538167075.264079: Removing [hidden email] -> krbtgt/[hidden email] from MEMORY:KH07w0C
[14791] 1538167075.264156: Storing [hidden email] -> krbtgt/[hidden email] in MEMORY:KH07w0C
[14791] 1538167075.264252: Removing [hidden email] -> krb5_ccache_conf_data/pa_type/krbtgt\/TEST.COM\@TEST.COM@X-CACHECONF: from MEMORY:KH07w0C
[14791] 1538167075.264320: Storing [hidden email] -> krb5_ccache_conf_data/pa_type/krbtgt\/TEST.COM\@TEST.COM@X-CACHECONF: in MEMORY:KH07w0C
[14791] 1538167075.264398: Storing config in MEMORY:KH07w0C for : proxy_impersonator: [hidden email]
[14791] 1538167075.264464: Removing [hidden email] -> krb5_ccache_conf_data/proxy_impersonator@X-CACHECONF: from MEMORY:KH07w0C
[14791] 1538167075.264523: Storing [hidden email] -> krb5_ccache_conf_data/proxy_impersonator@X-CACHECONF: in MEMORY:KH07w0C
[14791] 1538167075.264588: Removing [hidden email] -> [hidden email] from MEMORY:KH07w0C
[14791] 1538167075.264648: Storing [hidden email] -> [hidden email] in MEMORY:KH07w0C
[14791] 1538167075.265171: Getting credentials [hidden email] -> [hidden email] using ccache MEMORY:sAA7vI4
[14791] 1538167075.265276: Retrieving [hidden email] -> [hidden email] from MEMORY:sAA7vI4 with result: 0/Success
[14791] 1538167075.265424: Creating authenticator for [hidden email] -> [hidden email], seqnum 774377519, subkey rc4-hmac/46AC, session key rc4-hmac/AEF0
[14791] 1538167075.265952: Decrypted AP-REQ with server principal [hidden email]: rc4-hmac/2163
[14791] 1538167075.266046: AP-REQ ticket: [hidden email] -> [hidden email], session key rc4-hmac/AEF0
[14791] 1538167075.266387: Negotiated enctype based on authenticator: rc4-hmac
[14791] 1538167075.266462: Authenticator contains subkey: rc4-hmac/46AC
[14791] 1538167075.266554: Resolving unique ccache of type MEMORY
[14791] 1538167075.266631: Initializing MEMORY:narfKr4 with default princ [hidden email]
[14791] 1538167075.266831: Removing [hidden email] -> krbtgt/[hidden email] from MEMORY:narfKr4
[14791] 1538167075.266921: Storing [hidden email] -> krbtgt/[hidden email] in MEMORY:narfKr4
[14791] 1538167075.267043: Removing [hidden email] -> krb5_ccache_conf_data/pa_type/krbtgt\/TEST.COM\@TEST.COM@X-CACHECONF: from MEMORY:narfKr4
[14791] 1538167075.267137: Storing [hidden email] -> krb5_ccache_conf_data/pa_type/krbtgt\/TEST.COM\@TEST.COM@X-CACHECONF: in MEMORY:narfKr4
[14791] 1538167075.267223: Storing config in MEMORY:narfKr4 for : proxy_impersonator: [hidden email]
[14791] 1538167075.267292: Removing [hidden email] -> krb5_ccache_conf_data/proxy_impersonator@X-CACHECONF: from MEMORY:narfKr4
[14791] 1538167075.267352: Storing [hidden email] -> krb5_ccache_conf_data/proxy_impersonator@X-CACHECONF: in MEMORY:narfKr4
[14791] 1538167075.267419: Removing [hidden email] -> [hidden email] from MEMORY:narfKr4
[14791] 1538167075.267478: Storing [hidden email] -> [hidden email] in MEMORY:narfKr4
[14791] 1538167075.268760: Retrieving [hidden email] -> [hidden email] from MEMORY:narfKr4 with result: 0/Success
[14791] 1538167075.268838: Getting credentials [hidden email] -> http/[hidden email] using ccache MEMORY:narfKr4
[14791] 1538167075.268942: Retrieving [hidden email] -> krbtgt/[hidden email] from MEMORY:narfKr4 with result: 0/Success
[14791] 1538167075.269007: Starting with TGT for client realm: [hidden email] -> krbtgt/[hidden email]
[14791] 1538167075.269065: Requesting tickets for http/[hidden email], referrals on
[14791] 1538167075.269139: Generated subkey for TGS request: rc4-hmac/68E3
[14791] 1538167075.269221: etypes requested in TGS request: aes256-cts, aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts
[14791] 1538167075.269369: Encoding request body and padata into FAST request
[14791] 1538167075.269577: Sending request (4026 bytes) to TEST.COM
[14791] 1538167075.269685: Resolving hostname 172.21.162.211
[14791] 1538167075.269846: Initiating TCP connection to stream 172.21.162.211:88
[14791] 1538167075.270110: Sending TCP request to stream 172.21.162.211:88
[14791] 1538167075.272750: Received answer (1932 bytes) from stream 172.21.162.211:88
[14791] 1538167075.273519: Response was not from master KDC
[14791] 1538167075.273623: Decoding FAST response
[14791] 1538167075.273844: FAST reply key: rc4-hmac/25D0
[14791] 1538167075.273980: TGS reply is for [hidden email] -> http/[hidden email] with session key aes256-cts/81DC
[14791] 1538167075.274086: TGS request result: 0/Success
[14791] 1538167075.274161: Received creds for desired service http/[hidden email]
[14791] 1538167075.274236: Removing [hidden email] -> http/[hidden email] from MEMORY:narfKr4
[14791] 1538167075.274310: Storing [hidden email] -> http/[hidden email] in MEMORY:narfKr4
[14791] 1538167075.274464: Creating authenticator for [hidden email] -> http/[hidden email], seqnum 1049723237, subkey aes256-cts/323A, session key aes256-cts/81DC
[14791] 1538167075.275185: Destroying ccache MEMORY:narfKr4
[14791] 1538167075.275320: Destroying ccache MEMORY:sAA7vI4
[14791] 1538167075.275477: Destroying ccache MEMORY:2zEVGbO
[14791] 1538167075.275631: Destroying ccache MEMORY:mhj20wl
[14791] 1538167075.275851: Destroying ccache MEMORY:KH07w0C






    On Monday 5 November 2018, 15:56:23 GMT, Derek Atkins <[hidden email]> wrote:  
 
 moore moore <[hidden email]> 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
      [hidden email]            www.ihtfp.com
      Computer and Internet Security Consultant
 
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: TGS granting

moore moore
 Hello Derek,
After some further research, if I understand a bit better, the AP request between proxy and service is being delivered over SPNEGO.It is incorrect to think that it would have been explicitly visible in the trace between proxy and KDC, since it will be in the HTTP request from proxy to server.
Maybe the following is the reason I get so many 401 reauths from the server:
From 3.2.2.  Generation of a KRB_AP_REQ Message in RFC4120
"Authenticators MUST NOT be re-used and SHOULD be rejected if replayed to a server."

So if I understand based on your previous info also, would the following be on the correct path:
- cache the service ticket- on reauths, generate new authenticator and reuse a cached service ticket- somehow encapsulate the service ticket and NEW authenticator into AP REQ- deliver over SPNEGO to the server on kerberised server.- thus eliminating the need for excessive round trips from proxy to KDC
If this is practical, I will try figure out the kerb library API.
Appreciate your help.

   On Tuesday 6 November 2018, 23:12:00 GMT, moore moore <[hidden email]> wrote:  
 
  Hello Derek,Thanks again for the helpful information..
Time skew is not present and the service ticket is cached.

OK, so at the moment, everytime there is a 401 from the kerberised windows server, the application process (on the proxy), goes to the KDC.
In wireshark, this always shows as a TGS-REQ/TGS-RSP
I never see a AP-REQ/AP-RSP in the trace/wireshark.BUT, but looking the kerberos library logs, I see it mentioned there.And then I checked tcpdump and I see AP-REQ as a value in some of the TGS-REQs.

Sample kerb log below.

Here there is
- AS-REQ and pre auth requested for [hidden email] user.
- AS-REQ and RSP  for [hidden email] user.
- Sample TGS-REQ/RSP for [hidden email] ( can see AP-REQ) in log.
This is between proxy and KDC.So not sure, if I can get some data/token from this? and use between proxy and service.Which is over HTTP SPNEGO.

Is the sample code/api documentation you could refer me to so I could try understand how to build and use the AP-REQ?
Thank you for your time.


[14791] 1538167075.224560: Getting initial credentials for [hidden email]
[14791] 1538167075.225189: Looked up etypes in keytab: rc4-hmac
[14791] 1538167075.225577: Sending request (177 bytes) to TEST.COM
[14791] 1538167075.225915: Resolving hostname 172.21.162.211
[14791] 1538167075.226408: Sending initial UDP request to dgram 172.21.162.211:88
[14791] 1538167075.227366: Received answer (214 bytes) from dgram 172.21.162.211:88
[14791] 1538167075.228299: Response was not from master KDC
[14791] 1538167075.228471: Received error from KDC: -1765328359/Additional pre-authentication required
[14791] 1538167075.228653: Processing preauth types: 16, 15, 19, 2
[14791] 1538167075.228829: Selected etype info: etype rc4-hmac, salt "", params ""
[14791] 1538167075.229021: Retrieving [hidden email] from FILE:/etc/krb5.keytab (vno 0, enctype rc4-hmac) with result: 0/Success
[14791] 1538167075.229146: AS key obtained for encrypted timestamp: rc4-hmac/2163
[14791] 1538167075.229309: Encrypted timestamp (for 1538167075.859690): plain 301AA011180F32303138303932383230333735355AA10502030D1E2A, encrypted 717BCF6554C1F514AB6D86FB08D00E9BEA7EF1B56C6996DA76E0AB5D9812D5E0C4233E6DC88A7EEA6582FA5FDC22ADB86F95D178
[14791] 1538167075.229428: Preauth module encrypted_timestamp (2) (real) returned: 0/Success
[14791] 1538167075.229520: Produced preauth for next request: 2
[14791] 1538167075.229625: Sending request (251 bytes) to TEST.COM
[14791] 1538167075.229750: Resolving hostname 172.21.162.211
[14791] 1538167075.229923: Sending initial UDP request to dgram 172.21.162.211:88
[14791] 1538167075.230849: Received answer (98 bytes) from dgram 172.21.162.211:88
[14791] 1538167075.231488: Response was not from master KDC
[14791] 1538167075.231613: Received error from KDC: -1765328332/Response too big for UDP, retry with TCP
[14791] 1538167075.231736: Request or response is too big for UDP; retrying with TCP
[14791] 1538167075.231832: Sending request (251 bytes) to TEST.COM (tcp only)
[14791] 1538167075.231927: Resolving hostname 172.21.162.211
[14791] 1538167075.232095: Initiating TCP connection to stream 172.21.162.211:88
[14791] 1538167075.232374: Sending TCP request to stream 172.21.162.211:88
[14791] 1538167075.233225: Received answer (1548 bytes) from stream 172.21.162.211:88
[14791] 1538167075.233701: Response was not from master KDC
[14791] 1538167075.233829: Salt derived from principal: TEST.COMproxy
[14791] 1538167075.233933: AS key determined by preauth: rc4-hmac/2163
[14791] 1538167075.234083: Decrypted AS reply; session key is: rc4-hmac/FAF6
[14791] 1538167075.234202: FAST negotiation: unavailable
[14791] 1538167075.234328: Initializing FILE:/tmp/krb5cc_0 with default princ [hidden email]
[14791] 1538167075.234524: Removing [hidden email] -> krbtgt/[hidden email] from FILE:/tmp/krb5cc_0
[14791] 1538167075.234629: Storing [hidden email] -> krbtgt/[hidden email] in FILE:/tmp/krb5cc_0
[14791] 1538167075.234885: Storing config in FILE:/tmp/krb5cc_0 for krbtgt/[hidden email]: pa_type: 2
[14791] 1538167075.235039: Removing [hidden email] -> krb5_ccache_conf_data/pa_type/krbtgt\/TEST.COM\@TEST.COM@X-CACHECONF: from FILE:/tmp/krb5cc_0
[14791] 1538167075.235143: Storing [hidden email] -> krb5_ccache_conf_data/pa_type/krbtgt\/TEST.COM\@TEST.COM@X-CACHECONF: in FILE:/tmp/krb5cc_0
[14791] 1538167075.241199: Getting credentials [hidden email] -> [hidden email] using ccache FILE:/tmp/krb5cc_0
[14791] 1538167075.241446: Retrieving [hidden email] -> [hidden email] from FILE:/tmp/krb5cc_0 with result: -1765328243/Matching credential not found
[14791] 1538167075.241571: Getting credentials [hidden email] -> krbtgt/[hidden email] using ccache FILE:/tmp/krb5cc_0
[14791] 1538167075.241755: Retrieving [hidden email] -> krbtgt/[hidden email] from FILE:/tmp/krb5cc_0 with result: 0/Success
[14791] 1538167075.241886: Get cred via TGT krbtgt/[hidden email] after requesting [hidden email] (canonicalize on)
[14791] 1538167075.241986: Generated subkey for TGS request: rc4-hmac/86EA
[14791] 1538167075.242096: etypes requested in TGS request: aes256-cts, aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts
[14791] 1538167075.242257: Encoding request body and padata into FAST request
[14791] 1538167075.242433: Sending request (2176 bytes) to TEST.COM
[14791] 1538167075.242534: Resolving hostname 172.21.162.211
[14791] 1538167075.242729: Initiating TCP connection to stream 172.21.162.211:88
[14791] 1538167075.243002: Sending TCP request to stream 172.21.162.211:88
[14791] 1538167075.244768: Received answer (1842 bytes) from stream 172.21.162.211:88
[14791] 1538167075.245459: Response was not from master KDC
[14791] 1538167075.245556: Decoding FAST response
[14791] 1538167075.245748: FAST reply key: rc4-hmac/F069
[14791] 1538167075.245871: TGS reply is for [hidden email] -> [hidden email] with session key rc4-hmac/AEF0
[14791] 1538167075.245967: Got cred; 0/Success
[14791] 1538167075.246061: Resolving unique ccache of type MEMORY
[14791] 1538167075.246144: Initializing MEMORY:sAA7vI4 with default princ [hidden email]
[14791] 1538167075.246270: Removing [hidden email] -> krbtgt/[hidden email] from MEMORY:sAA7vI4
[14791] 1538167075.246347: Storing [hidden email] -> krbtgt/[hidden email] in MEMORY:sAA7vI4
[14791] 1538167075.246444: Removing [hidden email] -> krb5_ccache_conf_data/pa_type/krbtgt\/TEST.COM\@TEST.COM@X-CACHECONF: from MEMORY:sAA7vI4
[14791] 1538167075.246520: Storing [hidden email] -> krb5_ccache_conf_data/pa_type/krbtgt\/TEST.COM\@TEST.COM@X-CACHECONF: in MEMORY:sAA7vI4
[14791] 1538167075.246613: Storing config in MEMORY:sAA7vI4 for : proxy_impersonator: [hidden email]
[14791] 1538167075.246737: Removing [hidden email] -> krb5_ccache_conf_data/proxy_impersonator@X-CACHECONF: from MEMORY:sAA7vI4
[14791] 1538167075.246813: Storing [hidden email] -> krb5_ccache_conf_data/proxy_impersonator@X-CACHECONF: in MEMORY:sAA7vI4
[14791] 1538167075.246891: Removing [hidden email] -> [hidden email] from MEMORY:sAA7vI4
[14791] 1538167075.246963: Storing [hidden email] -> [hidden email] in MEMORY:sAA7vI4
[14791] 1538167075.247319: Getting credentials [hidden email] -> [hidden email] using ccache FILE:/tmp/krb5cc_0
[14791] 1538167075.247489: Retrieving [hidden email] -> [hidden email] from FILE:/tmp/krb5cc_0 with result: -1765328243/Matching credential not found
[14791] 1538167075.247576: Getting credentials [hidden email] -> krbtgt/[hidden email] using ccache FILE:/tmp/krb5cc_0
[14791] 1538167075.247758: Retrieving [hidden email] -> krbtgt/[hidden email] from FILE:/tmp/krb5cc_0 with result: 0/Success
[14791] 1538167075.247863: Get cred via TGT krbtgt/[hidden email] after requesting [hidden email] (canonicalize on)
[14791] 1538167075.247953: Generated subkey for TGS request: rc4-hmac/F169
[14791] 1538167075.248043: etypes requested in TGS request: aes256-cts, aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts
[14791] 1538167075.248184: Encoding request body and padata into FAST request
[14791] 1538167075.248353: Sending request (2176 bytes) to TEST.COM
[14791] 1538167075.248448: Resolving hostname 172.21.162.211
[14791] 1538167075.248605: Initiating TCP connection to stream 172.21.162.211:88
[14791] 1538167075.248931: Sending TCP request to stream 172.21.162.211:88
[14791] 1538167075.250602: Received answer (1842 bytes) from stream 172.21.162.211:88
[14791] 1538167075.251358: Response was not from master KDC
[14791] 1538167075.251478: Decoding FAST response
[14791] 1538167075.251629: FAST reply key: rc4-hmac/E50D
[14791] 1538167075.251805: TGS reply is for [hidden email] -> [hidden email] with session key rc4-hmac/F1B4
[14791] 1538167075.251901: Got cred; 0/Success
[14791] 1538167075.251999: Resolving unique ccache of type MEMORY
[14791] 1538167075.252080: Initializing MEMORY:2zEVGbO with default princ [hidden email]
[14791] 1538167075.252202: Removing [hidden email] -> krbtgt/[hidden email] from MEMORY:2zEVGbO
[14791] 1538167075.252276: Storing [hidden email] -> krbtgt/[hidden email] in MEMORY:2zEVGbO
[14791] 1538167075.252371: Removing [hidden email] -> krb5_ccache_conf_data/pa_type/krbtgt\/TEST.COM\@TEST.COM@X-CACHECONF: from MEMORY:2zEVGbO
[14791] 1538167075.252448: Storing [hidden email] -> krb5_ccache_conf_data/pa_type/krbtgt\/TEST.COM\@TEST.COM@X-CACHECONF: in MEMORY:2zEVGbO
[14791] 1538167075.252538: Storing config in MEMORY:2zEVGbO for : proxy_impersonator: [hidden email]
[14791] 1538167075.252614: Removing [hidden email] -> krb5_ccache_conf_data/proxy_impersonator@X-CACHECONF: from MEMORY:2zEVGbO
[14791] 1538167075.252721: Storing [hidden email] -> krb5_ccache_conf_data/proxy_impersonator@X-CACHECONF: in MEMORY:2zEVGbO
[14791] 1538167075.252802: Removing [hidden email] -> [hidden email] from MEMORY:2zEVGbO
[14791] 1538167075.252873: Storing [hidden email] -> [hidden email] in MEMORY:2zEVGbO
[14791] 1538167075.253224: Getting credentials [hidden email] -> [hidden email] using ccache FILE:/tmp/krb5cc_0
[14791] 1538167075.253394: Retrieving [hidden email] -> [hidden email] from FILE:/tmp/krb5cc_0 with result: -1765328243/Matching credential not found
[14791] 1538167075.253482: Getting credentials [hidden email] -> krbtgt/[hidden email] using ccache FILE:/tmp/krb5cc_0
[14791] 1538167075.253634: Retrieving [hidden email] -> krbtgt/[hidden email] from FILE:/tmp/krb5cc_0 with result: 0/Success
[14791] 1538167075.253798: Get cred via TGT krbtgt/[hidden email] after requesting [hidden email] (canonicalize on)
[14791] 1538167075.253893: Generated subkey for TGS request: rc4-hmac/0FA7
[14791] 1538167075.253985: etypes requested in TGS request: aes256-cts, aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts
[14791] 1538167075.254128: Encoding request body and padata into FAST request
[14791] 1538167075.254285: Sending request (2176 bytes) to TEST.COM
[14791] 1538167075.254380: Resolving hostname 172.21.162.211
[14791] 1538167075.254531: Initiating TCP connection to stream 172.21.162.211:88
[14791] 1538167075.254767: Sending TCP request to stream 172.21.162.211:88
[14791] 1538167075.256452: Received answer (1842 bytes) from stream 172.21.162.211:88
[14791] 1538167075.257177: Response was not from master KDC
[14791] 1538167075.257272: Decoding FAST response
[14791] 1538167075.257422: FAST reply key: rc4-hmac/F998
[14791] 1538167075.257538: TGS reply is for [hidden email] -> [hidden email] with session key rc4-hmac/6958
[14791] 1538167075.257633: Got cred; 0/Success
[14791] 1538167075.257759: Resolving unique ccache of type MEMORY
[14791] 1538167075.257845: Initializing MEMORY:mhj20wl with default princ [hidden email]
[14791] 1538167075.257968: Removing [hidden email] -> krbtgt/[hidden email] from MEMORY:mhj20wl
[14791] 1538167075.258044: Storing [hidden email] -> krbtgt/[hidden email] in MEMORY:mhj20wl
[14791] 1538167075.258140: Removing [hidden email] -> krb5_ccache_conf_data/pa_type/krbtgt\/TEST.COM\@TEST.COM@X-CACHECONF: from MEMORY:mhj20wl
[14791] 1538167075.258224: Storing [hidden email] -> krb5_ccache_conf_data/pa_type/krbtgt\/TEST.COM\@TEST.COM@X-CACHECONF: in MEMORY:mhj20wl
[14791] 1538167075.258330: Storing config in MEMORY:mhj20wl for : proxy_impersonator: [hidden email]
[14791] 1538167075.258407: Removing [hidden email] -> krb5_ccache_conf_data/proxy_impersonator@X-CACHECONF: from MEMORY:mhj20wl
[14791] 1538167075.258478: Storing [hidden email] -> krb5_ccache_conf_data/proxy_impersonator@X-CACHECONF: in MEMORY:mhj20wl
[14791] 1538167075.258552: Removing [hidden email] -> [hidden email] from MEMORY:mhj20wl
[14791] 1538167075.258623: Storing [hidden email] -> [hidden email] in MEMORY:mhj20wl
[14791] 1538167075.258994: Getting credentials [hidden email] -> [hidden email] using ccache FILE:/tmp/krb5cc_0
[14791] 1538167075.259163: Retrieving [hidden email] -> [hidden email] from FILE:/tmp/krb5cc_0 with result: -1765328243/Matching credential not found
[14791] 1538167075.259251: Getting credentials [hidden email] -> krbtgt/[hidden email] using ccache FILE:/tmp/krb5cc_0
[14791] 1538167075.259403: Retrieving [hidden email] -> krbtgt/[hidden email] from FILE:/tmp/krb5cc_0 with result: 0/Success
[14791] 1538167075.259503: Get cred via TGT krbtgt/[hidden email] after requesting [hidden email] (canonicalize on)
[14791] 1538167075.259593: Generated subkey for TGS request: rc4-hmac/1E3B
[14791] 1538167075.259709: etypes requested in TGS request: aes256-cts, aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts
[14791] 1538167075.259860: Encoding request body and padata into FAST request
[14791] 1538167075.260017: Sending request (2176 bytes) to TEST.COM
[14791] 1538167075.260113: Resolving hostname 172.21.162.211
[14791] 1538167075.260264: Initiating TCP connection to stream 172.21.162.211:88
[14791] 1538167075.260492: Sending TCP request to stream 172.21.162.211:88
[14791] 1538167075.262157: Received answer (1842 bytes) from stream 172.21.162.211:88
[14791] 1538167075.263296: Response was not from master KDC
[14791] 1538167075.263396: Decoding FAST response
[14791] 1538167075.263545: FAST reply key: rc4-hmac/C06A
[14791] 1538167075.263659: TGS reply is for [hidden email] -> [hidden email] with session key rc4-hmac/A45B
[14791] 1538167075.263783: Got cred; 0/Success
[14791] 1538167075.263873: Resolving unique ccache of type MEMORY
[14791] 1538167075.263951: Initializing MEMORY:KH07w0C with default princ [hidden email]
[14791] 1538167075.264079: Removing [hidden email] -> krbtgt/[hidden email] from MEMORY:KH07w0C
[14791] 1538167075.264156: Storing [hidden email] -> krbtgt/[hidden email] in MEMORY:KH07w0C
[14791] 1538167075.264252: Removing [hidden email] -> krb5_ccache_conf_data/pa_type/krbtgt\/TEST.COM\@TEST.COM@X-CACHECONF: from MEMORY:KH07w0C
[14791] 1538167075.264320: Storing [hidden email] -> krb5_ccache_conf_data/pa_type/krbtgt\/TEST.COM\@TEST.COM@X-CACHECONF: in MEMORY:KH07w0C
[14791] 1538167075.264398: Storing config in MEMORY:KH07w0C for : proxy_impersonator: [hidden email]
[14791] 1538167075.264464: Removing [hidden email] -> krb5_ccache_conf_data/proxy_impersonator@X-CACHECONF: from MEMORY:KH07w0C
[14791] 1538167075.264523: Storing [hidden email] -> krb5_ccache_conf_data/proxy_impersonator@X-CACHECONF: in MEMORY:KH07w0C
[14791] 1538167075.264588: Removing [hidden email] -> [hidden email] from MEMORY:KH07w0C
[14791] 1538167075.264648: Storing [hidden email] -> [hidden email] in MEMORY:KH07w0C
[14791] 1538167075.265171: Getting credentials [hidden email] -> [hidden email] using ccache MEMORY:sAA7vI4
[14791] 1538167075.265276: Retrieving [hidden email] -> [hidden email] from MEMORY:sAA7vI4 with result: 0/Success
[14791] 1538167075.265424: Creating authenticator for [hidden email] -> [hidden email], seqnum 774377519, subkey rc4-hmac/46AC, session key rc4-hmac/AEF0
[14791] 1538167075.265952: Decrypted AP-REQ with server principal [hidden email]: rc4-hmac/2163
[14791] 1538167075.266046: AP-REQ ticket: [hidden email] -> [hidden email], session key rc4-hmac/AEF0
[14791] 1538167075.266387: Negotiated enctype based on authenticator: rc4-hmac
[14791] 1538167075.266462: Authenticator contains subkey: rc4-hmac/46AC
[14791] 1538167075.266554: Resolving unique ccache of type MEMORY
[14791] 1538167075.266631: Initializing MEMORY:narfKr4 with default princ [hidden email]
[14791] 1538167075.266831: Removing [hidden email] -> krbtgt/[hidden email] from MEMORY:narfKr4
[14791] 1538167075.266921: Storing [hidden email] -> krbtgt/[hidden email] in MEMORY:narfKr4
[14791] 1538167075.267043: Removing [hidden email] -> krb5_ccache_conf_data/pa_type/krbtgt\/TEST.COM\@TEST.COM@X-CACHECONF: from MEMORY:narfKr4
[14791] 1538167075.267137: Storing [hidden email] -> krb5_ccache_conf_data/pa_type/krbtgt\/TEST.COM\@TEST.COM@X-CACHECONF: in MEMORY:narfKr4
[14791] 1538167075.267223: Storing config in MEMORY:narfKr4 for : proxy_impersonator: [hidden email]
[14791] 1538167075.267292: Removing [hidden email] -> krb5_ccache_conf_data/proxy_impersonator@X-CACHECONF: from MEMORY:narfKr4
[14791] 1538167075.267352: Storing [hidden email] -> krb5_ccache_conf_data/proxy_impersonator@X-CACHECONF: in MEMORY:narfKr4
[14791] 1538167075.267419: Removing [hidden email] -> [hidden email] from MEMORY:narfKr4
[14791] 1538167075.267478: Storing [hidden email] -> [hidden email] in MEMORY:narfKr4
[14791] 1538167075.268760: Retrieving [hidden email] -> [hidden email] from MEMORY:narfKr4 with result: 0/Success
[14791] 1538167075.268838: Getting credentials [hidden email] -> http/[hidden email] using ccache MEMORY:narfKr4
[14791] 1538167075.268942: Retrieving [hidden email] -> krbtgt/[hidden email] from MEMORY:narfKr4 with result: 0/Success
[14791] 1538167075.269007: Starting with TGT for client realm: [hidden email] -> krbtgt/[hidden email]
[14791] 1538167075.269065: Requesting tickets for http/[hidden email], referrals on
[14791] 1538167075.269139: Generated subkey for TGS request: rc4-hmac/68E3
[14791] 1538167075.269221: etypes requested in TGS request: aes256-cts, aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts
[14791] 1538167075.269369: Encoding request body and padata into FAST request
[14791] 1538167075.269577: Sending request (4026 bytes) to TEST.COM
[14791] 1538167075.269685: Resolving hostname 172.21.162.211
[14791] 1538167075.269846: Initiating TCP connection to stream 172.21.162.211:88
[14791] 1538167075.270110: Sending TCP request to stream 172.21.162.211:88
[14791] 1538167075.272750: Received answer (1932 bytes) from stream 172.21.162.211:88
[14791] 1538167075.273519: Response was not from master KDC
[14791] 1538167075.273623: Decoding FAST response
[14791] 1538167075.273844: FAST reply key: rc4-hmac/25D0
[14791] 1538167075.273980: TGS reply is for [hidden email] -> http/[hidden email] with session key aes256-cts/81DC
[14791] 1538167075.274086: TGS request result: 0/Success
[14791] 1538167075.274161: Received creds for desired service http/[hidden email]
[14791] 1538167075.274236: Removing [hidden email] -> http/[hidden email] from MEMORY:narfKr4
[14791] 1538167075.274310: Storing [hidden email] -> http/[hidden email] in MEMORY:narfKr4
[14791] 1538167075.274464: Creating authenticator for [hidden email] -> http/[hidden email], seqnum 1049723237, subkey aes256-cts/323A, session key aes256-cts/81DC
[14791] 1538167075.275185: Destroying ccache MEMORY:narfKr4
[14791] 1538167075.275320: Destroying ccache MEMORY:sAA7vI4
[14791] 1538167075.275477: Destroying ccache MEMORY:2zEVGbO
[14791] 1538167075.275631: Destroying ccache MEMORY:mhj20wl
[14791] 1538167075.275851: Destroying ccache MEMORY:KH07w0C






    On Monday 5 November 2018, 15:56:23 GMT, Derek Atkins <[hidden email]> wrote:  
 
 moore moore <[hidden email]> 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
      [hidden email]            www.ihtfp.com
      Computer and Internet Security Consultant
   
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: TGS granting

Derek Atkins-2
Hi,

moore moore <[hidden email]> writes:

> Hello Derek,
>
> After some further research, if I understand a bit better, the AP request
> between proxy and service is being delivered over SPNEGO.
> It is incorrect to think that it would have been explicitly visible in the
> trace between proxy and KDC, since it will be in the HTTP request from proxy
> to server.

Correct.

> Maybe the following is the reason I get so many 401 reauths from the server:
>
> From 3.2.2.  Generation of a KRB_AP_REQ Message in RFC4120
> "Authenticators MUST NOT be re-used and SHOULD be rejected if replayed to a
> server."
>
> So if I understand based on your previous info also, would the following be on
> the correct path:
> - cache the service ticket
> - on reauths, generate new authenticator and reuse a cached service ticket
> - somehow encapsulate the service ticket and NEW authenticator into AP REQ

The "generate new authenticator" *is* creating a new AP REQ -- so there
is no "somehow" here, doing the former is doing the latter, and
vice-versa.  If you create a new (as opposed to reusing a cached) AP REQ
then you are, by definition, creating a new authenticator.  It sounds
like the AP-REQ auth-data is being cached and reused.

> - deliver over SPNEGO to the server on kerberised server.
> - thus eliminating the need for excessive round trips from proxy to KDC
>
> If this is practical, I will try figure out the kerb library API.

Yes, this is exactly what I've been trying to explain that you need to do.

> Appreciate your help.

You're welcome.

> On Tuesday 6 November 2018, 23:12:00 GMT, moore moore
> <[hidden email]> wrote:
>
> Hello Derek,
> Thanks again for the helpful information..
>
> Time skew is not present and the service ticket is cached.
>
> OK, so at the moment, everytime there is a 401 from the kerberised windows
> server, the application process (on the proxy), goes to the KDC.
>
> In wireshark, this always shows as a TGS-REQ/TGS-RSP
>
> I never see a AP-REQ/AP-RSP in the trace/wireshark.
> BUT, but looking the kerberos library logs, I see it mentioned there.
> And then I checked tcpdump and I see AP-REQ as a value in some of the
> TGS-REQs.
>
> Sample kerb log below.
>
> Here there is
> - AS-REQ and pre auth requested for [hidden email] user.
> - AS-REQ and RSP for [hidden email] user.
> - Sample TGS-REQ/RSP for [hidden email] ( can see AP-REQ) in log.
>
> This is between proxy and KDC.
> So not sure, if I can get some data/token from this? and use between proxy and
> service.
> Which is over HTTP SPNEGO.
>
> Is the sample code/api documentation you could refer me to so I could try
> understand how to build and use the AP-REQ?
>
> Thank you for your time.
>
> [14791] 1538167075.224560: Getting initial credentials for [hidden email]
> [14791] 1538167075.225189: Looked up etypes in keytab: rc4-hmac
> [14791] 1538167075.225577: Sending request (177 bytes) to TEST.COM
> [14791] 1538167075.225915: Resolving hostname 172.21.162.211
> [14791] 1538167075.226408: Sending initial UDP request to dgram
> 172.21.162.211:88
> [14791] 1538167075.227366: Received answer (214 bytes) from dgram
> 172.21.162.211:88
> [14791] 1538167075.228299: Response was not from master KDC
> [14791] 1538167075.228471: Received error from KDC: -1765328359/Additional
> pre-authentication required
> [14791] 1538167075.228653: Processing preauth types: 16, 15, 19, 2
> [14791] 1538167075.228829: Selected etype info: etype rc4-hmac, salt "",
> params ""
> [14791] 1538167075.229021: Retrieving [hidden email] from
> FILE:/etc/krb5.keytab (vno 0, enctype rc4-hmac) with result: 0/Success
> [14791] 1538167075.229146: AS key obtained for encrypted timestamp: rc4-hmac/
> 2163
> [14791] 1538167075.229309: Encrypted timestamp (for 1538167075.859690): plain
> 301AA011180F32303138303932383230333735355AA10502030D1E2A, encrypted
> 717BCF6554C1F514AB6D86FB08D00E9BEA7EF1B56C6996DA76E0AB5D9812D5E0C4233E6DC88A7EEA6582FA5FDC22ADB86F95D178
> [14791] 1538167075.229428: Preauth module encrypted_timestamp (2) (real)
> returned: 0/Success
> [14791] 1538167075.229520: Produced preauth for next request: 2
> [14791] 1538167075.229625: Sending request (251 bytes) to TEST.COM
> [14791] 1538167075.229750: Resolving hostname 172.21.162.211
> [14791] 1538167075.229923: Sending initial UDP request to dgram
> 172.21.162.211:88
> [14791] 1538167075.230849: Received answer (98 bytes) from dgram
> 172.21.162.211:88
> [14791] 1538167075.231488: Response was not from master KDC
> [14791] 1538167075.231613: Received error from KDC: -1765328332/Response too
> big for UDP, retry with TCP
> [14791] 1538167075.231736: Request or response is too big for UDP; retrying
> with TCP
> [14791] 1538167075.231832: Sending request (251 bytes) to TEST.COM (tcp only)
> [14791] 1538167075.231927: Resolving hostname 172.21.162.211
> [14791] 1538167075.232095: Initiating TCP connection to stream
> 172.21.162.211:88
> [14791] 1538167075.232374: Sending TCP request to stream 172.21.162.211:88
> [14791] 1538167075.233225: Received answer (1548 bytes) from stream
> 172.21.162.211:88
> [14791] 1538167075.233701: Response was not from master KDC
> [14791] 1538167075.233829: Salt derived from principal: TEST.COMproxy
> [14791] 1538167075.233933: AS key determined by preauth: rc4-hmac/2163
> [14791] 1538167075.234083: Decrypted AS reply; session key is: rc4-hmac/FAF6
> [14791] 1538167075.234202: FAST negotiation: unavailable
> [14791] 1538167075.234328: Initializing FILE:/tmp/krb5cc_0 with default princ
> [hidden email]
> [14791] 1538167075.234524: Removing [hidden email] -> krbtgt/[hidden email]
> from FILE:/tmp/krb5cc_0
> [14791] 1538167075.234629: Storing [hidden email] -> krbtgt/[hidden email]
> in FILE:/tmp/krb5cc_0
> [14791] 1538167075.234885: Storing config in FILE:/tmp/krb5cc_0 for krbtgt/
> [hidden email]: pa_type: 2
> [14791] 1538167075.235039: Removing [hidden email] -> krb5_ccache_conf_data/
> pa_type/krbtgt\/TEST.COM\@TEST.COM@X-CACHECONF: from FILE:/tmp/krb5cc_0
> [14791] 1538167075.235143: Storing [hidden email] -> krb5_ccache_conf_data/
> pa_type/krbtgt\/TEST.COM\@TEST.COM@X-CACHECONF: in FILE:/tmp/krb5cc_0
> [14791] 1538167075.241199: Getting credentials [hidden email] ->
> [hidden email] using ccache FILE:/tmp/krb5cc_0
> [14791] 1538167075.241446: Retrieving [hidden email] -> [hidden email] from
> FILE:/tmp/krb5cc_0 with result: -1765328243/Matching credential not found
> [14791] 1538167075.241571: Getting credentials [hidden email] -> krbtgt/
> [hidden email] using ccache FILE:/tmp/krb5cc_0
> [14791] 1538167075.241755: Retrieving [hidden email] -> krbtgt/
> [hidden email] from FILE:/tmp/krb5cc_0 with result: 0/Success
> [14791] 1538167075.241886: Get cred via TGT krbtgt/[hidden email] after
> requesting [hidden email] (canonicalize on)
> [14791] 1538167075.241986: Generated subkey for TGS request: rc4-hmac/86EA
> [14791] 1538167075.242096: etypes requested in TGS request: aes256-cts,
> aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts
> [14791] 1538167075.242257: Encoding request body and padata into FAST request
> [14791] 1538167075.242433: Sending request (2176 bytes) to TEST.COM
> [14791] 1538167075.242534: Resolving hostname 172.21.162.211
> [14791] 1538167075.242729: Initiating TCP connection to stream
> 172.21.162.211:88
> [14791] 1538167075.243002: Sending TCP request to stream 172.21.162.211:88
> [14791] 1538167075.244768: Received answer (1842 bytes) from stream
> 172.21.162.211:88
> [14791] 1538167075.245459: Response was not from master KDC
> [14791] 1538167075.245556: Decoding FAST response
> [14791] 1538167075.245748: FAST reply key: rc4-hmac/F069
> [14791] 1538167075.245871: TGS reply is for [hidden email] ->
> [hidden email] with session key rc4-hmac/AEF0
> [14791] 1538167075.245967: Got cred; 0/Success
> [14791] 1538167075.246061: Resolving unique ccache of type MEMORY
> [14791] 1538167075.246144: Initializing MEMORY:sAA7vI4 with default princ
> [hidden email]
> [14791] 1538167075.246270: Removing [hidden email] -> krbtgt/[hidden email]
> from MEMORY:sAA7vI4
> [14791] 1538167075.246347: Storing [hidden email] -> krbtgt/[hidden email]
> in MEMORY:sAA7vI4
> [14791] 1538167075.246444: Removing [hidden email] -> krb5_ccache_conf_data/
> pa_type/krbtgt\/TEST.COM\@TEST.COM@X-CACHECONF: from MEMORY:sAA7vI4
> [14791] 1538167075.246520: Storing [hidden email] -> krb5_ccache_conf_data/
> pa_type/krbtgt\/TEST.COM\@TEST.COM@X-CACHECONF: in MEMORY:sAA7vI4
> [14791] 1538167075.246613: Storing config in MEMORY:sAA7vI4 for :
> proxy_impersonator: [hidden email]
> [14791] 1538167075.246737: Removing [hidden email] -> krb5_ccache_conf_data
> /proxy_impersonator@X-CACHECONF: from MEMORY:sAA7vI4
> [14791] 1538167075.246813: Storing [hidden email] -> krb5_ccache_conf_data/
> proxy_impersonator@X-CACHECONF: in MEMORY:sAA7vI4
> [14791] 1538167075.246891: Removing [hidden email] -> [hidden email] from
> MEMORY:sAA7vI4
> [14791] 1538167075.246963: Storing [hidden email] -> [hidden email] in
> MEMORY:sAA7vI4
> [14791] 1538167075.247319: Getting credentials [hidden email] ->
> [hidden email] using ccache FILE:/tmp/krb5cc_0
> [14791] 1538167075.247489: Retrieving [hidden email] -> [hidden email] from
> FILE:/tmp/krb5cc_0 with result: -1765328243/Matching credential not found
> [14791] 1538167075.247576: Getting credentials [hidden email] -> krbtgt/
> [hidden email] using ccache FILE:/tmp/krb5cc_0
> [14791] 1538167075.247758: Retrieving [hidden email] -> krbtgt/
> [hidden email] from FILE:/tmp/krb5cc_0 with result: 0/Success
> [14791] 1538167075.247863: Get cred via TGT krbtgt/[hidden email] after
> requesting [hidden email] (canonicalize on)
> [14791] 1538167075.247953: Generated subkey for TGS request: rc4-hmac/F169
> [14791] 1538167075.248043: etypes requested in TGS request: aes256-cts,
> aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts
> [14791] 1538167075.248184: Encoding request body and padata into FAST request
> [14791] 1538167075.248353: Sending request (2176 bytes) to TEST.COM
> [14791] 1538167075.248448: Resolving hostname 172.21.162.211
> [14791] 1538167075.248605: Initiating TCP connection to stream
> 172.21.162.211:88
> [14791] 1538167075.248931: Sending TCP request to stream 172.21.162.211:88
> [14791] 1538167075.250602: Received answer (1842 bytes) from stream
> 172.21.162.211:88
> [14791] 1538167075.251358: Response was not from master KDC
> [14791] 1538167075.251478: Decoding FAST response
> [14791] 1538167075.251629: FAST reply key: rc4-hmac/E50D
> [14791] 1538167075.251805: TGS reply is for [hidden email] ->
> [hidden email] with session key rc4-hmac/F1B4
> [14791] 1538167075.251901: Got cred; 0/Success
> [14791] 1538167075.251999: Resolving unique ccache of type MEMORY
> [14791] 1538167075.252080: Initializing MEMORY:2zEVGbO with default princ
> [hidden email]
> [14791] 1538167075.252202: Removing [hidden email] -> krbtgt/[hidden email]
> from MEMORY:2zEVGbO
> [14791] 1538167075.252276: Storing [hidden email] -> krbtgt/[hidden email]
> in MEMORY:2zEVGbO
> [14791] 1538167075.252371: Removing [hidden email] -> krb5_ccache_conf_data/
> pa_type/krbtgt\/TEST.COM\@TEST.COM@X-CACHECONF: from MEMORY:2zEVGbO
> [14791] 1538167075.252448: Storing [hidden email] -> krb5_ccache_conf_data/
> pa_type/krbtgt\/TEST.COM\@TEST.COM@X-CACHECONF: in MEMORY:2zEVGbO
> [14791] 1538167075.252538: Storing config in MEMORY:2zEVGbO for :
> proxy_impersonator: [hidden email]
> [14791] 1538167075.252614: Removing [hidden email] -> krb5_ccache_conf_data
> /proxy_impersonator@X-CACHECONF: from MEMORY:2zEVGbO
> [14791] 1538167075.252721: Storing [hidden email] -> krb5_ccache_conf_data/
> proxy_impersonator@X-CACHECONF: in MEMORY:2zEVGbO
> [14791] 1538167075.252802: Removing [hidden email] -> [hidden email] from
> MEMORY:2zEVGbO
> [14791] 1538167075.252873: Storing [hidden email] -> [hidden email] in
> MEMORY:2zEVGbO
> [14791] 1538167075.253224: Getting credentials [hidden email] ->
> [hidden email] using ccache FILE:/tmp/krb5cc_0
> [14791] 1538167075.253394: Retrieving [hidden email] -> [hidden email] from
> FILE:/tmp/krb5cc_0 with result: -1765328243/Matching credential not found
> [14791] 1538167075.253482: Getting credentials [hidden email] -> krbtgt/
> [hidden email] using ccache FILE:/tmp/krb5cc_0
> [14791] 1538167075.253634: Retrieving [hidden email] -> krbtgt/
> [hidden email] from FILE:/tmp/krb5cc_0 with result: 0/Success
> [14791] 1538167075.253798: Get cred via TGT krbtgt/[hidden email] after
> requesting [hidden email] (canonicalize on)
> [14791] 1538167075.253893: Generated subkey for TGS request: rc4-hmac/0FA7
> [14791] 1538167075.253985: etypes requested in TGS request: aes256-cts,
> aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts
> [14791] 1538167075.254128: Encoding request body and padata into FAST request
> [14791] 1538167075.254285: Sending request (2176 bytes) to TEST.COM
> [14791] 1538167075.254380: Resolving hostname 172.21.162.211
> [14791] 1538167075.254531: Initiating TCP connection to stream
> 172.21.162.211:88
> [14791] 1538167075.254767: Sending TCP request to stream 172.21.162.211:88
> [14791] 1538167075.256452: Received answer (1842 bytes) from stream
> 172.21.162.211:88
> [14791] 1538167075.257177: Response was not from master KDC
> [14791] 1538167075.257272: Decoding FAST response
> [14791] 1538167075.257422: FAST reply key: rc4-hmac/F998
> [14791] 1538167075.257538: TGS reply is for [hidden email] ->
> [hidden email] with session key rc4-hmac/6958
> [14791] 1538167075.257633: Got cred; 0/Success
> [14791] 1538167075.257759: Resolving unique ccache of type MEMORY
> [14791] 1538167075.257845: Initializing MEMORY:mhj20wl with default princ
> [hidden email]
> [14791] 1538167075.257968: Removing [hidden email] -> krbtgt/[hidden email]
> from MEMORY:mhj20wl
> [14791] 1538167075.258044: Storing [hidden email] -> krbtgt/[hidden email]
> in MEMORY:mhj20wl
> [14791] 1538167075.258140: Removing [hidden email] -> krb5_ccache_conf_data/
> pa_type/krbtgt\/TEST.COM\@TEST.COM@X-CACHECONF: from MEMORY:mhj20wl
> [14791] 1538167075.258224: Storing [hidden email] -> krb5_ccache_conf_data/
> pa_type/krbtgt\/TEST.COM\@TEST.COM@X-CACHECONF: in MEMORY:mhj20wl
> [14791] 1538167075.258330: Storing config in MEMORY:mhj20wl for :
> proxy_impersonator: [hidden email]
> [14791] 1538167075.258407: Removing [hidden email] -> krb5_ccache_conf_data
> /proxy_impersonator@X-CACHECONF: from MEMORY:mhj20wl
> [14791] 1538167075.258478: Storing [hidden email] -> krb5_ccache_conf_data/
> proxy_impersonator@X-CACHECONF: in MEMORY:mhj20wl
> [14791] 1538167075.258552: Removing [hidden email] -> [hidden email] from
> MEMORY:mhj20wl
> [14791] 1538167075.258623: Storing [hidden email] -> [hidden email] in
> MEMORY:mhj20wl
> [14791] 1538167075.258994: Getting credentials [hidden email] ->
> [hidden email] using ccache FILE:/tmp/krb5cc_0
> [14791] 1538167075.259163: Retrieving [hidden email] -> [hidden email] from
> FILE:/tmp/krb5cc_0 with result: -1765328243/Matching credential not found
> [14791] 1538167075.259251: Getting credentials [hidden email] -> krbtgt/
> [hidden email] using ccache FILE:/tmp/krb5cc_0
> [14791] 1538167075.259403: Retrieving [hidden email] -> krbtgt/
> [hidden email] from FILE:/tmp/krb5cc_0 with result: 0/Success
> [14791] 1538167075.259503: Get cred via TGT krbtgt/[hidden email] after
> requesting [hidden email] (canonicalize on)
> [14791] 1538167075.259593: Generated subkey for TGS request: rc4-hmac/1E3B
> [14791] 1538167075.259709: etypes requested in TGS request: aes256-cts,
> aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts
> [14791] 1538167075.259860: Encoding request body and padata into FAST request
> [14791] 1538167075.260017: Sending request (2176 bytes) to TEST.COM
> [14791] 1538167075.260113: Resolving hostname 172.21.162.211
> [14791] 1538167075.260264: Initiating TCP connection to stream
> 172.21.162.211:88
> [14791] 1538167075.260492: Sending TCP request to stream 172.21.162.211:88
> [14791] 1538167075.262157: Received answer (1842 bytes) from stream
> 172.21.162.211:88
> [14791] 1538167075.263296: Response was not from master KDC
> [14791] 1538167075.263396: Decoding FAST response
> [14791] 1538167075.263545: FAST reply key: rc4-hmac/C06A
> [14791] 1538167075.263659: TGS reply is for [hidden email] ->
> [hidden email] with session key rc4-hmac/A45B
> [14791] 1538167075.263783: Got cred; 0/Success
> [14791] 1538167075.263873: Resolving unique ccache of type MEMORY
> [14791] 1538167075.263951: Initializing MEMORY:KH07w0C with default princ
> [hidden email]
> [14791] 1538167075.264079: Removing [hidden email] -> krbtgt/[hidden email]
> from MEMORY:KH07w0C
> [14791] 1538167075.264156: Storing [hidden email] -> krbtgt/[hidden email]
> in MEMORY:KH07w0C
> [14791] 1538167075.264252: Removing [hidden email] -> krb5_ccache_conf_data/
> pa_type/krbtgt\/TEST.COM\@TEST.COM@X-CACHECONF: from MEMORY:KH07w0C
> [14791] 1538167075.264320: Storing [hidden email] -> krb5_ccache_conf_data/
> pa_type/krbtgt\/TEST.COM\@TEST.COM@X-CACHECONF: in MEMORY:KH07w0C
> [14791] 1538167075.264398: Storing config in MEMORY:KH07w0C for :
> proxy_impersonator: [hidden email]
> [14791] 1538167075.264464: Removing [hidden email] -> krb5_ccache_conf_data
> /proxy_impersonator@X-CACHECONF: from MEMORY:KH07w0C
> [14791] 1538167075.264523: Storing [hidden email] -> krb5_ccache_conf_data/
> proxy_impersonator@X-CACHECONF: in MEMORY:KH07w0C
> [14791] 1538167075.264588: Removing [hidden email] -> [hidden email] from
> MEMORY:KH07w0C
> [14791] 1538167075.264648: Storing [hidden email] -> [hidden email] in
> MEMORY:KH07w0C
> [14791] 1538167075.265171: Getting credentials [hidden email] ->
> [hidden email] using ccache MEMORY:sAA7vI4
> [14791] 1538167075.265276: Retrieving [hidden email] -> [hidden email] from
> MEMORY:sAA7vI4 with result: 0/Success
> [14791] 1538167075.265424: Creating authenticator for [hidden email] ->
> [hidden email], seqnum 774377519, subkey rc4-hmac/46AC, session key rc4-hmac/
> AEF0
> [14791] 1538167075.265952: Decrypted AP-REQ with server principal
> [hidden email]: rc4-hmac/2163
> [14791] 1538167075.266046: AP-REQ ticket: [hidden email] -> [hidden email],
> session key rc4-hmac/AEF0
> [14791] 1538167075.266387: Negotiated enctype based on authenticator: rc4-hmac
> [14791] 1538167075.266462: Authenticator contains subkey: rc4-hmac/46AC
> [14791] 1538167075.266554: Resolving unique ccache of type MEMORY
> [14791] 1538167075.266631: Initializing MEMORY:narfKr4 with default princ
> [hidden email]
> [14791] 1538167075.266831: Removing [hidden email] -> krbtgt/[hidden email]
> from MEMORY:narfKr4
> [14791] 1538167075.266921: Storing [hidden email] -> krbtgt/[hidden email]
> in MEMORY:narfKr4
> [14791] 1538167075.267043: Removing [hidden email] -> krb5_ccache_conf_data/
> pa_type/krbtgt\/TEST.COM\@TEST.COM@X-CACHECONF: from MEMORY:narfKr4
> [14791] 1538167075.267137: Storing [hidden email] -> krb5_ccache_conf_data/
> pa_type/krbtgt\/TEST.COM\@TEST.COM@X-CACHECONF: in MEMORY:narfKr4
> [14791] 1538167075.267223: Storing config in MEMORY:narfKr4 for :
> proxy_impersonator: [hidden email]
> [14791] 1538167075.267292: Removing [hidden email] -> krb5_ccache_conf_data
> /proxy_impersonator@X-CACHECONF: from MEMORY:narfKr4
> [14791] 1538167075.267352: Storing [hidden email] -> krb5_ccache_conf_data/
> proxy_impersonator@X-CACHECONF: in MEMORY:narfKr4
> [14791] 1538167075.267419: Removing [hidden email] -> [hidden email] from
> MEMORY:narfKr4
> [14791] 1538167075.267478: Storing [hidden email] -> [hidden email] in
> MEMORY:narfKr4
> [14791] 1538167075.268760: Retrieving [hidden email] -> [hidden email] from
> MEMORY:narfKr4 with result: 0/Success
> [14791] 1538167075.268838: Getting credentials [hidden email] -> http/
> [hidden email] using ccache MEMORY:narfKr4
> [14791] 1538167075.268942: Retrieving [hidden email] -> krbtgt/
> [hidden email] from MEMORY:narfKr4 with result: 0/Success
> [14791] 1538167075.269007: Starting with TGT for client realm: [hidden email]
> -> krbtgt/[hidden email]
> [14791] 1538167075.269065: Requesting tickets for http/
> [hidden email], referrals on
> [14791] 1538167075.269139: Generated subkey for TGS request: rc4-hmac/68E3
> [14791] 1538167075.269221: etypes requested in TGS request: aes256-cts,
> aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts
> [14791] 1538167075.269369: Encoding request body and padata into FAST request
> [14791] 1538167075.269577: Sending request (4026 bytes) to TEST.COM
> [14791] 1538167075.269685: Resolving hostname 172.21.162.211
> [14791] 1538167075.269846: Initiating TCP connection to stream
> 172.21.162.211:88
> [14791] 1538167075.270110: Sending TCP request to stream 172.21.162.211:88
> [14791] 1538167075.272750: Received answer (1932 bytes) from stream
> 172.21.162.211:88
> [14791] 1538167075.273519: Response was not from master KDC
> [14791] 1538167075.273623: Decoding FAST response
> [14791] 1538167075.273844: FAST reply key: rc4-hmac/25D0
> [14791] 1538167075.273980: TGS reply is for [hidden email] -> http/
> [hidden email] with session key aes256-cts/81DC
> [14791] 1538167075.274086: TGS request result: 0/Success
> [14791] 1538167075.274161: Received creds for desired service http/
> [hidden email]
> [14791] 1538167075.274236: Removing [hidden email] -> http/
> [hidden email] from MEMORY:narfKr4
> [14791] 1538167075.274310: Storing [hidden email] -> http/
> [hidden email] in MEMORY:narfKr4
> [14791] 1538167075.274464: Creating authenticator for [hidden email] ->
> http/[hidden email], seqnum 1049723237, subkey aes256-cts/323A,
> session key aes256-cts/81DC
> [14791] 1538167075.275185: Destroying ccache MEMORY:narfKr4
> [14791] 1538167075.275320: Destroying ccache MEMORY:sAA7vI4
> [14791] 1538167075.275477: Destroying ccache MEMORY:2zEVGbO
> [14791] 1538167075.275631: Destroying ccache MEMORY:mhj20wl
> [14791] 1538167075.275851: Destroying ccache MEMORY:KH07w0C
>
> On Monday 5 November 2018, 15:56:23 GMT, Derek Atkins <[hidden email]> wrote:
>
> moore moore <[hidden email]> 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
>       [hidden email]            www.ihtfp.com
>       Computer and Internet Security Consultant
>

--
       Derek Atkins                 617-623-3745
       [hidden email]             www.ihtfp.com
       Computer and Internet Security Consultant
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev