Hi,
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.
Ah, I see. The spec does not mandate a fixed well-known shared secret
for RADIUS/UDP at all. It only specifies that when TLS transport is
used, security is provided on the transport layer, so the shared secret
that used to protect the RADIUS payload is useless is set to this fixed
term.
When using RADIUS/UDP, the shared secret is still chosen by the
administrator by configuration.
Would it help to clarify the first lines to read:
If peer communication between two devices is configured for both
RADIUS/TLS transport (i.e. TLS security on the transport layer,
shared secret fixed to "radsec") and RADIUS/UDP (i.e. shared secret
security with a secret manually configured by the administrator),
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.
Just to make sure people realise that RADIUS/UDP security is untouched
by this spec?
Greetings,
Stefan Winter
--
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg
Tel: +352 424409 1
Fax: +352 422473
signature.asc
Description: OpenPGP digital signature
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf