Radius, Radsec, Diameter [was: Silly question - secure Radius?]
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
>>- 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
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