Implementing IETF Draft on DNS use in Kerberos

[Sam Hartman]

>>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams at ubsw.com> writes:

    >> I thought that the receipt of a valid TGT was proof for the
    >> client that it was dealing with a trusted KDC and thus the
    >> local realm lookup was valid.

    Nicolas> This is true if you're doing pre-authentication and the
    Nicolas> user of the TGT is the host's principal itself.

People seem to be doing a good job of discussing this issue to death
without actually explaining what is going on.

Fundamentally a host cannot trust Kerberos unless that host has a key
and somehow the authentication is linked back to that key.  Since that
key will belong to some realm, you will already know what realm to
trust if you are able to trust Kerberos at all.

Getting a TGT only proves that the entity asserting itself to be the
KDC shares a secret with the entity asserting that it is the principal
in the client field of the TGT.  If you have not independently
validated one of these assertions you cannot trust the Kerberos
authentication.

The common attack is to set up a fake KDC that pretends to have some
account in it and then to present that key to the local system.

eI think I've explained this issue enough times that I should get
around to writing and publishing an exploit.  Perhaps then people will
really get it.

(Nico, I realize you do actually get itbut I'm concerned that your
explanation was not quite sufficient.)