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 <[EMAIL PROTECTED]> 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
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
