Re: Crypto-agility requirement and draft-zorn-radius-encattr/draft-zorn-radius-keywrap

[Leif Johansson <leifj@it.su.se>]

Bernard Aboba wrote:
>>   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
> themselves.
>
> 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 be possible.
>
> I'm not sure about the level of protection provided in draft-zorn.
>
>
This problem crops up whenever a server-announced parameter needs
to be negotiated securely (for instance SASL mechanisms). What you
need to do, unless you can actually protect the parameter, is to verify
the parameter against the first set you received from the server _after_
you negotiate a secure channel, and complain if it doesn't match.

For instance, if your server was once DTLS and now isn't your client
should not silently accept a "downgrade". This requires a basic leap-of-
faith that the first negotiation was either non-intercepted or
determined by policy.

    Cheers Leif


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