Kerberos composite authentication that reflects user's origin

Question

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.

Answer 1

It's an old question, but it's worth discussing.

What you're describing already exists. It's called Kerberos FAST Armoring and is described in RFC 6113.

The gist of the protocol is that an out of band process (say the computer logging on in Windows' case) gets a TGT using a strong password (is long, has good entropy, resistant to brute force, etc.), and uses the session key from that exchange to mix in with the users client secret to form a key that is also resistant to brute force. Now attackers have to go to significant lengths for attacks like kerberoasting and will most likely find it to be a futile attempt.

Now, in order to make the above protocol work securely, both parties need to know the mix-in key. This is accomplished by including the machine TGT (or whatever account is used) in the request beside the AS-REQ (and TGS-REQs after authentication). The KDC suddenly has a wealth of information at it's fingertips now. It knows for a fact (i.e. securely as far as Kerberos is concerned) what computer the user has logged on to, so it can then start applying policies based on the user/computer intersection based on whatever has been stored in the computer TGT.

The trade off is that you won't have interstitial services manipulating the requests in any way. Frankly that's by design and is a net positive, but the downside is that the client or KDC needs to be aware of all properties you care to apply policy against. This does make reasoning about the security of the protocol a lot easier though.

Also note that the description of your protocol may alter the base protocol significantly and. Trying to encode that much additional metadata into the protocol would be complicated and there's only so many typed holes in Kerberos that are resistant to tampering that don't break when meeting legacy parties. Modifying the crypto is also quite hazardous and the implications of doing so can leave gaping holes in the security unless you go into great detail about how this would operate exactly.

But going back to RFC 6113: it provides a structured way of extending the protocol so this sort of stuff becomes a lot easier in the future.

Answer 2

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.