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