On Jun 18, 2020, at 4:24 AM, Jakov Varenina <jakov.varen...@est.tech<mailto:jakov.varen...@est.tech>> wrote:
Hi Anthony and all, I have been working with Mario on this feature. Let me first answer the questions: 1) Multi-user authentication will not be supported when using this new kind of SecurityManager implementation. I agree here. What we are implementing is application/service level authentication. Using certs from the applications connection is not viable for multi-user authentication. A method similar to option 2 below would need to be implemented for such a thing. (See comments below on option 2 issues) 2) The idea was to use only CN for principal, and ignore SAN (this would be documented). But we could as you suggested forward both, or even whole certificate, and let the user to decide which one to use. According to RFC 6125 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc6125%23section-6.4.4&data=02%7C01%7Cjabarrett%40vmware.com%7Cca7271e56ce84e558a2a08d8137a41be%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637280763124731300&sdata=GoHTUKN2MVyztXmIO0l22dz2c9p0W3v2l9kOOY9a4hE%3D&reserved=0>, SAN is not replacement for CN but they complement each other. I have reservations about only forwarding the CN in the credential properties. I have been doing some research in this area I strongly feel we need to forward the entire certificate. It should also be done in a way the prevents the client from being able to forward this same key/value to the server in the authentication part of the handshake. What the SecurityMangaer is trusting is that the SSL engine did its due diligence and verified and validated the certificate. So only the SSL Engine should be able to export this “authenticated” certificate. The SecurityManager is simply trusting the third party authentication by its mean presence in the credentials, or some other out of band means. By passing the entire certificate it allows the SM implantation to use whatever portions of the certificate it wants for identity mapping. It could use the CN, something the SAN, and some extension. In order to completely remove the need for username/password, it is required that we implement this new kind of authorization on *all* geode interfaces/components (cluster, gateway, web, jmx, locator, server). The reason why we didn't have any progress is because we faced major obstacle during development when we tried to retrieve clients certificate from RMI connections (e.g. jmx connections). It seems there are no easy/nice way to retrieve it, and what we came up so far is following: 1) We have found some possible "hack solution" that could be implemented and it is described in the following paper (https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fciteseerx.ist.psu.edu%2Fviewdoc%2Fdownload%3Fdoi%3D10.1.1.224.2915%26rep%3Drep1%26type%3Dpdf&data=02%7C01%7Cjabarrett%40vmware.com%7Cca7271e56ce84e558a2a08d8137a41be%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637280763124731300&sdata=%2Fdk70AwZSk0YVPDrYESvMq2u6cV%2Bn4ia3i3BQGpgE2c%3D&reserved=0). We have started to work on the prototype that will implement this solution. I want to spend some time digging into this issue with you. I just saw yesterday you all were stuck on this and haven’t had a chance to dig in. Can I sync up with you later today? 2) Second idea is that client reads CN (principal) from certificate and sends it towards server in a same way as Username/Password is sent now over RMI connections. The downside of this solution is that server doesn't verify the originator identity, that is, will not compare received principal with one received within the client certificate. With this solution, client's that uses certificates signed by geode trusted Certificate Authority and with lower authorization privileges, can "hack" client implementation and send principal with higher ( then which was given to them with a certificate) authorization privileges over RMI connection, since that principal will not compared with one received in the certificate. As you pointed out, having the client send the certificate in the auth part of the handshake doesn’t authenticate the origin. To do this you must have a challenge. The current protocol does not have a challenge response handshake so the challenge must be pre-arranged. Like simply hashing the a password gives you the ability to replay the hash should you intercept it, same would go for the cert. Pre-arranged challenges have also their own security issues because you know some part of the message, think cracking the Enigma. A common practice would be a known challenge with salt. It solves the known message part since there is randomness at the start of the message it randomizes the output of the encryption. It doesn’t solve the playback issue that pre-arranged challenges have though. For this you need a once token of some kind. This token can be used once and only once when making a challenge. This then requires the server to remember these once tokens to avoid playback issues. Now if the server could give the client a challenge then we solve all these problems. Well now we have re-invented the SSL handshake or re-implemented our protocol to support challenge response. Obviously re-implementing SSL is silly, we should just continue using option 1 since all we want is application/service authentications right now anyway. If we do want a more robust client/server auth system that does support challenge response and many other types of authentications we should look towards SASL rather than inventing our own. Long story short, given the immediate concerns is authenticating the application not the user we should continue on option 1 and try to find a way to export the already authenticated certificate to the SM. -Jake
