Silly question - secure Radius?
I am just getting started with setting up Radius, and with the reading I've done (mostly with the O'Reilly book), it seems that Radius in itself is insecure. Sure, you can use a Shared Secret and the password is sent with a MD5 hash, but is there anything better? Sorry for the dumb question, Shawn
Shawn Kennedy schrieb:
Sure, you can use a Shared Secret and the password is sent with a MD5 hash, but is there anything better?
Sure, you can use the CHAP protocol or EAP protocols for authenticating, then no password needs to be send to the RadiusServer (instead, you get a challenge and your computer locally uses your password to compute a response, the RadiusServer gets challenge, respones and does the same computation to verify the password and nothing is transferred over the net which allows to obtain the password). Regards, Stefan
"Shawn Kennedy" <shawnlkennedy@lucent.com> wrote:
I am just getting started with setting up Radius, and with the reading I've done (mostly with the O'Reilly book), it seems that Radius in itself is insecure. Sure, you can use a Shared Secret and the password is sent with a MD5 hash, but is there anything better?
"radsec", which Radiator just came out with. I've taken a quick look at it, but I don't think it will be easy to implement inside of the current server. Adding it via an external program should be relatively trivial, though. Alan DeKok.
-----Original Message----- From: aland@nitros9.org [mailto:aland@nitros9.org]On Behalf Of Alan DeKok Sent: Thursday, July 07, 2005 12:36 PM To: shawnlkennedy@lucent.com; FreeRadius users mailing list Subject: Re: Silly question - secure Radius?
"Shawn Kennedy" <shawnlkennedy@lucent.com> wrote:
I am just getting started with setting up Radius, and with the reading I've done (mostly with the O'Reilly book), it seems that Radius in itself is insecure. Sure, you can use a Shared Secret and the password is sent with a MD5 hash, but is there anything better?
"radsec", which Radiator just came out with.
I've taken a quick look at it, but I don't think it will be easy to implement inside of the current server. Adding it via an external program should be relatively trivial, though.
Hi Alan, Thanks for the heads up. Wasn't aware of such a thing. I briefly looked at CHAP, but abandoned it for the obvious reasons. Looking into EAP-TLS, but don't have a PKI infrastructure set up yet. Just as a side question, is this sort of thing on FreeRadius's radar screen? Thanks again, Shawn
"Shawn Kennedy" <shawnlkennedy@lucent.com> wrote:
Thanks for the heads up. Wasn't aware of such a thing. I briefly looked at CHAP, but abandoned it for the obvious reasons. Looking into EAP-TLS, but don't have a PKI infrastructure set up yet.
EAP-TTLS or PEAP don't require client certs, only server certs.
Just as a side question, is this sort of thing on FreeRadius's radar screen?
radsec? It addresses the server->server problem, not the supplicant login problem. Sure, it's on the radar, but so far there hasn't been much *practical* interest in implementing it. Alan DeKok.
Hi!
radsec? It addresses the server->server problem, not the supplicant login problem. Sure, it's on the radar, but so far there hasn't been much *practical* interest in implementing it.
Speaking of a radar - is an implementation of the Diameter protocol something you have on that radar as well? To my knowledge, no real usable implementation exists. The only serious thing on Open Source side I have seen is opendiameter (www.opendiameter.org), but they are only providing libraries for Diameter internals so far. If you want to do a real, practical task, like "I would like to authnuse Active Directory as a backend authentication and TTLS-PAP for the credential transport" you are pretty much on your own right now. Greetings, Stefan Winter -- Stefan WINTER Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche Ingénieur de recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg email: stefan.winter@restena.lu tél.: +352 424409-1 http://www.restena.lu fax: +352 422473
Stefan Winter <freeradius-users-ml@stefan-winter.de> wrote:
Speaking of a radar - is an implementation of the Diameter protocol something you have on that radar as well?
Why the heck would we do that?
To my knowledge, no real usable implementation exists. The only serious thing on Open Source side I have seen is opendiameter (www.opendiameter.org), but they are only providing libraries for Diameter internals so far. If you want to do a real, practical task, like "I would like to authnuse Active Directory as a backend authentication and TTLS-PAP for the credential transport" you are pretty much on your own right now.
See "wire diameter", from Taiwan. I recall it's a student project, but it does give a minimal diameter server. But again, can you think of *one* client implementation of diameter? I can't. Alan DeKok.
Alan DeKok wrote:
See "wire diameter", from Taiwan. I recall it's a student project, but it does give a minimal diameter server.
But again, can you think of *one* client implementation of diameter? I can't.
well, that's not the point since diameter would be backwards compatible to radius... but i do ask myself what the manufacturers are waiting for. it could be at least an option. see also "open diameter". it even does EAP... ciao artur
Artur Hecker <hecker@enst.fr> wrote:
well, that's not the point since diameter would be backwards compatible to radius... but i do ask myself what the manufacturers are waiting for. it could be at least an option.
Diameter will be interesting ole when manufacturers ship millions of boxes with diameter. Why don't they? Let's look at what they need from RADIUS or diameter: 1) username/password authentication. Yup, RADIUS does this. 2) EAP->AAA for wireless. Yup, RADIUS does this. The nice thing about RADIUS is that it's so easy to implement. In contrast, diameter is 1000x more complicated than RADIUS, and it only solve .1% more problems than RADIUS. Diameter is not going to be widely deployed. Ever.
see also "open diameter". it even does EAP...
Not as many EAP methods as FreeRADIUS. :) Adding EAP-FAST to FreeRADIUS may not be too hard, either. Alan DeKok.
you might be right. yet i think that we might ignore some opportunities which would be possible/supported by diameter. i really believe that current usage produces demand in the same manner as demand influences the usage. using additional web-based "touches" to trigger server solicitations by the client is indeed quite ridiculous. the main problem with radius is IMHO its client-server nature. it inherently lacks control. also TCP in dimaeter and defined TLS in proxy mode might be advantageous. ciao artur Alan DeKok wrote:
Artur Hecker <hecker@enst.fr> wrote:
well, that's not the point since diameter would be backwards compatible to radius... but i do ask myself what the manufacturers are waiting for. it could be at least an option.
Diameter will be interesting ole when manufacturers ship millions of boxes with diameter.
Why don't they? Let's look at what they need from RADIUS or diameter:
1) username/password authentication. Yup, RADIUS does this. 2) EAP->AAA for wireless. Yup, RADIUS does this.
The nice thing about RADIUS is that it's so easy to implement. In contrast, diameter is 1000x more complicated than RADIUS, and it only solve .1% more problems than RADIUS. Diameter is not going to be widely deployed.
Ever.
see also "open diameter". it even does EAP...
Not as many EAP methods as FreeRADIUS. :)
Adding EAP-FAST to FreeRADIUS may not be too hard, either.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Artur Hecker <hecker@enst.fr> wrote:
you might be right. yet i think that we might ignore some opportunities which would be possible/supported by diameter.
Like... what?
i really believe that current usage produces demand in the same manner as demand influences the usage. using additional web-based "touches" to trigger server solicitations by the client is indeed quite ridiculous.
I'm not sure what you're referring to here.
the main problem with radius is IMHO its client-server nature. it inherently lacks control. also TCP in dimaeter and defined TLS in proxy mode might be advantageous.
It shouldn't be too hard to write a radsec implementation. Ideally, it could leverage the TLS code in rlm_eap. Alan DeKok.
hi alan sorry for the delay.
you might be right. yet i think that we might ignore some opportunities which would be possible/supported by diameter.
Like... what?
well, from my perspective the main arguments would be: - reliability (especially for accounting) in every related implementation we always had to tweak around the timeouts etc. just because you can't be sure that the accounting-stop arrives correctly when the user is disconnected. especially in an environment with a lot of connects and disconnects, this results in "stalled" sessions which have to be explicitly treated and where the relation to the real network usage is principally lost. this is boring. 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. - 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) - 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. - 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 :-)). that's what bothers me personally, in this order. i think there are much more of those in the diameter RFC.
i really believe that current usage produces demand in the same manner as demand influences the usage. using additional web-based "touches" to trigger server solicitations by the client is indeed quite ridiculous.
I'm not sure what you're referring to here.
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.
It shouldn't be too hard to write a radsec implementation. Ideally, it could leverage the TLS code in rlm_eap.
that wouldn't be enough for roaming cases. ciao artur
Artur Hecker <hecker@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.
On Thu, 14 Jul 2005, Alan DeKok wrote:
Artur Hecker <hecker@enst.fr> wrote:
- 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!
I think the point the original poster was making was that Diameter allows arbitrary conversations between NASes and servers that are initiated by either party, via "applications", in an extensible manner. Sure, the original RADIUS spec has been hacked around retrospectively to provide some server-initiated functionality, but it's never been very elegant. josh. ------------------------------------------------------------ Josh Howlett, Networking & Digital Communications, Information Systems & Computing, University of Bristol, U.K. 'phone: 0117 928 7850 email: josh.howlett@bris.ac.uk ------------------------------------------------------------
Josh Howlett <Josh.Howlett@bristol.ac.uk> wrote:
I think the point the original poster was making was that Diameter allows arbitrary conversations between NASes and servers that are initiated by either party, via "applications", in an extensible manner.
Yup. Which clients support diameter? I can't think of any. Until Cisco starts shipping diameter clients in their boxes, all of this discussion is wishful thinking. Alan DeKok.
apparently we do agree. thanks to Josh for his comment. just one thing: Alan DeKok wrote:
Josh Howlett <Josh.Howlett@bristol.ac.uk> wrote:
I think the point the original poster was making was that Diameter allows arbitrary conversations between NASes and servers that are initiated by either party, via "applications", in an extensible manner.
Yup.
Which clients support diameter? I can't think of any.
Until Cisco starts shipping diameter clients in their boxes, all of this discussion is wishful thinking.
see? as i said: now you _started_ talking about God :-) ciao artur
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@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
Alan DeKok wrote:
See "wire diameter", from Taiwan. I recall it's a student project, but it does give a minimal diameter server.
I took a look at it two months ago or so. It may implement the Diameter protocol, but does not have any backends on board, so the use case I mentioned (AD) or a simple MySQL backend just aren't available. Plus, I mailed the author at the time and asked him several questions about WIRE Diameter and never got a reply.
Artur Hecker wrote: see also "open diameter". it even does EAP...
Well, it does packet handling, providing only a library for the server. But in order to really use it, you must first wrap daemon glue code around the libraries, and you must be able to do something with the credentials you get from that server. Which leads to missing backends again. Greetings, Stefan Winter -- Stefan WINTER Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche Ingénieur de recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg email: stefan.winter@restena.lu tél.: +352 424409-1 http://www.restena.lu fax: +352 422473
Stefan Winter <freeradius-users-ml@stefan-winter.de> wrote:
see also "open diameter". it even does EAP...
Well, it does packet handling, providing only a library for the server. But in order to really use it, you must first wrap daemon glue code around the libraries, and you must be able to do something with the credentials you get from that server. Which leads to missing backends again.
It shouldn't be that hard to take "wire diameter", and have it convert all diameter messages to RADIUS. At that point, you've got a real server doing the work. Alan DeKok.
participants (6)
-
Alan DeKok -
Artur Hecker -
Josh Howlett -
Shawn Kennedy -
Stefan Winter -
Stefan.Neis＠t-online.de