On 31 Mar 2015, at 15:27, Alan DeKok <aland@deployingradius.com> wrote:
On Mar 31, 2015, at 1:53 PM, Sam Hartman <hartmans@mit.edu> wrote:
So, I'd handle this by providing a utility to generate a strong random key and copy that between servers.
Which means that the systems have to communicate, and there's one more step to getting it to work.
Agreed.
Hashing the signature definitely makes it better. The enginex design really scares me.
My updated recommendation to Arran is to simply do:
key = hmac_sha256(server key, user identifier)
Call it an administrator key. It's not necessarily a user ID. It may have nothing to do with the request. It may be the thing that changes in order to implement key rotation. It's left up to the administrator to set. If they don't care so much about security, it could just be static. The likelihood of the private key being compromised is low. OTOH it could be a call out to the rlm_cache xlat function, which could use the rlm_rest xlat function to fetch a key from some central key generation and rotation service. The point is to accommodate the security requirements of different users without allowing them to shoot themselves in the foot.
Which should still be secure, easy to derive, and hard to crack.
Going to try out this, and see whether the generated keys are the same over multiple calls. https://www.openssl.org/docs/crypto/EVP_PKEY_derive.html The result of that could be used to key a HMAC of the administrator provided data. The hashing should resolve any issues with abusing EVP_PKEY_derive (by using it with both the server's private and public keys). With the first method I suggested, the signature did appear to be consistent with RSA keys and OpenSSL 1.0.1f, using the default engine and SHA256 as the digest. But it looks like for DH and EC the signature would change each time. So for OpenSSL < 1.0.0 the above hmac_sha256 would probably be ok. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2