Subject: [radext] #101: Secdir review of draft-ietf-radext-crypto-agility-requirements-06‏

From: "radext issue tracker" <[email-masked]>
Date: Wed, 15 Jun 2011 06:17:27 -0000

#101: 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.

-- 
------------------------------------+---------------------------------------
 Reporter:  charliek@…              |       Owner:            
     Type:  defect                  |      Status:  new       
 Priority:  minor                   |   Milestone:  milestone1
Component:  Crypto-Agility          |     Version:  1.0       
 Severity:  Submitted WG Document   |    Keywords:            
------------------------------------+---------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/101>
radext <http://tools.ietf.org/radext/>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>