Issue 282: backward compatibility, proposed text

[Stefan Winter <stefan.winter@restena.lu>]

Hi,

> 1.  How is backward compatibility/forward migration of RADSEC handled?
> Operational recommendations in this area should be discussed.   The
> potential for rollback attacks should also be covered in the security
> considerations section.  
>   

Section 4 of the new -03 revision reads:

4.  Compatibility with other RADIUS transports

   Ongoing work in the IETF defines multiple alternative transports to
   the classic UDP transport model as defined in [RFC2865], namely
   RADIUS over TCP [I-D.dekok-radext-tcp-transport], RADIUS over DTLS
   [I-D.dekok-radext-dtls] and the present document on RadSec.

   RadSec does not specify any inherent backwards compatibility to
   classic RADIUS or cross compatibility to the other transports, i.e.
   an implementation which implements RadSec only will not be able to
   receive or send RADIUS packet payloads over other transports.  An
   implementation wishing to be backward or cross compatible (i.e.
   wishes to serve clients using other transports than RadSec) will need
   to implement the other transports and RadSec transport and be
   prepared to send and receive on all implemented transports, which is
   called a multi-stack implementation.

   If a given IP device is able to receive RADIUS payloads on multiple
   transports, this may or may not be the same instance of software, and
   it may or may not serve the same purposes.  It is not safe to assume
   that both ports are interchangeable.  In particular, it can not be
   assumed that state is maintained for the packet payloads between the
   transports.  Two such instances MUST be considered separate RADIUS
   server entities.

   As a consequence, the selection of transports to communicate from a
   client to a server is a manual administrative action.  An automatic
   fallback to classic RADIUS is NOT RECOMMENDED, as it may lead to
   down-bidding attacks on the peer communication.

And the Security Consideration contains:

   If peer communication between two devices is configured for both
   RadSec and classic RADIUS, a failover from RadSec to classic RADIUS
   opens the way for a down-bidding attack if an adversary can
   maliciously close the TCP connection, or prevent it from being
   established.  In this case, security of the packet payload is reduced
   from the selected TLS cipher suite packet encryption to the classic
   MD5 per-attribute encryption.

Please comment if this text can satisfactorily close this sub-issue.

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


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>