Stefan said:
My working copy has the following text in Security Considerations now:
If peer communication between two devices is configured for both
RADIUS/TLS transport (using TLS security) and RADIUS/UDP (using
shared secret security),and where the RADIUS/UDP transport is the
failover option if the TLS session cannot be established, a down-
bidding attack can occur if an adversary can maliciously close the
TCP connection, or prevent it from being established. Situations
where clients are configured in such a way are likely to occur during
a migration phase from RADIUS/UDP to RADIUS/TLS. By preventing the
TLS session setup, the attacker can reduce the security of the packet
payload from the selected TLS cipher suite packet encryption to the
classic MD5 per-attribute encryption. The situation should be
avoided by disabling the weaker RADIUS/UDP transport as soon as the
new RADIUS/TLS transport is established and tested. Disabling can
happen at either the RADIUS client or server side:
o Client side: de-configure the failover setup, leaving RADIUS/TLS
as the only communication option
o Server side: de-configure the RADIUS/UDP client from the list of
valid RADIUS clients
I hope that makes my intended statement clearer.
[BA] My issue is the use of a "well known" shared secret with RADIUS/UDP.
This could be fixed by requiring that a server supporting RADIUS/TLS MUST
check for a RADIUS/TLS connection before allowing use of the "well known"
shared secret.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf