guanxi and the trust gateway
Wed, Mar 28, 2007
This is something I wrote months ago but thought I’d blog it anyway. The functionality is in use in the Guanxi SP just now, to allow Guards to communicate with their Engine via HTTPS without manual intervention to populate truststores.
One of the bugbears I have with HTTPS in a collection of entities is the fact you have to continuously update your truststore with their client certificates and optional trust chains. Wouldn’t it be nice if the trust in an entity collection such as a Shibboleth federation could be handled at a higher level? What do I mean by higher level? Well, instead of my having to get hold of certificates all the time and adding them to my truststores, I could just decide to trust an entity, based on it’s endpoint address.
Let’s map out a scenario. There is an Attribute Authority (AA) at https://guanxi.uhi.ac.uk/AA. Before my Service Provider (SP) can communicate with it, the SP must be in possession of the AA’s certificate. That takes human intervention. A human must email me the certificate and I must manually import it into the SP’s truststore. It would be nice if my SP could just trust https://guanxi.uhi.ac.uk to identify itself. i.e. have the AA send the SP it’s certificate directly, without any human intervention.
If I’ve trusted the original human to be who they say they are and also to have enough authority to state that I should trust the certificate they’re sending then I should have no bother in trusting other assertions they make, such as “you can trust https://guanxi.uhi.ac.uk to identity itself”. Basically, they’re delegating their statement of trust to the machine. The machine will now send me the certificate. Well, it won’t send me it, it’ll send the SP the certificate.
The fly in the ointment now is the fact that a local system will not communicate with a remote system via HTTPS unless the local system can authenticate the remote one. i.e., in Java, the local system needs a truststore with the remote system’s certificate in it. But in this scenario, the remote system is in the process of adding it’s certificate to the reply and sending it down the pipe.
The Guanxi Trust Layer gets round this by using a Trust Gateway. The Trust Gateway can be configured to work at the higher trust level, the domain level, i.e. “you can trust https://guanxi.uhi.ac.uk to identify itself”. So it does just that. It delegates to a probing layer in the Guanxi SSL layer that defers authentication until it has extracted the remote system’s certificate from the socket connection. It then dynamically creates an in-memory truststore and adds the remote system’s certificate to it. It then delegates back to the normal trust mechanism in the SSL layer, to allow for proper authentication of the remote system.
Although it dispenses for the need to distribute certificates within a federation, it doesn’t allow just anyone to join a federation. The normal rules, process and governance must be followed to validate the entities joining the system. Once they’re in though, the Trust Gateway on the SP will allow for dynamic certificate authentication without having to distribute the certificate of the new entities. Once they’re in the federation their entity domains are added to the higher level trust layer, the domain layer. i.e. the Trust Gateway will allow those domains to identity themselves on the wire.
Although identity extraction is dynamic on the wire now, the authentication of those identities is completed as normal. It’s just the process of populating the truststore that’s changed.
A cracker could take hijack a domain name but they’d still need to get hold of the hijacked server’s private key/public certificate chain to get past security checks at an SP. Just like just now. So the security surface of the federation remains constant, the important point being, it doesn’t increase. However, the administrative surface decreases as I no longer have to hoard certificates.
Perhaps it could even decrease the security surface as plain HTTP connections would not work.