FW: Secdir review of draft-ietf-radext-crypto-agility-requirements-06

["Romascanu, Dan (Dan)" <dromasca@avaya.com>]

Document authors and WG, 

Please respond to the issues raised by Charlie in his secdir review.

Thanks and Regards,

Dan 

-----Original Message-----
From: Charlie Kaufman [mailto:charliek@microsoft.com] 
Sent: Wednesday, June 15, 2011 9:04 AM
To: secdir@ietf.org; iesg@ietf.org; draft-ietf-radext-crypto-agility-requirements.all@tools.ietf.org
Subject: Secdir review of draft-ietf-radext-crypto-agility-requirements-06

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

This document was written based on a request/demand from the security area, so it would seem only fair that we review it fairly carefully. RADIUS was developed in simpler times and uses a naïve approach to encryption and authentication of messages. Among the least of its problems, it has a hard-wired dependency on MD5. Russ Housley - Security Area Director at the time - asked the RADEXT WG to propose remediations to the protocol (perhaps as the price of withdrawing a 'discuss' on some other work they were doing). This was in 2006.

This document does not propose remediations to RADIUS, but rather proposes requirements that any such remediations must satisfy. I've always hated IETF 'requirements' documents, because they tend to be a form of shadow boxing where people have solutions in mind and are trying not to admit it as that argue for requirements that would favor their solution when solutions are judged against requirements. That makes it especially hard for people who are not deeply involved to understand the implications of what is being said.

I couldn't figure out what solutions people might have in mind motivating these requirements. In fact, these requirements appeared to me to rule out any possible solution. In particular, page 5 para 3 line 1 says "Proposals MUST NOT introduce new capabilities negotiation features into the RADIUS protocol and crypto-agility solutions SHOULD NOT require changes to the RADIUS operational model.", where the model says that RADIUS is a stateless request/response protocol. That makes most cryptographic algorithm negotiation protocols impossible.

Actually, crypto agility for RADIUS would be pretty trivial. RADIUS uses pair-wise configured secret keys. Cryptographic algorithms could be associated with those keys, and therefore configured in the same manner as the keys. You couldn't assign the new kinds of keys unless both ends understood the new algorithms. Everything would work with no cryptographic negotiation at all. The apparent reason that doesn't address the problem is that they are trying to do much more than algorithm agility. They are also trying to improve the protocol to include features like Perfect Forward Secrecy, Automated Key Management, and authentication using X.509 certificates.

Some text in the document seems to imply that running the whole thing over DTLS might be acceptable (because DTLS would be considered a transport so it's algorithm negotiation mechanisms would not be considered new capabilities negotiation features in RADIUS). If that were acceptable, it would solve all of their other problems, though it would add a lot of heft to implementations on small devices.

The bottom line is that they are working really hard to do the right thing, but there is a danger they will be wasting their time unless someone from the security community is working with them to find a reasonable solution that works for both the RADIUS community and the security community. I have my doubts as to whether this document brings them closer to a solution, but it is certainly an opportunity for someone to volunteer to step up.

	--Charlie

p.s. One protocol nit to worry about. In section 4.3, paragraph 4, the spec suggests to one way to mitigate downgrade attacks is for initiators to remember that responders once accepted the newer (stronger) protocol, and on that basis refuse to accept the older (weaker) protocol in subsequent negotiations. While it sounds logical, it can lead to deployment problems where someone rolls out a newer responder but then finds due to some problem that they must back it out. For that case, there must be some (likely out of band) way to tell the initiator to go back to accepting the old protocol.

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