Ben H <bhen...@gmail.com> writes: > I was reading up a bit on the history of pre-authentication after hearing a > speaker I generally put all faith into mention something about pre-auth > which I didn't think was accurate (namely that's its use was to help > determine available encryption types...something which I can find no > evidence of).
The ETYPE-INFO and ETYPE-INFO2 "preauth" types are hints from the KDC to the client as to what enctypes to use for further preauth or for decrypting the AS-REP. They happen to take advantage of the protocol "hole" provided by the preauth elements in the protocol, but they do not exemplify the intended use of preauth. > In any event, my understanding is that pre-auth is used to prevent an > entity from requesting a TGT without credentials and therefore not being > able to brute force the encryption. I think the intention was to prevent just anyone on the entire Internet from requesting ciphertext use for a dictionary attack unless they could first demonstrate knowledge of the key. > However, there are tools out there which are able to also perform > brute-force attacks against the pre-auth timestamp. In order to do this > however, it would require the ability to listen on the wire between a > client and a KDC. Something that may be trivial in certain circumstances > (compromising a single application box could provide a sniff of all users > authenticating to the KDC). > > That being said, assuming that all traffic to the KDC is encrypted, > pre-authentication would seem to be superior as I can't request a ticket > without credentials from an insecure location. If however, we assume that > all traffic between a client and a KDC may be compromised, is > pre-authentication superior? I believe you're thinking primarily of encrypted-timestamp preauth. It adds some protection from attackers who are not network-omniscient, but not very much when an attacker can capture all traffic entering and leaving the KDC. There are stronger preauth protections than encrypted-timestamp, e.g., FAST (RFC 6113), that can replace or strengthen the use of password-derived keys, and we are considering adding more. > We don't even need to make repeated attempts for a pre-auth required, we > simply need to listen on the wire for when user's authenticate. > Isn't a known entity like a UTC timestamp eaiser to brute force against > than the encrypted TGT? The encryption schemes used for encrypted-timestamp (and in much of Kerberos) are authenticated encryption, so it is easy to verify that the correct key was guessed. ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
