Last Call Review of draft-ietf-radext-crypto-agility-requirements-
review-ietf-radext-crypto-agility-requirements-secdir-lc-kaufman-2011-06-17-00

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.