Re: Review of draft-ietf-radext-radsec

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]