Freeradius client 1.1.5

[Eivind Naess]

Hi Chris,

I am sorry that I didn't get around to reply your email before now. I
had to work with the client library on one of the projects at work and
found some more areas that could needs some improvements. I guess some
of these could be considered for version 2.0 of the client library.

1) Documentation
I find it sometimes hard to find information outside some of the
function without looking at the code, and I guess you can look into
the man page. An good idea as the project moves forward is to perform
some documentation of the globally exported functions such as
rc_config_add(...), etc.

I've had to do some work evolving round the libnl (or netlink from the
netfilter guys), this project uses doxygen to generate the
documentation for the APIs in html format (with option for PDF, etc).

The API for freeradius-client is pretty simple, but it sure wold be
nice. Doxygen might be one way of doing this, but the project may have
a different favorite. My point was mainly documentation.

2) Restructuring of the core logic
I personally like to re-factor the rc_auth(), group of functions and
to break them out into using something similar to a rc_send(fd,
handle, ...). Some applications may not want to have a blocking
interface, and rather have an API that allows a) service of multiple
requests, b) continue to work on other tasks asynchronously of the
request / response.

Comparing it to the BSD version libradius, it has an API to perform
these operations. And I find it a bit more flexible. And there exist a
patches to make it work with the TACAS+ server. Point is, the API is
more flexible to do such things as mentioned above.

3) Some attributes require additional processing
Working over this, I found some of the Microsoft attributes a bit
tougher to work through. The MS_MPPE_SEND_KEY and MS_MPPE_RECV_KEY
required decryption using the secret and the random vector sent to the
server. This isn't explicitly exported / allowed so I had to *hack* it
to get around the problem.

This can obviously be solved in many different ways, and reading the
code I get the impression that the 'secret' is not to be exposed
longer than it needs to. I don't understand why it would be a concern
since the 'secret' is resident in memory since you embed it into you
application. That is of course if you don't read it from a
configuration file with proper file attributes.

Regardless, I am starting to think that what you really would like to
do in cases for odd-ball attributes like these is to have the
application provide a callback interface in which it is passed to the
API and once you finally have validated the properties, then you walk
the list of attributes and if the attribute matches then call the
registered callback function for that property.

4) Use of OpenSSL
I see that the project provides their own implementation of MD5. I am
an embedded developer and this makes me concerned in two ways: 1)
additional code, larger footprint, 2) linking with freeradius-client
and openssl may have consequences. I've debugged one time too many
where code calls MD5_Init() within the wrong library and if one
implementation is broken then you can just imagine -- you spend ours
banging your head in the wall.

It would be nice if configure could figure out whether or not you have
md5.h, and link with openssl instead of using the provided version.

5) Other Projects
I don't know how much this matter much but I think it would be very
nice if freeradius-client (with help of configure) could compile
modules for applications in which you have installed on your system.
In this way
Third Party Software like pppd, openser, openvpn, you name your
favorite here. Could use freeradius-client from the latest sources.

I know this may a bit much to ask and it may have some negative
aspects, like they make a modification to their interface and now the
module changes, backward compatibility, etc. On the other hand, I
think the positives would be to prevent e.g. a fork of the project.
Each project do it a bit different, e.g. pppd provide their own. Bug
fixes doesn't always make it upstream, etc... If the motivator is
"one-stop-shop for radius authentication", then this might be
interesting.

So Chris, does there exist a version 2.0 branch in CVS? In case, you
think some of the above is interesting and I can give you some time to
implement these, what is the code/patch submission policies?

Are you other freeradius-client developers available on IRC?

Best Regards,
- Eivind


On Nov 12, 2007 1:50 PM, Chris Parker <cparker at starnetusa.net> wrote:
>
> On Nov 12, 2007, at 3:25 PM, Eivind Naess wrote:
>
> > Hi Freeradius-client developers!
> >
> > I have a couple of questions regarding the freeradius-client project.
> >
> > 1) When is freeradius-client-1.1.6 being released?
>
> In the near future.  Before 2008.
>
> There's some segfaults reported by the OpenSER folks that I want to
> handle a little better.  Admittedly, they are not embedding it the
> way that it's now designed to be embedded, but I think we can at
> least return an error rather than SEGV.
>
> > 2) Is there any roadmap for the freeradius-client, any chance that I
> > could help participate taking it to version 2.0? In case what are the
> > features being worked on?
>
> 1.x:
>
>    Overall Goal: Introduce embedded capabilities, while maintaining
> backwards compat as much
>      as possible.
>
>    o Internalize sequence number handling ( not use external file )
>    o Expand cross-platform support
>    o Improve cross-compiling
>
> 2.x:
>
>    Overall Goal: Improve embedded capabilities.  No requirement to
> maintain backwards compat.
>
>    o Restructure code/logic in more sensible manner, since we're not
> constrained by backwards compat.
>    o Include standard RFC attributes via header, so no external
> dictionary needed for those.
>    o Add ability to pass VSA attributes via config option on
> initialization.
>
> Other suggestions as to what the community/users of the client lib
> are looking for are certainly welcome.  Code/patches/testing/feedback
> also very welcome.
>
> -Chris
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
>