Russ, I understand and agree with your first statements regarding the enctype. I was proposing a scenario where the environment was restricted to only AES types, so a client which only supported DES would not be allowed in any event. Assuming the server preferred AES, but accepted DES if requested, then clearly the pre-auth has the advantage. Of course, even in a pre-auth scenario, couldn't I have a rogue client or modify the kerberos configuration (or run a second configuration) on a client that I have configured to support only a weak enctype?
Regarding your second statements - I'm not sure I fully grasp your meanings. I am certainly not doubting that there are advantages to the pre-auth. The point you make about unused accounts is a good one. If an enterprise is secured enough to prevent the passive man-in-the-middle attacks then the advantage is clear. My argument is mostly taking the vein that if this were compromised (switch password discovered, network tap, no ip-sec, compromise of a system on isolated network, etc.) that any principal's logon traffic which passed to the KDC is a possible target for a pre-auth attack. Of course I might not simply be able to request a TGT for ad...@domain.com, but there is a good chance some administrator credentials will flow on a daily basis to the KDC, no? So while I may be trivializing these other protections, my experience tells me that often there are enough overlooked aspects of a network's security that gaining the advantage here is not as difficult as it might seem. In the best of all possible worlds, enc timestamp pre-auth has a clear advantage - but in practice I am trying to determine what that advantage truly is. I believe we are probably on the same page here, but if you feel I am still missing your point (and you care to make it again), please elaborate. On Wed, May 14, 2014 at 5:16 PM, Russ Allbery <ea...@eyrie.org> wrote: > Ben H <bhen...@gmail.com> writes: > > > But the preauthentication gives the added protection of allowing the > > server to choose/enforce the encryption type used. > > I don't believe this is the case. Whether or not pre-authentication is > enabled, the server always has the ability to choose or enforce the > encryption type used. > > The difference in the pre-authentication case is that the *attacker* > cannot choose a weak enctype that the server is willing to accept by > claiming that the attacker is a client that only supports weak enctypes. > Instead, the attacker has to work from network capture information from a > real client, and real clients will always attempt to negotiate the > strongest encryption type they support. > > > That being said, if say AES were the only allowable encryption type used > > on such a network, the advantages here would be significantly less > > substantial and if we assumed easy access to the network, and standard > > encrypted-timestamp preauth, then the advantages of this pre-auth are > > negligible at best to no pre-auth at all? > > Pre-authentication essentially requires the attacker to be capable of > being a passive man-in-the-middle in order to launch an off-line > brute-force attack. If there is no security risk benefit in shifting the > attacker profile from "anyone who can connect to the KDC" to "passive > man-in-the-middle," then yes, encrypted timestamp pre-authentication isn't > really doing anything for you. > > That being said, I am rather dubious that you can construct a reasonable > scenario where that change has no benefit. A typical enterprise closed > network use case is *not* such a scenario. With encrypted timestamp, the > attacker can still only attack clients for which it has network capture > data, which means that unused accounts are not vulnerable to off-line > brute-force, and any limitation on the attacker's ability to see all > network traffic (and, in practice, there will be many limitations for most > likely attacker scenarios) will give you more security by reducing the > principal space the attacker can launch off-line attacks against. > > -- > Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/> > ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
