> 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*... ________________________________________________ Kerberos mailing list [EMAIL PROTECTED] http://mailman.mit.edu/mailman/listinfo/kerberos
