Spurious tickets when using DNS realm configuration

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

Spurious tickets when using DNS realm configuration

David Cross
I have noticed that when using DNS realm configuration (URI and TXT) records I have spurious kdc requests and ccache entries.

Specifically if I auth as user@REALM and klist I see my tgt as expected. If i then ssh to a host and klist I get 2 tickets:
host/foo@
host/foo@REALM

Additionally on the kdc i see that it additionally requests the tgt again. Reading get_creds.c I think I kind of see what is going on here, it is getting the ‘fallback’ realm (line 124). However i am not fully following the control logic here and certainly not seeing how dns based (mis)configuration is interacting here)

This does work, I’d just like to get rid of the cruft and understand what isn’t right with DNS based configuration.

Thank you

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

Re: Spurious tickets when using DNS realm configuration

Greg Hudson
On 7/24/19 2:13 AM, David Cross wrote:
> Specifically if I auth as user@REALM and klist I see my tgt as expected. If i then ssh to a host and klist I get 2 tickets:
> host/foo@
> host/foo@REALM

This is expected, and results from not having a [domain_realm] map entry
for the server host.  (Using DNS realm configuration shouldn't affect
this one way or another.)  Because the realm of the server is not known,
the initial principal we request credentials for is host/foo@, and we
don't find out that the actual name is host/foo@REALM until we get the
ticket.  We need to cache the result under host/foo@ or we would make a
repeat query the next time around.

In the next release there will only be one cache entry, which will
appear in klist like:

07/24/19 12:18:54  07/25/19 12:18:41  host/small-gods.mit.edu@
        Ticket server: host/[hidden email]

> Additionally on the kdc i see that it additionally requests the tgt again.

The TGT or the service ticket?  Regardless, I don't have a good
explanation for that; I wouldn't expect there to be multiple TGS
requests in a simple referral scenario.  Getting KRB5_TRACE output might
help determine what's going on.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Spurious tickets when using DNS realm configuration

Russ Allbery-2
Greg Hudson <[hidden email]> writes:
> On 7/24/19 2:13 AM, David Cross wrote:

>> Additionally on the kdc i see that it additionally requests the tgt again.

> The TGT or the service ticket?  Regardless, I don't have a good
> explanation for that; I wouldn't expect there to be multiple TGS
> requests in a simple referral scenario.  Getting KRB5_TRACE output might
> help determine what's going on.

Maybe David is seeing multiple AS_REQs from pre-auth?  That usually gets
logged as two requests, one without the challenge (which will result in
"Additional pre-authentication required") and one with it.

--
Russ Allbery ([hidden email])              <http://www.eyrie.org/~eagle/>
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Spurious tickets when using DNS realm configuration

David Cross
On 2019-07-24 12:47, Russ Allbery wrote:

> Greg Hudson <[hidden email]> writes:
>> On 7/24/19 2:13 AM, David Cross wrote:
>
>>> Additionally on the kdc i see that it additionally requests the tgt
>>> again.
>
>> The TGT or the service ticket?  Regardless, I don't have a good
>> explanation for that; I wouldn't expect there to be multiple TGS
>> requests in a simple referral scenario.  Getting KRB5_TRACE output
>> might
>> help determine what's going on.
>
> Maybe David is seeing multiple AS_REQs from pre-auth?  That usually
> gets
> logged as two requests, one without the challenge (which will result in
> "Additional pre-authentication required") and one with it.

Sorry to dissapear... and as I was typing my reply, I figured out what
was going on; I have it set to request forwardable tickets....so the
'second' TGT is the forwardable one; I just validated this by disabling
the forwardable ticket and I now see this in the logs instead of a new
TGT:

