#7 is an assumption, albeit a somewhat optimistic one. Amazing how many operators actually deploy RADIUS with a single shared secret for all RADIUS clients. RFC 2865 does refer to the possibility that a RADIUS client would have the same shared secret with multiple servers in the same realm.
#6 would be a protocol requirement if the keys were derived. If the keys are chosen to the administrator, it is largely an assumption about administrator behavior with some implications for implementers. As an example, RFC 2865 Section 3 contains some advice relating to the strength of the legacy shared secret that would have implications for the minimum supported size of the shared secret field:
The secret (password shared between the client and the RADIUS
server) SHOULD be at least as large and unguessable as a well-
chosen password. It is preferred that the secret be at least 16
octets. This is to ensure a sufficiently large range for the
secret to provide protection against exhaustive search attacks.
The secret MUST NOT be empty (length 0) since this would allow
packets to be trivially forged.
From: Pasi.Eronen@nokia.com
To: bernard_aboba@hotmail.com; radiusext@ops.ietf.org
Date: Tue, 7 Apr 2009 12:19:27 +0200
Subject: RE: Crypto-agility transition model
Hi Bernard,
Items #1..#4 seem to provide one reasonable transition model, and
in particular, the assumptions in #2 would make my comment about "Compromise of
legacy shared secret" largely moot.
About #6: is this intended to be an assumption (we assume that
administrators never use shared secrets they can remember), a
requirement for
administrators (basically unenforceable, and putting administrator requirements
in RFCs intended for implementors probably isn't very effective anyway since the
administrators won't read this), or a protocol requirement (given realistic
assumptions about administrators, the protocol must prevent brute-force
attacks)?
#7 certainly looks like an assumption or somewhat misplaced and
unenforceable requirement (although in theory, we could require that management
interfaces enforce unique credentials -- but probably implementors would ignore
that requirement).
Best regards,
Pasi
At IETF 74, we discussed Pasi Eronen's review of the RADIUS
Crypto-agility requirements document. Several of the issues that arose
related to the transition model. My proposal is that we explicitly
discuss the envisaged transition model in the document. One proposal for
a transition model is enclosed below. Comments solicited.
1. The transition model for RADIUS crypto-agility issues that
the RADIUS server is upgraded first, and that RADIUS clients are then upgraded
over time. This implies that we can assume that the RADIUS server is
crypto-agile from day 1, and that there are a mixture of capable and
non-capable RADIUS clients until all RADIUS clients have been upgraded to
support upgraded operation.
2. Once all RADIUS clients have been
upgraded, it is assumed that the RADIUS server is set to require all RADIUS
clients to utilize upgraded ciphersuites. Furthermore it is assumed that
the transition is completed prior to the time at which MD5 security is
compromised. For the purposes of the requirements document, such as
breach would be considered to enable the forgery of RADIUS packets protected
by existing ciphersuites (e.g. MD5, HMAC-MD5). Once such a forgery
becomes possible, packets protected by legacy ciphersuites can no longer be
trusted and therefore it is no longer feasible to allow use of legacy
ciphersuites to integrity protect RADIUS packets. One corollary of this
assumption is that the use of MD5/HMAC-MD5 to protect a ciphersuite
"negotiation" is acceptable during the transition period.
3. During
the transition period, it is assumed that each RADIUS client utilizing legacy
ciphersuites is provisioned with a unique legacy shared secret. If this
assumption holds true, then during the transition period, it is possible for
the RADIUS server to authenticate a legacy RADIUS client's identity and apply
appropriate per-client policies (see #4 below).
4. During the
transition period, the RADIUS server is required to support access both by
legacy RADIUS clients as well as upgraded RADIUS clients. Secure
operation during the transition period can be accomplished in one of two
ways:
a. RADIUS server policy. If a RADIUS client
is known to be upgraded, the RADIUS server can require that this RADIUS client
operate in the upgraded mode. This assumes that an upgraded RADIUS
client cannot masquerade as a legacy RADIUS client so as to evade the policy
(see the assumptions in #2 and #3). Note that if an upgraded ciphersuite
requires provisioning of new pre-shared keys on the RADIUS server, then
client-specific configuration will probably be needed anyway.
b. "Negotiation". If the administrator does
not wish to keep track of which specific RADIUS clients have been upgraded,
then he/she can enable the RADIUS server to accept use of upgraded
ciphersuites from RADIUS clients that offer it as well as to accept use of
legacy ciphersuites. Based on the assumptions in #2, it is acceptable
for such an offer to only be protected by a legacy shared secret during the
transition period.
5. It is REQUIRED that compromise of
the legacy shared secret not result in compromise of shared secrets or session
keys used by any of the upgraded ciphersuites. This is required
since we need to assume that an attacker could have captured previous RADIUS
exchanges that could enable recovery of the legacy shared secret in the
future. Therefore even if legacy ciphersuites were no longer in use,
compromise of upgraded RADIUS clients and servers would be still be possible
if compromise of legacy shared secrets could enable attacks on upgraded
ciphersuites.
6. It is REQUIRED that keys utilized by upgraded
ciphersuites be sufficiently strong to prevent attacks by brute force.
If we don't make this assumption, then negotiation of upgraded cryptographic
algorithms is pointless.
7. It is REQUIRED that administrators
assign unique credentials to RADIUS clients for use with upgraded
ciphersuites. If this is not done then RADIUS servers may not be
able to distinguish upgraded RADIUS clients from one another. This could
prevent RADIUS servers from correctly applying security policies to upgraded
RADIUS clients (e.g. RADIUS server wouldn't be able to distinguish NAS A that
supports Ciphersuite A and B from NAS B that only supports Ciphersuite B).
|