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.