Jul 28 19:16:05 kerberos krb5kdc[####]: TGS_REQ (1 etypes {19})
10.1.7.155: TGT NOT FORWARDABLE: authtime 0,  [hidden email] for
krbtgt/[hidden email], KDC can't fulfill requested option

So that's one mystery down.

(replying to the other thread separately)
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Spurious tickets when using DNS realm configuration (and cross realm TGT)

David Cross
In reply to this post by Greg Hudson
On 2019-07-24 12:28, Greg Hudson wrote:

> On 7/24/19 2:13 AM, David Cross wrote:
>> Specifically if I auth as user@REALM and klist I see my tgt as
>> expected. If i then ssh to a host and klist I get 2 tickets:
>> host/foo@
>> host/foo@REALM
>
> This is expected, and results from not having a [domain_realm] map
> entry
> for the server host.  (Using DNS realm configuration shouldn't affect
> this one way or another.)  Because the realm of the server is not
> known,
> the initial principal we request credentials for is host/foo@, and we
> don't find out that the actual name is host/foo@REALM until we get the
> ticket.  We need to cache the result under host/foo@ or we would make a
> repeat query the next time around.
>

Ok, I have definitely confirmed that adding a domain_map entry alters
this behavior (no 'blank' realm entries), but it *should* be able to
determine the host in question, and this set from KRB5_TRACE suggests it
does, but then promptly forgets?:


[12050] 1564341061.206976: TXT record _kerberos.host.net.example.com.
not found
[12050] 1564341061.206977: TXT record _kerberos.net.example.com. not
found
[12050] 1564341061.206978: TXT record _kerberos.example.com. found:
EXAMPLE.COM
[12050] 1564341061.206979: ccselect module realm chose cache
FILE:/tmp/krb5cc_1001 with client principal [hidden email] for server
principal host/[hidden email]
[12050] 1564341061.206980: Getting credentials [hidden email] ->
host/host.net.example.com@ using ccache FILE:/tmp/krb5cc_1001
                                                                     
^^^^^^^^^^^^^^^^^^^^^^^^^^^      ????

Additionally, in investigating this I noticed something weird (I have 3
realms setup, with a fully connected graph between them), when doing
cross-realm authentication I notice I sometimes get cross-realm TGTs..
and other times I don't (but it works in all cases).  If I do or do not
is deterministic based on the relationship requested.

Given the realms:
   EXAMPLE.COM
   EXAMPLE.NET
   EXAMPLE.ORG

If I am authenticated to EXAMPLE.COM and request a host key for a host
in  EXAMPLE.NET I get a cross realm TGT *and* the host key:
07/28/2019 16:10:41  07/29/2019 16:04:49  krbtgt/[hidden email]
07/28/2019 16:10:41  07/29/2019 16:04:49  
host/[hidden email]

If I request a host key for a host in EXAMPLE.ORG I do *NOT* get a cross
realm TGT, just the host key (and it works):
07/28/2019 16:05:07  07/29/2019 16:04:49  
host/[hidden email]

The logs on the kdc (this is a single KDC process serving all 3 realms,
it is configured with 3 separate principal databases, and 3 distinct
kadmin/kpasswd processes) show the following:

For the first case (cross realm TGT issued):  (this is what I would
expect)

Jul 28 19:48:39 kerberos krb5kdc[####]: TGS_REQ (8 etypes {18 17 20 19
16 23 25 26}) 10.1.7.155: LOOKING_UP_SERVER: authtime 0,  
[hidden email] for host/[hidden email], Server not
found in Kerberos database
Jul 28 19:48:39 kerberos krb5kdc[####]: TGS_REQ (8 etypes {18 17 20 19
16 23 25 26}) 10.1.7.155: ISSUE: authtime 1564343215, etypes {rep=19
tkt=19 ses=19}, [hidden email] for krbtgt/[hidden email]
Jul 28 19:48:39 kerberos krb5kdc[####]: TGS_REQ (8 etypes {18 17 20 19
16 23 25 26}) 10.1.7.155: ISSUE: authtime 1564343215, etypes {rep=19
tkt=19 ses=19}, [hidden email] for
host/[hidden email]



For the second case I see:

Jul 28 19:47:31 kerberos krb5kdc[####]: TGS_REQ (8 etypes {18 17 20 19
16 23 25 26}) 10.1.7.155: ISSUE: authtime 1564343215, etypes {rep=19
tkt=19 ses=19}, [hidden email] for krbtgt/[hidden email]
Jul 28 19:47:31 kerberos krb5kdc[####]: TGS_REQ (8 etypes {18 17 20 19
16 23 25 26}) 10.1.7.155: ISSUE: authtime 1564343215, etypes {rep=19
tkt=19 ses=19}, [hidden email] for
host/[hidden email]

This has apparently short-circuited the cross realm evaluation and not
even returned it to the client just handing back the end ticket?  The
KRB5_TRACE logs seem to confirm this (cross realm TGT in client cache):

[12118] 1564342598.335091: Server has referral realm; starting with
host/[hidden email]
[12118] 1564342598.335092: Retrieving [hidden email] ->
krbtgt/[hidden email] from FILE:/tmp/krb5cc_1001 with result:
0/Success
[12118] 1564342598.335093: Starting with TGT for client realm:
[hidden email] -> krbtgt/[hidden email]
[12118] 1564342598.335094: Requesting tickets for
host/[hidden email], referrals on
[12118] 1564342598.335095: Generated subkey for TGS request:
aes128-sha2/FB2D
[12118] 1564342598.335096: etypes requested in TGS request: aes256-cts,
aes128-cts, aes256-sha2, aes128-sha2, des3-cbc-sha1, rc4-hmac,
camellia128-cts, camellia256-cts
[12118] 1564342598.335098: Encoding request body and padata into FAST
request
[12118] 1564342598.335099: Sending request (987 bytes) to EXAMPLE.COM
[12118] 1564342598.335100: Sending DNS URI query for
_kerberos.EXAMPLE.COM.
[12118] 1564342598.335101: URI answer: 10 1
"krb5srv:m:tcp:kerberos.example.com"
[12118] 1564342598.335102: Resolving hostname kerberos.example.com
[12118] 1564342598.335107: Response was from master KDC
[12118] 1564342598.335108: Decoding FAST response
***[12118] 1564342598.335109: TGS request result: -1765328377/Server
host/[hidden email] not found in Kerberos database


