Radius, Radsec, Diameter [was: Silly question - secure Radius?]

[Alan DeKok]

Artur Hecker <hecker at enst.fr> wrote:
> well, from my perspective the main arguments would be:
...

  Those are all nice arguments for diameter, and good reasons why the
protocol was designed.

  But I keep coming back to: Where are the client implementations?
There are few to none client implementations.

> - reliability (especially for accounting)

  radsec from the NAS to the RADIUS server would solve this.

> udp is generally not very handy when you want more control over the NAS, 
> even if i understand the initial motivation to base radius on it. 
> however, today you run in all those problems with NAT, session 
> initiation in firewalled environments, reliability, security and so on.

  radsec solves this, too.

> - server-initiated messaging
> the strict client-server design of radius (imho amplified by the use of 
> the conn-less UDP) does not allow for server-initiated commands such as 
> "disconnect" or "force re-authorization on profile changes" (very 
> important with PBM)

  Huh?  See the "disconnect request" packets.  Radclient even supports
this!

> - NAS management
> radius-typical fqdn/shared secret based security simply does not scale. 
> it is too complicated to manage NAS in this manner and often results in 
> network-wide radius passwords.

  radsec with per-NAS certificates solves this.

> - security with proxying
> in Radius proxies can modify packets. this is often not a good thing to 
> do. diameter has a far better and more extensive support for TLS, 
> especially for roaming scenarios. security might not be an issue in the 
> way radius is typically used, but its security definitions are 
> completely obsolete (strange md5-based hashing is not exactly the state 
> of the art, and right now ipsec support is as improbable with NAS as 
> diameter-support itself :-)).

  radsec doesn't support this, but there was a radius + kerberos draft
which did.  Recent opinions in the radius working group indicate that
dropping this might have been a mistake.

> well, we have seen a lot of implementations (especially in the hotspot 
> management area) where people use HTTP from server to NAS to trigger 
> radius-requests to be sent towards the server (!). it's nonsense.

  Yup.

  Alan DeKok.