RFC 5077 ticket key derivation
a.cudbardb at freeradius.org
Tue Mar 31 23:04:33 CEST 2015
> On 31 Mar 2015, at 15:27, Alan DeKok <aland at deployingradius.com> wrote:
> On Mar 31, 2015, at 1:53 PM, Sam Hartman <hartmans at 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.
>> 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.
The result of that could be used to key a HMAC of the administrator
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 Cudbard-Bell <a.cudbardb at freeradius.org>
FreeRADIUS development team
FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 872 bytes
Desc: Message signed with OpenPGP using GPGMail
More information about the Freeradius-Devel