One SEC AD's review of draft-ietf-radext-crypto-agility-requirements-01

[<Pasi.Eronen@nokia.com>]

Hi,

At Dan Romascanu's request, I've taken an early look at draft-ietf-
radext-crypto-agility-requirements-01. This was probably a good idea
from Dan, since if I had sent a DISCUSS this long at IESG evaluation
time, the WG might have (somewhat justifiably) suggested doing some
rubber-hose discuss clearing on a dark San Francisco back alley :-)


Overall comment:

Currently, much of the text in this draft seems to be open to multiple
interpretations. It's possible that the WG members agree on the
interpretation (but it's also possible that they only *think* they
agree...), but someone who hasn't participated in the WG discussions
will be somewhat confused.

Personally, I'm not really a big fan of requirements RFCs (and would
rather spend the energy in getting the solutions right)... but the
AAA space certainly has some history of requirements open to multiple
interpretations (including the infamous "Housley criteria" that became
RFC 4962), and a special branch of hermeneutics devoted to interpreting
them in ways that were not always very productive :-) [and BTW -- I've
certainly done some of that myself...]

The outcome I'd really like to avoid is having IESG first approve
these requirements, and then getting a solution draft that in WG's
opinion meets the requiremnts, but is very different from how IESG
understood the requirements. So, the main intent of the remaining
comments is reducing the likelihood of this happening.


Hop-by-hop/end-to-end:

The document currently considers only "hop-by-hop" security
mechanisms, not any "end-to-end" protection (across proxies). I think
this is OK and perfectly reasonable -- but the document should say this,
and explain what this means for interpreting RFC 4962

Much of RFC 4962 is open to multiple interpretations, and some parts
of it can be read as requiring more than hop-by-hop security.  IMHO
exactly the same parts can also be read as saying hop-by-hop can be
sufficient (when done properly), and I think this document should
explicitly say it's interpreting 4962 the latter way. (And once the
document has this explanation, you might want to run it by some other
ADs, too -- e.g. Tim and Russ)


Forward secrecy:

Sometimes RADIUS is used to deliver keys (like EAP MSK) that will be
used (perhaps indirectly via additional key derivation steps) to
encrypt information that may be valuable for a long time.  Given this,
the document needs some discussion about "forward secrecy" (whether
revealing the long-term credential allows decrypting all past
communications), and if the conclusion is that crypto-agility
solutions don't need to support forward secrecy (even as
optional-to-use feature), explain the rationale behind this
conclusion.


Authentication/long-term credentials:

Authenticating the RADIUS client and server will require (manual)
configuration of some kinds of credentials (currently, the RADIUS
shared secret). The document should say something about what kinds of
long-term authentication credentials (for RADIUS entities) the
crypto-agility solutions are expected to support.

Presumably, they MUST support pair-wise shared secrets. Other
possibilities for long-term credentials could include e.g. X.509
certificates with PKI, public keys without certification
infrastructure (generate keypair + configure fingerprint of peer's
key), or Kerberos. Even if the conclusion is that nothing else than
pairwise shared secrets is needed, that should be said in the document
(with rationale explaining why).


Replay protection:

Section 4.2 says "Proposals MUST support replay protection.  The
existing mechanisms for replay protection are considered adequate and
should be maintained." I think the latter sentence needs some
clarification.  If the intent is to say replay protection provided by
the current mechanisms (i.e., basically none for Access-Request
messages) is good enough, I would disagree with that (or at least
would expect to see an explanation why that's the case for
Access-Requests). If the intent is something else, the text needs
to be clearer.


Meaning of negotiation:

The document says proposals MUST support negotiation of cryptographic
algorithms. Does "negotiation" here mean picking which algorithm to
use in the protocol (RADIUS client and server figure out an algorithm
supported by both of them), or would negotiation between system
administrators meet this requirement?

I assume the WG has rough consensus about what this means, and
ordinarily, I would have automatically assumed it's the former.  But
some earlier proposals in this space have supported only the latter
kind (which does provide some kind of algorithm agility -- it's better
than hardcoding MD5 -- but could mean synchronized manual work for
every transition)...


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.


Compromise of legacy shared secret:

Section 4.2 says "Crypto-agility solutions MUST avoid security
compromise, even in situations where the existing cryptographic
algorithms utilized by RADIUS implementations are shown to be weak
enough to provide little or no security (e.g. in event of compromise
of the legacy RADIUS shared secret).  Included in this would be
protection against bidding down attacks."

If interpreted literally, this requirement could be very difficult
to meet (perhaps impossible).

It seems to assume that for this particular peer, the administrator
has configured two different shared secrets (one for the current
security mechanisms, another for the new ones), but has not configured
whether to use the old or new mechanisms (with this particular peer),
and instead, that is negotiated somehow.

If the attacker knows the legacy shared secret, and has complete
control over the communication channel (and in particular, can drop
messages going from A to B), then it seems the attacker will be
indistinguishable from a valid peer that supports only the legacy
mechanisms (and does not know the new shared secret), and detecting
bidding down will not be possible.

Preventing bidding down in less extreme cases of compromise is of
course both possible and desirable (e.g. if the algorithms are just
weak but not breakable in real time, or if the attacker doesn't have
complete control over the communications). And the administrator could
always configure just the "new shared secret", if he/she knows that
the peer supports it.


Backward compatibility/negotiation:

Section 4.3 says "Solutions to the problem MUST demonstrate backward
compatibility with existing RADIUS implementations.  That is, a
crypto-agility solution needs to be able to send packets that a legacy
RADIUS client or server will receive and process successfully.
Similarly, a crypto-agility solution needs to be capable of receiving
and processing packets from a legacy RADIUS client or server."

The intent of this paragraph is probably right, but currently, it's
somewhat open to multiple interpretations. Would something like this
capture the intent?

"Solutions to the problem MUST demonstrate backward compatibility with
existing RADIUS implementations.  That is, an implementation that
supports both the crypto-agility solution and legacy mechanisms MUST
be able to talk with legacy RADIUS clients and servers (using the
legacy mechanisms). Acceptable solutions to determining which set of
mechanisms is used (with a particular peer) include some kind of
negotiation, and manual configuration."

Note that *not* meeting this requirement would actually be quite
difficult... if the intent of this paragraph was to require some kind
of negotiation (interpreted loosely -- anything more automatic than
manual configuration), the text should say so.


"Operational model"?

Section 4.3 says "Crypto-agility solutions SHOULD NOT require changes
to the RADIUS operational model, such as the introduction of new
commands or maintenance of [additional] state on the RADIUS server."

I'm not sure what "operational" means here -- at first I thought it
might mean "operations and management" (so the requirement would be
basically "SHOULD not complicate life for administrators"), but the
two examples given don't seem to fit that very well. And it seems any
solution that e.g. derives fresh session keys will involve some small
(but greater than zero) amount of additional state on clients and
servers.

If the intent was really operations and management, perhaps the should
be rephased something like "When using long-term shared secrets for
authentication, crypto-agility solutions SHOULD NOT require more
operations and management work than the current solutions."


"RADIUS service?"

Section 4.3 says "For example, proposals SHOULD NOT [..] include
definition of new RADIUS services."

What's a RADIUS service -- i.e. what types of proposals this
definition would disqualify? (In RFC 2865, "service" is defined as the
service provided by the NAS to the user, but that definition doesn't
seem applicable here.)


Best regards,
Pasi

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>