Avoiding Pre-Auth/Auth Principal State Disclosure

[Chris Hecker]

Wow, thanks for taking the time for the detailed response!  I will digest
this and see if I still have questions.

Chris


On Thu, Jul 2, 2020 at 10:45 Greg Hudson <ghudson at mit.edu> wrote:

> On 7/1/20 3:55 PM, Chris Hecker wrote:
> >> For example, if we treated single-component principals as users,
> > anyone with a user/admin principal (or user/root, which has no status in
> > the code but is a common convention for elevated access) would probably
> > still be detectable by an attacker.
> >
> > Not sure I follow this, why wouldn’t they be treated like a normal princ
> > if we had this obscurity feature?
>
> The difficulty is in making a "normal princ" look identical to an actual
> normal princ.
>
> Let's say we added this obscurity setting to the KDC in the following
> naive way: if an unauthenticated AS request comes in and the client
> principal isn't found in the DB, we send PREAUTH_REQUIRED.  If the
> request contains preauth (of a recognizable "real" preauth type) then we
> send PREAUTH_FAILED.
>
> Service principals can (and frequently do) authenticate as clients.
> Because they have random keys, they don't generally require preauth
> (partly because preauth would be a waste of round trips when the key is
> random, and partly because PREAUTH_REQUIRED has undesirable legacy
> semantics when applied to service principals).  So without first
> authenticating as a legitimate client, the attacker can distinguish
> between a dummy response and a real response for a service principal.
> Perhaps we don't care about obscuring valid service principals, but if
> we do, we have to instead respond to AS requests for service-principal
> clients with a dummy ticket (of a size indistinguishable from a
> legitimate ticket) encrypted in a random key, instead of a
> PREAUTH_REQUIRED.  And because there is no formal distinction between
> user principals and service principals, we can't trivially determine
> whether the client principal (if it existed) would be for a user or for
> a service.
>
> Additionally, in a PREAUTH_REQUIRED error, we have to send etype-info
> based on the request's enctype preference order and the client and
> server principals' supported enctypes.  There's no client principal
> entry, so what enctypes do we assume are supported by the client?
> Perhaps we consult supported_enctypes.  What if the administrator just
> recently began a transition from aes-sha1 to aes-sha2 enctypes?  Most
> real principals will only have aes-sha1 keys, but supported_enctypes
> lists the aes-sha2 enctypes.  In this situation it's easy to distinguish
> dummy responses from those for most real principals.
>
> The use of more advanced preauth mechanisms might further muddy things;
> for instance, principals intended to authenticate with PKINIT might have
> no keys, and therefore no etype-info.  Perhaps we allow the
> administrator to create a template principal which has similar metadata
> to the majority of user principals, and use that for dummy responses.
> Now we're asking a lot from the administrator, and any kind of enctype
> or preauth transition would still create classes of users who are
> distinguishable from the template.
>
> We'd also have to consider whether to include TGS requests in the threat
> model.  If the attacker is an insider or has compromised just one client
> account, they can try to build their valid principal list using TGS
> requests instead of AS requests.  If we're just trying to obscure user
> principals this might not be too hard, assuming users have DISALLOW_SVR
> set.  We'd have to send back S_PRINCIPAL_UNKNOWN instead of
> MUST_USE_USER2USER when the service principal has that flag.
> (Additional attention might need to be given to the user-to-user code
> path, as the attacker could try user-to-user with a bogus TGT.)  If
> we're also trying to obscure service principals, the problem becomes
> much harder; we'd have to issue dummy service tickets for invalid
> services, again making sure the ticket size isn't distinguishable, and
> making the choice of ticket session key enctype indistinguishable from a
> normal service principal.  Issuing dummy service tickets would create
> many problems for legitimate users, such as breaking
> dns_canonicalize_hostname=fallback.
>
> Finally, none of the above analysis considers side channels.  If a dummy
> response takes a measurably different amount of time for the KDC to
> synthesize than a normal response, an attacker still might be able to
> distinguish valid from invalid principal names.
>