Windows KDC - Delegation Option

[Ben H]

Thanks again.  I confirmed that the [domain_realm] entry worked both on a
unix host and on my kfw-3.2.2 install.
Once added, no referral was needed and only one entry shows in the cache.

Interestingly, in respect to your information on the forwarded ticket TGS
request, I found that Windows implements this differently.

When using Putty with SPPI, the forwardable TGT is requested by the host
and sent over to the remote system.  In this, there is no difference to
GSSAPI.

However, the ticket *is* cached on the windows host:


#0>     Client: jsmith @ MYDOMAIN.LOCAL
        Server: krbtgt/MYDOMAIN.LOCAL @ MYDOMAIN.LOCAL
        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
        Ticket Flags 0x60a10000 -> forwardable forwarded renewable
pre_authent name_canonicalize
        Start Time: 4/25/2014 22:07:21 (local)
        End Time:   4/26/2014 8:07:21 (local)
        Renew Time: 5/2/2014 22:07:21 (local)
        Session Key Type: AES-256-CTS-HMAC-SHA1-96

Because it is cached on the windows host, the same ticket it sent on each
request and not TGS request goes to the KDC.
Not only that, but it would appear that the same forwardable ticket is sent
to any host that is accepts forwarded tickets (trusted for delegation).
I confirmed this by both a wirecap (no TGS sent on subsequent connections
to original remote host and to a second host), and by the fact the
time-stamp on my first cached ticket was the same on both remote hosts.

Based on your prior explanation I can't help but infer this means that
although the new forwardable TGT session key may be different than my
original TGT, it is still shared between all hosts that I delegate to,
leading to a possible attack against all systems should one be compromised?
 Is this the reason that MIT chooses to request a new TGT for each
connection?


On Fri, Apr 25, 2014 at 7:01 PM, Greg Hudson <ghudson at mit.edu> wrote:

> On 04/25/2014 07:16 PM, Ben H wrote:
> > Is there some way to show a mapping that these two tickets are really
> > identical?
>
> In theory it would be possible to checksum the tickets and tell that
> they are the same, but list doesn't know how to do this.
>
> > Is the empty realm display really necessary once we have achieved the
> > realm name?  Why do we continue to show it if we have already received
> > the realm?
>
> Displaying the entry may not be necessary, but caching it without the
> realm is necessary to avoid repeating the TGS request the next time we
> try to contact the remote host.  klist is just displaying the entries in
> the cache.
>
> > Is it possible to avoid this situation by a more thorough configuration
> > of krb5.conf?
>
> Sure, you can add a [domain_realm] entry matching the remote host.  See
>
> http://web.mit.edu/kerberos/krb5-latest/doc/admin/conf_files/krb5_conf.html#domain-realm
>
> > Why would the client be unable to determine the remote realm if I am
> > specifying a FQDN (i.e. shouldn't it assume the realm?)
>
> We have a fallback heuristic that f.q.d.n is in the realm F.Q.D, but we
> do not consider it authoritative, so we try referrals first.  In many
> situations that heuristic would be inaccurate; for instance, hosts in
> the mit.edu domain are typically in the realm ATHENA.MIT.EDU, not MIT.EDU.
>
> > Can you point me to what might be the best resource to learn more about
> > this feature - as I'm having a hard time understanding the full concept.
> >  I wasn't previously aware that the cache could show two tickets that
> > were actually the same.
>
> We could probably stand to have better documentation for the client side
> behavior of referrals.  Right now I believe all we have is at:
>
> http://web.mit.edu/kerberos/krb5-latest/doc/admin/realm_config.html#mapping-hostnames-onto-kerberos-realms
> and the documentation for the associated kdc.conf variables.
>