|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
Message-ID: <202312042223.3B4MNGKF008347@hedwig.cmf.nrl.navy.mil> To: krbdev@mit.edu In-Reply-To: <ZW5NeKSnrWjvHUYZ@pleonasm.mit.edu> MIME-Version: 1.0 Date: Mon, 04 Dec 2023 17:23:17 -0500 From: Ken Hornstein via krbdev <krbdev@mit.edu> Reply-To: Ken Hornstein <kenh@cmf.nrl.navy.mil> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: krbdev-bounces@mit.edu >I would go even further and say that it is a design assumption of MIT krb5 >that all KDCs are just separate instances of the same logical instance and are >assumed to behave "identically" (i.e., with identical configuration). I'm going to reiterate my earlier statement: THIS IS NOT AN ANSWER TO MY QUESTION. >As Nico says, this particular case seems like the KDC knowing that the enctype >list is sorted strongest-to-weakest, and also knowing that "the KDC" is the >only entity that can create this ciphertext, so enforcing that the strongest >key is being used and preventing by construction any brute-force or other >attacks on krbtgt keys of other enctypes. I'm a little unclear how you could try brute-forcing the "wrong" TGT key in this situation without submitting 2^keylength TGT requests. Again, it is possible I am missing something. --Ken _______________________________________________ krbdev mailing list krbdev@mit.edu https://mailman.mit.edu/mailman/listinfo/krbdev
|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |