It's Monday evening, the weather is great, and we're in the middle of a pandemic. Lets talk Kerberos! Or rather, it's little known nephew FAST and Armoring.
— Steve Syfuhs (@SteveSyfuhs) July 28, 2020
Twitter warning: Like all good things this is mostly correct, with a few details fuzzier than others for reasons: a) details are hard on twitter; b) details are fudged for greater clarity; c) maybe I'm just dumb.
Note this thread was created a while back. Just catching up.
You might have heard about it from such features as Windows Kerberos Armoring. It's in fact three separate things. What's New in Kerberos Authentication | Microsoft Docs
First, it's part of a larger body of work called the pre-authentication framework, a way to provide a generic extensible model of adding authentication methods to Kerberos. It gets more interesting, honest.
Second, it's a method of creating a generic secure tunnel for information to flow between a client and a KDC within the original Kerberos protocol. I swear, it'll get interesting.
Third, it's a method where you bind your authentication to the machine account to prevent password attacks like Kerberoasting -- aha, there's the exciting thing!
Kill all password attacks. Here's how it works.
Kerberos is deceptively simple: you, the client, request a ticket from the KDC. The KDC happily responds and encrypts the response to your password. You decrypt it with your password, and voila you have a ticket. This is dangerous because...
You now have this oracle that'll return encrypted blobs of structured data to any caller, encrypted to a password. This makes cryptographic attacks super easy for weak passwords. A solution was added: the pre-auth timestamp, which is the current time encrypted with your password.
The KDC receives this timestamp, decrypts it because it knows your password (-ish) and verifies the request was within a short period of time. But still, attackers can intercept the messages and perform those same attacks. They just need to convince you to get a ticket first.
The protocol itself is bound by this weak thing -- your password. It needs more randomness. Incidentally, most callers happen to be on a domain joined computer when doing Kerberos, and the computer uses a super random password. Innnnnteresting.
So this framework has this thing called Armoring, which is the idea that you take a key and mix in a whole lotta randomness from another source, and use that instead. So here we take the computer account, and have it request a TGT. The TGT has this thing called a session key.
That session key is protected within the TGT and only the client and the KDC know it. So why not let the KDC use the randomness of that session key to protect the client?
The client gets this new mixed key and can now communicate with the KDC. The randomness of the computer password makes any crypto attack infeasible, and the user can still user a password.
Okay, but what about users that aren't on a domain joined computer? There's a small provision in the spec that lets callers request an anonymous ticket. You lose server authentication, but when you're out alone in the wild, what're you gonna do?
...assuming the KDC supports that provision of course.
Now that's all well and good, but what about this tunneling thing? Well back in the dark ages crypto was export controlled (ugh), which left a lot of protocol designers deciding to leave a bunch of crap in cleartext. FAST said nuh uh, attackers can modify that over the wire.
So you have this super secret shiny key now, and a nice dark hole to shove stuff. So what do we do? We make a copy of the entire request, encrypt it, and shove it in the hole. And leave the outer message in cleartext for appearances sake.
Because why not?
The cool thing about all this, aside from making password attacks more difficult, is it lets developers easily extend the protocol to include new pre-auth methods like OTPs or PAKEs, and does a reasonably good job of hardening the aging crypto properties of the protocol.
So, go turn it on. It's super easy.