No cross realm TGT:
[12119] 1564342613.678759: Server has referral realm; starting with
host/[hidden email]
[12119] 1564342613.678760: Retrieving [hidden email] ->
krbtgt/[hidden email] from FILE:/tmp/krb5cc_1001 with result:
0/Success
[12119] 1564342613.678761: Starting with TGT for client realm:
[hidden email] -> krbtgt/[hidden email]
[12119] 1564342613.678762: Requesting tickets for
host/[hidden email], referrals on
[12119] 1564342613.678763: Generated subkey for TGS request:
aes128-sha2/C16E
[12119] 1564342613.678764: etypes requested in TGS request: aes256-cts,
aes128-cts, aes256-sha2, aes128-sha2, des3-cbc-sha1, rc4-hmac,
camellia128-cts, camellia256-cts
[12119] 1564342613.678766: Encoding request body and padata into FAST
request
[12119] 1564342613.678767: Sending request (993 bytes) to EXAMPLE.COM
[12119] 1564342613.678768: Sending DNS URI query for
_kerberos.EXAMPLE.COM.
[12119] 1564342613.678769: URI answer: 10 1
"krb5srv:m:tcp:kerberos.example.org"
[12119] 1564342613.678770: Resolving hostname kerberos.example.org
[12119] 1564342613.678775: Response was from master KDC
[12119] 1564342613.678776: Decoding FAST response
[12119] 1564342613.678777: FAST reply key: aes128-sha2/4277
***[12119] 1564342613.678778: Reply server
krbtgt/[hidden email] differs from requested
host/[hidden email]

So it gets the cross realm TGT, and then doesn't save it? after being
short-circuit evaluated in the KDC?

I do not (that I remember, or can find) have any CAPATHS setup on either
the client or the server.  The only thing that
seems unifying is that the 'home' realm for the KDC is EXAMPLE.ORG (it
is kerberos.example.org).


Thank you for your time in helping me unravel this and ensure I am setup
correctly; I had tried the normal googling of results and not come up
with many hits.

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

Re: Spurious tickets when using DNS realm configuration (and cross realm TGT)

David Cross
On 2019-07-28 17:08, [hidden email] wrote:
> [snip for brevity]
> So it gets the cross realm TGT, and then doesn't save it? after being
> short-circuit evaluated in the KDC?
>
> I do not (that I remember, or can find) have any CAPATHS setup on
> either
> the client or the server.  The only thing that
> seems unifying is that the 'home' realm for the KDC is EXAMPLE.ORG (it
> is kerberos.example.org).

Ok.. so I made a bunch of changes to the krb5.conf on the kdc to remove
the default realm as well as to add in the other realms, additionally I
added 'dns_lookup_realm' and 'dns_lookup_kdc' to the krb5.conf on the
client machine as well as the kdc, and now I see the intermedate tgts in
all cases.   So its definitely config driven, and things appear to be
setup correctly; I wish I understood the subtleties of these behaviors
more (was it removing the default_realm?  was it the DNS entries? adding
the remaining realms?)
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Spurious tickets when using DNS realm configuration (and cross realm TGT)

Greg Hudson
On 7/28/19 6:49 PM, [hidden email] wrote:
> Ok.. so I made a bunch of changes to the krb5.conf on the kdc to remove
> the default realm as well as to add in the other realms, additionally I
> added 'dns_lookup_realm' and 'dns_lookup_kdc' to the krb5.conf on the
> client machine as well as the kdc, and now I see the intermedate tgts in
> all cases.   So its definitely config driven, and things appear to be
> setup correctly; I wish I understood the subtleties of these behaviors
> more (was it removing the default_realm?  was it the DNS entries? adding
> the remaining realms?)

Some of the design principles behind referrals may be under-documented.

Using unauthenticated DNS for locating KDCs is not an attack vector, as
it is no less secure than the network path to the KDC itself, and the
protocol is designed to expect attacks along that path.  So it is on by
default.

Using unauthenticated DNS for host-to-realm mapping can be an attack
vector, because the mapping affects who you authenticate to.  So using
TXT records for this mapping has to be explicitly turned on, and even if
it is turned on, we try to get a referral from the local KDC first.
When possible, using referrals is recommended over using TXT records.

As a loose rule, we only cache what we ask for.  If the client does
cross-realm using referrals, it doesn't cache the referral TGT (as of
release 1.16, see [1]) because it asked the local KDC for a service
ticket, not a cross-realm TGT.  But if the client authoritatively knows
the realm in advance (typically via [domain_realm]), it explicitly asks
for a cross-realm TGT, and caches it.

[1] https://krbdev.mit.edu/rt/Ticket/Display.html?id=8579
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev