1

I'm experimenting with Kerberos and was wondering if some sort of composite authentication that identifies both a user and the origin of the users request was a) possible and b) implemented anywhere.

What I'm after is a setup where there is an intermediate entity (it could be the users machine, it could be the router the client is connecting through) that alters a client's messages to an Authentication Server (AS) so that they identify both the user and the origin of the request. The AS can then take this alteration into consideration and send back a TGT that can be used to grant access based on the source.

This could be used, for example, if you had a computer terminal at the counter of a shop and another in the back office. Each terminal would alter requests to the AS to reflect the source, and the terminal at the shop counter could be given less access as it is potentially more vulnerable.

I'm aware of principal instances but my understanding is that these are just considered as separate principals and the user has to have different credentials for each instance. I'm trying to achieve something that would both allow more granular access control and allow the user to use just one set of credentials.

As for feasibility, my first attempt at describing a scheme in which this could be achieved would be to make the following alterations to the Kerberos scheme:

  • All source entities have key pairs and principals that are distinct from the principals used by users.

  • The principal received by an AS may either be a user's principal or a user's principal that is a combined with a source's principal to form a composite principal.

  • Composite principals are of course valid principals and are created to be recognisable so anyone who knows about this scheme may recognise and decompose the principal to retrieve the original ids, and do so in such a way that both ids are can be recognised as either a source or user id. Furthermore, source and user ids are limited to allow for the creation of unambiguous composite principals.

  • The entity altering messages from the client would replace the principal being sent to the AS en route with a composite principal which had an origin id encoded in it.

  • If the AS is sent a composite principal, it'll encrypt the response using the user's shared information and then it'll encrypt this encrypted message using the public key associated with the origin's principal. Failure to find either the user's principal or source's principal will result in the same response as if a search had been done with an ordinary principle.

  • If the AS is sent a non-composite principal the AS will just use the received principal as a user's principal and behave as normal.

  • The source entity that altered the message from the client en-route to the AS will decrypt messages coming back from the AS using it's own private key, and then send the message on to the client. The entity does not have the clear text message as it does not know the user's secret (either password or private key).

I don't think this alters the protocol in any significant way, should allow naive clients to continue working and probably could be achieved by altering the logic that encrypts messages for the client on the AS. It would allow a user to be given one set of credentials and then there access from a particular origin would by entirely determined by the AS.

Obviously there are drawbacks, but I think the above would be adequate in my use case. Machines used would need to be trusted, but this is the same with Kerberos anyway, and users would have to be trusted not to subvert the source key pairs, but this is achievable in my use case. Of course any non-composite principal would have to be given the users least privileges to prevent escalation attacks.

This may have been implemented, it may be part of a different scheme or there may be something more appropriate to my needs; I'm fairly new to this particular area so I'm still figuring things out. If I'm wildly off track, do say. I have looked around for something along these lines but have yet to find anything that matches what I'm describing.

|improve this question
  • Heh, i'm not too familiar with kerberos' AS' but I do not particularly see anything wrong with giving different privileges to different clients based on client location. The trick is "how to ensure that what the server understands as a location cannot be spoofed?" (or "can i spoof the machine that i trust?"). And I believe that that should actually be your question. Because right now, your question is too open ended (as in: there are too many possible answers) for SE. – grochmal Dec 1 '16 at 2:00
  • Is your primary goal for this modification to prevent use of a stolen user principal ticket by an attacker on a different system (source entity)? – PwdRsch Dec 1 '16 at 2:17
  • @grochmal with regards to it being possible, I was more sounding out if there was fundamental flaw that I was missing that would mean it's not possible. It still leaves the second initial question, has anyone implemented anything like this? I presented the example alterations as a way that it could be done in case something like this already existed. Looking back at it I appreciate this question might be to open ended, perhaps I should have sat on it before posting. – Aubrey Stark-Toller Dec 2 '16 at 17:25
  • @PwdRsch My primary goal is to mitagate attacks on stolen credentials from locations that are valid source entities. Specifically, a scenario where a user uses many machines with different levels of security. If a user's credentials are stolen and used from one of these machines that has been breached, the attacker would be unable to access services available on more secure machines. To get this higher level of access they would then need to breach said secured machines and, if nothing else, this would buy time to revoke the stolen credentials. – Aubrey Stark-Toller Dec 2 '16 at 17:31
0

Be wary of trying to alter a security protocol; it can be hard to spot subtle flaws. Backing up a step, you said:

authentication that identifies both a user and the origin of the users request

...and...

My primary goal is to mitagate attacks on stolen credentials from locations that are valid source entities.

The Kerberos protocol allows tickets to contain one or more IP addresses, reflecting the origin of the user's request. The intent of putting the IP address into the ticket is to mitigate attacks on stolen credentials, which seems to be exactly what you are asking for.

There may be reasons why ticket addresses don't work for you (such as if DHCP and/or NAT mean your client machines don't have fixed addresses), but it should be one of the things you consider.

You might also look into Proxiable or Forwardable tickets; your clients could send tickets to a secondary service which looks at the origin of the ticket to decide how much to trust the ticket.

|improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.