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
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf