RE: Issue 282: backward compatibility, proposed text

["Joseph Salowey (jsalowey)" <jsalowey@cisco.com>]

Hi Stefan,

This looks good.

Thanks,

Joe

> -----Original Message-----
> From: Stefan Winter [mailto:stefan.winter@restena.lu] 
> Sent: Wednesday, February 11, 2009 1:13 AM
> To: Joseph Salowey (jsalowey)
> Cc: radiusext@ops.ietf.org
> Subject: Issue 282: backward compatibility, proposed text
> 
> 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/>