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