Forwarded TGT with addresses?

Roland C. Dowdeswell

2015-07-21 13:06:06 UTC

Post by Weijun Wang
When will a TGS-REQ for a forwarded TGT include addresses?
In Java, if a client wants to request for a forwarded TGT for a service,
it will get IP address for the host, and send a TGS-REQ for the ticket
with the address so that the TGT can only be used by the service.
Due to a bug, the address(es) field is never set. I'd like to set it now
but the TGT will be useless for the service if the address is not
correct, for example, service in NAT but KDC outside.
I tried MIT krb5 and seems the client has not send the address (I
created KDC on my local machine and create a fake service/yahoo.com). Is
this always true or is there a setting? In what cases is the addresses
field used?

Forwarding tickets with addresses is difficult to get right for
numerous reasons even when you do not consider NAT. In general,
multihomed hosts are problematic because if you connect to one
interface, this does not mean that the host normally uses this
interface and therefore IP address to initiate further connexions
by default.

There are two rarely implemented ways to deal with this: (1) build
into your protocol a mechanism for the target host to tell the
initiator what the correct address list is, (2) forward credentials
to the remote host with the one address and have the remote host
do a TGS_REQ to exchange this ticket for one with the full list of
addresses that it would like, or (3) forward credentials with no
addresses and have the target host exchange them for one with the
full list of addresses.

All of these are problematic. The first approach would require
modification to existing protocols which do support it. The second
approach doesn't always work because the target host may not be
able to reach the KDC from the address specified in the ticket.
The third approach doesn't really allow the client to know that
the remote host performed the action.

So, in combination with the fact that addresses in tickets provide
only a relatively weak security constraint, leads to the conclusion
that it is generally best for forward credentials without addresses.

OTOH, it might be interesting to bind tickets not to an address
but rather to another Kerberos principal. One could do this by,
say, defining an address type of krb5princ. If this were present,
then you would require that TGS_REQs be protected by FAST initiated
by one of the named principals. This seems like it would be
interesting. It would require that all exchanges with the KDC be
performed by a privileged daemon but would render tickets useless
to anyone without root on the host for which they were intended.
It'd provide a better audit trail in the KDC logs as well.