freeradius-client with IPv6 and DTLS

[Alan DeKok]

On Dec 23, 2014, at 2:49 AM, Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
> The advantage of freeradius-client is that it has a very easy high
> level API and could be used with a simple config file without a low
> level knowledge of the radius protocol.

  It wouldn’t be that hard to wrap libfreeradius-radius with such an API.  But… OK.

> That is why I preferred to
> modify that library, and the changes for DTLS weren't that large
> actually.  They simply wrap over the sendto() and recvfrom(). The only
> tricky part is that they serialize every communication over a single
> DTLS session, and that would affect multi-threaded programs using that
> library, as the sendto(), recvfrom() need to be atomic. I introduced
> locks to solve that, but a proper multiplexer could be a better solution
> for such programs.

  If someone needs to send hundreds or thousands of RADIUS packets, they can spend the time to fix the code.

> Unrelated: 
> If I can mention a small omission in the DTLS rfc is that it doesn't
> specify a key purpose in the certificates to be used for radius. For web
> servers the "TLS WWW server authentication" OID is used in extended key
> usage, but there is no equivalent for DTLS radius servers.

  The "TLS WWW server authentication” OID is not required by RADIUS.  Microsoft requires it for their clients, which is annoying.

  I’m not sure there’s a major benefit to adding an OID specifically for RADIUS authentication.

> I'd really prefer to fix any issues that result of that change instead
> of having the auto-generated files included. It is very cumbersome to
> work with a repository which has 20 files modified because I changed
> something in a Makefile.am. I've almost forgot to add all new files
> because git status shows so many changes it is difficult to distinguish
> what matters or not.

  Sure.  You could create an “autoconf” branch, and put the generated files there.  Have a script which merges all of the patches from “master", regenerates the files, commits them, and then checks out “master” again.  That way you get the best of both worlds.

>> $ ./autogen.sh … $ ./configure … configure: creating ./config.status
>> config.status: error: cannot find input file: `Makefile.in’
> 
> The autogen.sh run has failed for some reason in that platform. It's
> best to fix that anyway.

  The autogen.sh file didn’t fail.  It succeeded.  And this is on an Ubuntu 14.04 system.  If autogen doesn’t work there, there’s no reason to expect it to work *anywhere*.

  This is why I *loath* projects that don’t include configure, etc. in a checkout.  autoconf, etc. are such horrible crap that they just don’t work across multiple systems.  The only person capable of creating a “configure” script is the person who committed the “autoconf” crap.  No one else can do it, which makes autoconf nearly useless.

> Would be nice. Note that the IPv6 changes break the API and ABI by
> removing several helper functions. However, the removed functions were
> simply a wrap over the standard socket (IPv4) library, so I find it
> unlikely that will seriously affect any project using that library.

  That’s fine.

  Alan DeKok.