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

Artur Hecker hecker at enst.fr
Thu Jul 14 21:23:50 CEST 2005


just a small preamble: i perfectly understand your position and i do not 
expect you to start a diameter implementation tomorrow :-) for me it's 
merely a strategic discussion.

Alan DeKok wrote:
> 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.

perfect, apparently we've just closed the circle:

i started this conversation by the statement "what are the manufacturers 
waiting for?" adding that we might be missing interesting opportunities 
(as a cause of manufacturers not integrating diameter). you asked which 
features i was talking about :-) and now you ask about devices. circle 

according to this funny newsgroups discussion study, that's probably the 
point where we start talking about god (since we have reached the 

>>- reliability (especially for accounting)
>   radsec from the NAS to the RADIUS server would solve this.

only partly, i think, since the reliability of accounting depends on 
more than just on the reliability of transmissions. there are things to 
specify in the implementations, especially when we start talking about 
multi-party-accounting. you have to think about accountability, 
integrity and non-repudiation. the fact that accounting support is not 
obligatory in radius does not exactly help here.

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

that's probably true. but, citing you: where are the client 
implementations? do you know of any radsec-cacable 802.11 access point? 
that would interest me personally.

and what is radsec anyway? it is not an RFC standard track and why would 
i implement proprietary solutions when the sense is to enable a 
multi-domain operation?

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

hmmm?? well... PoD is probably the ugliest hack ever. imho, PoD is not a 
solution but a proof that things have been badly overseen during the 
Radius-design and especially re-design phases.

and anyway it only partially answers my question. disconnect is just ONE 
possible application. what about a complete PBM solution?

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

true and same as above: not a standard, no NAS.

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

*provoke* why talking about drafts when we have a standard track 
protocol which supports this? :-)

radius+kerberos: if it used used radius as a trusted third party, then 
it does not surprise me that it has been abandoned...


More information about the Freeradius-Users mailing list