Thoughts on Requirements for RADIUS crypto-agility

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

As noted in the previous message, the first stage in the development of 
a RADIUS crypto-agility solution is to formulate a requirements statement. 

A straw-man set of requirements is included below:

OVERALL APPROACH

1. RADIUS crypto-agility solutions are not restricted to utilizing 
technology described in existing RFCs.  Since RADIUS over IPsec is 
already described in RFC 3162 and 3579, this technique is already 
available to those who wish to use it.  Therefore it is expected that 
proposals will utilize other techniques. 

SECURITY SERVICES

2. Proposals MUST support the negotiation of cryptographic 
algorithms for per-packet integrity/authentication 
protection.  Support for confidentiality of entire RADIUS 
packets is OPTIONAL.  However, proposals MUST support the negotiation of 
algorithms for encryption (sometimes referred to as "hiding") of RADIUS 
attributes.  If possible, it is desirable for proposals to provide for the 
encryption of existing attributes.  This includes existing "hidden" 
attributes as well as attributes (such as location attributes) that 
require confidentiality. 

3. Proposals MUST support replay protection.  It has been noted that 
existing mechanisms for replay protection of Accounting-Request/Response, 
CoA-Request/Response and Disconnect-Request/Response messages are 
inadequate.

4. Crypto-agility solutions need to specify mandatory-to-implement
algorithms for each mechanism.

BACKWARD COMPATIBILITY

5. Solutions to the problem need to demonstrate backward compatibility 
with existing RADIUS implementations.  That is, a crypto-agility
solution needs to be able to send packets that a legacy RADIUS 
client or server will receive and process successfully.  Similarly, a 
crypto-agility solution needs to be capable of receiving and processing 
packets from a legacy RADIUS client or server. 
 
6. Crypto-agility solutions need to avoid security compromise, even
in situations where the existing cryptographic algorithms utilized by 
RADIUS implementations are shown to be weak enough to provide little or no 
security (e.g. in event of compromise of the RADIUS shared secret).  
Included in this would be protection against bidding down attacks. 
 
INTEROPERABILITY AND CHANGE CONTROL

7. Proposals need to indicate a willingness to cede change control to the 
IETF. 

8. Crypto-agility solutions need to be interoperable between independent 
implementations based purely on the information provided in the 
specification. 
 
SCOPE OF WORK

9. Crypto-agility solutions need to apply to all RADIUS packet types, 
including Access-Request, Challenge, Reject & Accept, 
Accounting-Request/Response, and CoA/Disconnect messages. 
 
10. Proposals MUST include a Diameter compatibility section. 

11. Crypto-agility solutions should not require fundamental changes to the 
RADIUS operational model, such as the introduction of new commands or 
maintenance of state on the RADIUS server.  Similarly, the addition of 
new capabilities to the RADIUS protocol is out of scope; a proposal should 
focus on the crypto-agility problem and nothing else.  For example, 
proposals should not require new attribute formats or include 
definition of new RADIUS services.  Unless modified, the restrictions 
in the RADEXT WG charter apply.  

Note that for the purposes of this work, the RADEXT WG charter restriction
against definition of "new security mechanisms" should be interpreted as
prohibiting changes to the basic RADIUS packet format (e.g. headers), but
permits new crypto-algorithms to be substituted for use in existing 
security mechanisms.

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