Hi again,
As a consequence, the selection of transports to communicate from a
client to a server is a manual administrative action. An automatic
fallback to RADIUS/UDP is NOT RECOMMENDED, as it may lead to down-
bidding attacks on the peer communication.
[BA] If a fixed shared secret "radsec" is used alongside fallback to
RADIUS/UDP,
that seems more like a MUST NOT!!
That paragraph was also brought up in the AD review. It was not meant in
the way you perceived it; please see the thread of the AD review of this
document for an extensive explanation how it was really meant.
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.
If I'm not mistaken, IETF LC period is now over. I plan to produce a new
-11 revision tomorrow to prepare the IESG review phase. It would be nice
if you could let me know whether the changes I did in the document
satisfactorily address your concerns.
Greetings,
Stefan Winter
In any case, I take the point that the text is confusing for readers.
While resolving the AD comments, I agreed with Dan Romascanu to
reformulate this whole paragraph and move it to Security Considerations
instead. I'll follow up with the new text later today.
Section 6
In the case of dynamic peer discovery as per
[I-D.ietf-radext-dynamic-discovery], a RADIUS/TLS node needs to be
able to accept connections from a large, not previously known, group
of hosts, possibly the whole internet. In this case, the server's
RADIUS/TLS port can not be protected from unauthorised connection
attempts with measures on the network layer, i.e. access lists and
firewalls. This opens more attack vectors for Distributed Denial of
Service attacks, just like any other service that is supposed to
serve arbitrary clients (like for example web servers).
In the case of dynamic peer discovery as per
[I-D.ietf-radext-dynamic-discovery], X.509 certificates are the only
proof of authorisation for a connecting RADIUS/TLS nodes. Special
care needs to be taken that certificates get verified properly
according to the chosen trust model (particularly: consulting CRLs,
checking critical extensions, checking subjectAltNames etc.) to
prevent unauthorised connections.
[BA] I'd recommend collecting this and other dynamic-discovery related
material
into a separate section prior to 3.1.
Moved out of the document, to go into dynamic-discovery.
Appendix C. Assessment of Crypto-Agility Requirements
The RADIUS Crypto-Agility Requirements (link to RFC once issued here)
defines numerous classification criteria for protocols that strive to
enhance the security of RADIUS. It contains mandatory (M) and
recommended (R) criteria which crypto-agile protocols have to
fulfill. The authors believe that the following assessment about the
crypto-agility properties of RADIUS/TLS are true.
[BA] The Crypto-Agility RFC is now published so you should reference that.
Done now in my working copy.
Thanks for this extensive review, much appreciated!
Greetings,
Stefan Winter
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
--
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