[radext] RFC 7360 on Datagram Transport Layer Security (DTLS) as a Transport Layer for RADIUS

[Alan DeKok]

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.

  Thanks.

> 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
therefore unimportant.

  Alan DeKok.