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

[Alan DeKok <aland@deployingradius.com>]

Romascanu, Dan (Dan) wrote:
> 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.

  I think that's part of the goal.  There isn't much point in having the
RADIUS WG design new cryptographic protocols.  It would seem more
efficient and secure to just leverage TLS.

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

  Hmm... the secrets would then need to contain both the cryptographic
algorithms, *and* any keys necessary for those algorithms.  That's
possible, I guess.

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

  Yes.  The WG has been focusing on TLS and DTLS for a while now.

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

  Most small devices doing RADIUS have HTTPS web interfaces.  The cost
of DTLS is likely acceptable.

  Also, if a device is doing RADIUS, it's probably forwarding,
filtering, and switching traffic at multiple Mbps.  Adding TLS for a few
packets/s is likely to be acceptable.

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

  If TLS is acceptable to the RADIUS WG, I presume it is likely to also
be acceptable to the security reviewers.

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

  IIRC, that is usually done via an administrative configuration change
on the device.

  Alan DeKok.

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