Thoughts on RADIUS Crypto-agility

["David B. Nelson" <d.b.nelson@comcast.net>]

The RADEXT WG has a work item relating to RADIUS crypto-agility.  In 
looking at this work item and thinking about how to make progress on it, 
we would like to put forward some thoughts. 
 
RADIUS crypto-agility is about the ability of RADIUS implementations to 
negotiate cryptographic algorithms for use in RADIUS exchanges.  This 
includes the cryptographic algorithms used to protect RADIUS packets, 
as well as the algorithms used to hide RADIUS attributes. 

Today, RADIUS packets are protected by the calculation of an MD5-based 
message integrity check (MIC) within the Authenticator field of packets 
other than the Access-Request.  In addition, the Message-Authenticator 
attribute is available, which utilizes  HMAC-MD5 to authenticate and 
integrity protect RADIUS packets.

A number of RADIUS attributes today support "hiding", in order to prevent 
an attacker from snooping contents over the wire.  These attributes 
include the User-Password and Tunnel-Password attributes, in addition to 
vendor-specific attributes.  Generally the "hiding" mechanisms utilize a 
stream cipher based on MD5.  

It should be noted that the recent work on MD5 collisions does not appear 
to enable compromise of any of the MD5-based mechanisms described above, 
absent knowledge of the RADIUS shared secret.  However, the progress 
toward compromise of the basic cryptographic assumptions made by MD5 has 
lead to a movement toward deprecation of MD5 in many contexts. 

Therefore there appears to be good reason for the RADEXT WG to move 
forward toward development of a backward compatible, interoperable 
mechanism for the negotiation of cryptographic algorithms within RADIUS. 

In moving forward, the proposal is for the RADEXT WG to first discuss the 
requirements for RADIUS crypto-agility and come to consensus, and then to 
solicit proposals satisfying those requirements.   

In order to develop consensus on the requirements as well as 
potential solutions, we would propose that the RADEXT WG consider 
the following process:
 
1. Discuss and refine the requirements for a solution to the problem,
coming to consensus at IETF 68 in Prague.  
 
2. Issue a call for document submissions meeting the problem 
requirements, during IETF 68, requesting documents be submitted for 
consideration within 30 days; 
 
3. Discussion of the proposals on the RADEXT WG list; 
 
4. If consensus emerges, adoption of the winning proposal as a 
Standards Track  WG work item. 

5. If consensus does not emerge, acceptance of one or more documents
with substantial support as Experimental Track WG work items. 
 
6. Completion of work and submission of documents to the IESG. 
 
A separate message proposing a straw-man set of requirements will be posted
to the list to get the process started.

Regards,

Bernard Aboba
Dave Nelson

RADEXT Co-Chairs




--
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/>