This issue relates to previous discussions of whether the requirements of RFC 4107 mandate that an automated key management be part of a RADIUS crypto-agility solution.
In previous discussions, the conclusion seems to have been that the requirements of RFC 4107 did not apply to RADIUS (e.g. only O(n) pre-shared secrets needed).
The argument here seems to be that if you support forward secrecy and algorithm negotiation then this implies automated key management.
That would seem to go beyond what is in RFC 4107, no?
From: bernard_aboba@hotmail.com
To: radiusext@ops.ietf.org
Subject: Crypto-agility requirements: Automated Key Management concern (from Issue 303)
Date: Sun, 28 Jun 2009 14:02:59 -0700
Automated Key Management:
Well... RADIUS certainly requires only O(n) keys, but on the other
hand, the amount of data encrypted with a single key is not
necessarily small (when considering the "value of the data" and time
aspects -- in terms of gigabytes, it's probably small compared to what
decent algorithms can handle).
And if you anyway support negotiating the algorithms (in the
protocol), generating a fresh session key may not be that much extra
effort, and may be needed anyway since the key can depend on the
selected algorithm (if you negotiate 256-bit AES, you need a 256-bit
key; if it's 3DES, 168 bits, etc.). And the solutions should avoid
using the same cryptographic key with multiple algorithms (and the
easiest way to ensure this would probably be fresh session keys).
Generating a fresh session key probably also simplifies replay
protection (it's the obvious time to e.g. reset counters to zero), but
other approaches to replays are certainly feasible.
And obviously, forward secrecy and supporting any other types of
long-term credentials than shared secrets requires automated key
management of some kind.
So, I think the conclusion here needs at the very least some
qualification and additional explanation.
*If* a solution not supporting forward secrecy and not supporting
other types of credentials is acceptable, *and* replay protection is
solved in certain way, *and* the solution can ensure that the
negotiated algorithms get keys appropriate for them, *and* the
solution can ensure that two algorithms don't use the same key, then
you might get away with no AKM. But even then, AKM might be less work.
|