RFC 5077 ticket key derivation

[Sam Hartman]

>>>>> "Arran" == Arran Cudbard-Bell <a.cudbardb at freeradius.org> writes:

    >> On 31 Mar 2015, at 13:19, Sam Hartman <hartmans at mit.edu> wrote:
    >> 
    >> * * Signs the administrator configured key, using the private key
    >> associated with the * SSL context, then hashes the signature to
    >> get a key of an appropriate length, * which is fed to the hmac
    >> and encryption contexts for the session ticket.
    >> 
    >> 
    >> wait. What?  I'm not parsing what you're trying to do there, and
    >> it's triggering my security spidy sense.

    Arran> Requirements:

    Arran> - A cluster of servers need to derive the same session ticket
    Arran> key without communicating with each other.

    Arran> - The key should be derived from something the administrator
    Arran> configures, and the private key set for the SSL context. So
    Arran> if administrators choose simple keys, they don't open
    Arran> themselves up to session ticket spoofing.

    Arran> - The derived key must be a fixed length.
OK.
So, I'd handle this by providing a utility to generate a strong random
key and copy that between servers.
The disadvantage is that you don't leverage the private key.
The advantage is that it's secure.

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.

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.

I don't know of a solution that meets your requirements as stated and
that I know how to evaluate the security properties of.

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
twitchy.

I now at least understand what you're trying to do, and don't have
anything specifically better to offer.

--Sam