[radext] RFC 7360 on Datagram Transport Layer Security (DTLS) as a Transport Layer for RADIUS
aland at freeradius.org
Fri Sep 5 15:23:58 CEST 2014
Michael Richardson wrote:
> On the topic of radiusclient: I've updated ServPOET from a really old version
> of radiusclient (one prior to freeradius!), to the latest git tree, and I've
> updated the client with some IPv6 TLV needs.
> I will issue a pull request soonish.
> DTLS support for radiusclient would be a good thing to do; I wonder how
> small it can be made... I'm thinking that using raw public support in
> DTLS along with TOFU would be a really simple way to bootstrap (the admin
> would have to lock down the keys using a "mv" operation...)
The radiusclient code is pretty bad, TBH. I don't think I'd want to
add OpenSSL support to it. We've done that in the server, and it's a
lot of work.
TBH, for embedded systems, I would recommend radsecproxy for all SSL
work. It's simple, small, and supported.
> btw, I really dislike having to carry all the dictionary files into an
> appliance system, and worse, parsing the files in each of the 6000 pppd's
> that runs. I'm thinking of a preparse dictionaries to .c data structure
> mechanism... what do you think?
I have some code to do that. But doing that involves major changes to
radiusclient, which I'm not inclined to do.
> It seems that client systems that link
> radiusclient *know* what TLVs they can deal with, the admin can not really
> add any new ones unless there is a scripting system on the client system.
Yes. Embedded systems should have their "known" attributes
hard-coded. Any other attributes are by definition unknown, and
More information about the Freeradius-Devel