RE: I-D Action:draft-ietf-radext-dynamic-discovery-00.txt

["Glen Zorn" <glenzorn@comcast.net>]

Stefan Winter [mailto://stefan.winter@restena.lu] writes:

> Hi,
> 
> >   My $0.02, as suggested in earlier emails:
> >
> > ...
> >    The discovery process is always susceptible to bidding down
> attacks
> >    if a realm has SRV records for RADIUS/UDP and/or RADIUS/TCP as
> well
> >    as for RADIUS/TLS and/or RADIUS/DTLS.
> > ...
> >
> >   This discover should be *forbidden* for RADIUS/UDP and RADIUS/TCP.
> >
> >   The only consumer of this dynamic discovery right now is RadSec.
> So
> > forbidding RADIUS/UDP and RADIUS/TCP from using this method has no
> > impact on existing systems.
> >
> 
> I agree. I didn't put anything to that effect into the draft because it
> got discussion (and IIRC some support) from others in the room last
> time. I'm happy to restrict discovery to TLS-based methods (i.e. DTLS
> and TLS) if nobody objects.

Just out of curiosity, why are we doing this?  In the revision of RFC 3588,
the dime WG has pretty much removed this capability because it was used by,
well, no one.  If it actually used by EDU Roam, that's fine, but does it
need to be standardized?

> 
> 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/>


--
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/>