RFC 5077 ticket key derivation
aland at deployingradius.com
Tue Mar 31 21:27:21 CEST 2015
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.
> Alan says something about a per-user ticket session key.
> You don't need that; you can have the same encryption key per-cluster,
> provided that you both encrypt and MAC and you don't do something
> horrible with how you encrypt things like reuse counters or nonces.
I have no idea how the session tickets are encrypted. That's the responsibility of the TLS people.
> You're assuming that if I sign the same data twice the signature will be
> the same.
> That's true for RSA with a particular old type of padding.
> That is not generally true of public key signatures.
> I can't remember off the top of my head if it is a desirable security
> property that signing the same item multiple times generates distinct
> signatures or not.
> 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)
Which should still be secure, easy to derive, and hard to crack.
> Besides what I mentioned above , you could take the private key itself
> plus the input from the administrator and use that to key an hmac you
> use for key derivation. In practice that's probably secure, except that
> it doesn't work with smart cards/cryptographic security modules, and
> that using a private key other than as a private key will make people
Yeah... that's life.
More information about the Freeradius-Devel