RADIUS Crypto-Agility Requirements

November 18, 2008

David B. NelsonIETF 73

Minneapolis

Draft Status

Current daft is draft-ietf-radext-crypto-agility-requirements-00.txt (recently expired)

WGLC on this draft completed on August 10, 2008.

Two technical issues were raised: Automated Key Management (RFC 4107) Support for cipher-suite negotiation

A small number of editorial issues were raised. -01 will be submitted this week.

Automated Key Management

Here is text for section 4.6:

"[RFC 4107] provides guidelines for when automated key management is necessary. At the IETF-70 meeting, and leading up to that meeting, the RADEXT WG debated whether or not RFC 4107 would require a RADIUS Crypto-Agility solution to feature Automated Key Management (AKM). The working group determined that AKM was not inherently required for RADIUS based on the following points:

o RFC 4107 requires AKM for protocols that involve O(n^2) keys. This does not apply to RADIUS deployments, which require O(n) keys

o RADIUS does not require the encryption of large amounts of data in a short time

o Organizations already have operational practices to manage existing RADIUS shared secrets to address key changes required through personnel changes

o The crypto agility solution can avoid use cryptographic modes of operation such as a counter mode cipher that require frequent key changes

Automated key management is required for RADIUS crypto agility solutions that use cryptographic modes of operation that require frequent key changes."

Negotiation RADIUS does not have a capability or feature

negotiation method. The best we have is “hint and accept” or “hint

and reject”. There are some concerns with this approach:

How to “negotiate” without disclosing credentials? How to avoid “bidding down” attacks? How does the Client / Supplicant know why it has

been rejected? And the User, too…

Cipher-Suite Selection

The NAS could "discover" the existence a cipher-suite and keys shared in common with a server, without exposing any sensitive information, using a device such as the Call-Check mechanism, to complete an Access-Request / Access-Accept (or Access-Reject) sequence without disclosing any end user credentials.

Does this require additional Error Reason Codes or other forms of messaging?

Bidding Down Attacks

What happens if the MD5 hash is cracked? In such a circumstance, MD5 couldn't be the only

mechanism used to protect the packet containing the cipher-suite “hint” or "offer".

Otherwise, an attacker recovering the MD5 key could then spoof an alternative offer, perhaps removing all offers other than MD5.

Proposals will need to discuss this issue, as well as some of the transition assumptions and requirements. 

And the requirement is…

Crypto-agility solutions cannot depend on the introduction of full negotiation capabilities into RADIUS.

The issues described in the previous slides must be addressed in any proposals.

Full disclosure of any limitations of the proposal / design in the Security Considerations section.