[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Issue 282: backward compatibility, proposed text
This looks good.
> -----Original Message-----
> From: Stefan Winter [mailto:firstname.lastname@example.org]
> Sent: Wednesday, February 11, 2009 1:13 AM
> To: Joseph Salowey (jsalowey)
> Cc: email@example.com
> Subject: Issue 282: backward compatibility, proposed text
> > 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.
> 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 firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.