Subject: Crypto-agility transition model

From: Bernard Aboba <[email-masked]>
Date: Wed, 1 Apr 2009 12:25:17 -0700

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

---

From: <[email-masked]>
Date: Tue, 7 Apr 2009 12:19:27 +0200

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

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Bernard Aboba
Sent: 01 April, 2009 22:25
To: [email-masked]
Subject: Crypto-agility transition model

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

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 7 Apr 2009 09:21:19 -0700

#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: [email-masked]
To: [email-masked]; [email-masked]
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

  
  From: [email-masked] 
  [mailto:[email-masked]] On Behalf Of ext Bernard 
  Aboba
Sent: 01 April, 2009 22:25
To: 
  [email-masked]
Subject: Crypto-agility transition 
  model

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