[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[radext] #101: Secdir review of draft-ietf-radext-crypto-agility-requirements-06â
#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 radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>