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. ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
