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