RFC 5077 ticket key derivation

[Alan DeKok]

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.

  Good point.

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

  Yeah... that's life.

  Alan DeKok.