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

[Artur Hecker]

hi


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

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


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


ciao
artur