[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Crypto-agility requirement and draft-zorn-radius-encattr/draft-zorn-radius-keywrap
Crypto-agility isn't just the ability to substitute one algorithm for
another, it should include the jettisoning any unnecessary baggage that
might've been appropriate (or required) for one algorithm if it's not
appropriate (or required) for another.
Let's just say that crypto-agility includes negotiation of parameters
relating to the cryptographic algorithms, as well as the algorithms
One question that I'd like to understand is the extent to which the
negotiation can be protected in either of the proposals.
WIth DTLS, in the absence of DNSSEC, I think that an attacker in the middle
could subvert the DTLS up-negotiation, so as to cause a client and server
that support DTLS to negotiate plain RADIUS. So some sort of policy
pre-configuration is required (e.g. RADIUS server requires DTLS on these
NASes). With DNSSEC, it is possible to specify whether a NAS/Server
supports DTLS in a DNS SRV RR, so it seems like protected negotiation would
I'm not sure about the level of protection provided in draft-zorn.
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.