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