host/*@REALM tickets with ssh, DNS

[eichin-krb@thok.org]

> being dense.  The main concern I had was based on the understanding
> that things work this way:

Unless I'm vastly misunderstanding your terms, your understanding is,
well, "inside out" at best.

> 1) I prove my identity to the KDC and am issued a ticket.

V4: no prove, just assert.
V5: well, there's preauth, but it is weak; mostly, also assert.

The ticket you get is encrypted in a key you are expected to have,
namely string2key of your password.

> 2) The ssh daemon proves it's identity to the KDC using the stored

The first edition simsong+spaf O'Reilly security book had this bit
wrong too, but was fixed by the 4th or so.  Namely, daemons *never*
talk directly to the kdc as part of the user authentication process.
When you [using your tgt, but that's an optimization] get a service
ticket, the kdc sends you part of it encrypted in your key, and part
of it encrypted in the daemon's key.  A session key is sealed into
both halves.  You forward on the latter part, keep your part, and now
you both have a common session key, based on (1) the host key only
being known to the daemon and the kdc (2) the password-user-key only
beeing known to you and the kdc.

Google for "zanarotti attack" if you want to find details of the
common security failure resulting from the assumption that being able
to decrypt a kdc response in a key handed to you by a user means
*anything*...