maintaining reSIProcate compatibility with FreeRADIUS

[Daniel Pocock]

Hi,

A few years ago, I adapted the RADIUS client code from SER to work in
reSIProcate and specifically the SIP proxy, repro

I'm now reviewing the code to work out how to extend it for reTurn, the
TURN server and to see if any other changes are necessary.

Things have changed slightly since reSIProcate originally adopted RADIUS
support.  The original implementation is based on
http://tools.ietf.org/html/draft-sterman-aaa-sip-04

and that works with FreeRADIUS (or it did work at the time) although the
draft is now expired.

Since that time, RFC 5090 has emerged

I notice various differences in the RFC, e.g. the RADIUS server must
provide nonces:
http://tools.ietf.org/html/rfc5090#section-2.1.5

and may also provide other values.  reSIProcate currently generates it's
own nonces and passes all the auth parameters to FreeRADIUS for
verification.

This brings me to some questions:

Is anybody already working on migrating FreeRADIUS to the RFC variation
of DIGEST support?

If so, will older clients stop working?

How to handle STUN/TURN?  I notice STUN only uses "nonce" and not "qop"
or any of the other values, yet RFC 5090 suggests that a RADIUS server
can demand that the challenge uses those attributes.  I'm also not sure
just what value for "method" would be used with STUN.  However, it would
seem desirable to support STUN/TURN from a single RADIUS server.  STUN
auth (inherited by TURN) is described here:
http://tools.ietf.org/html/rfc5389#section-10.2
This all leaves me feeling that STUN/TURN may need it's now module in
FreeRADIUS.

Regards,

Daniel