FreeRADIUS, radsec and dnssec

[Martin Pauly]

Hi,

On 06.04.2017 15:07, Michael Schwartzkopff wrote:
> But the DFN thinks there are stil some issues with FreeRADIUS 3 so that is why
> they advertise to use radsecproxy.
>
> They did not tell me yet what the issues were, but as far as
> I understood they wanted to have a dynamic home server resolution based on
> realms in eduroam.

at least there seem to be interoperability issues between FR3 (3.0.12) and
DFN's radsecproxy (1.6.8, I think). When trying to upgrade my old FR2 servers with FR3,
I came cross this:
- Proxy relationships are all configured old-style, i.e. with fixes shared secret
   and DNS CNAMEs (or even IP addresses)
- When my traveling users want to use eduroam, all is fine with FR2 on my side.
- When I replace it with my new FR3 VM (leaving outside view of CNAME/IP identical),
   my traveling users are unable to authenticate if and only if my FR3 server talking
   to DFN's radsecproxy is to terminate the request itself. If there is at least one
   Proxy step involved on my side, things are fine again.

Debugging showed that for every client, the first Access-Request arrives and
ist answered by Access-Challenge. The Access-Challenge is then discarded by
the radsecproxy, for unknown reasons.

Of course, this is not actual reason to recommend a radsecproxy at the boundary
of every realm. But putting it in enables you to sort of kill two birds with
one stone: You (and they) get the radsec benefits, and the weird issues
described above are magically gone.

For now, I simply put in the proxy step to get FR2 out of business.
As soon as I have converted this to radsec, I will try and see if I can
get some more information on that.

Cheers, Martin

-- 
   Dr. Martin Pauly     Phone:  +49-6421-28-23527
   HRZ Univ. Marburg    Fax:    +49-6421-28-26994
   Hans-Meerwein-Str.   E-Mail: pauly at HRZ.Uni-Marburg.DE
   D-35032 Marburg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5393 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20170407/8b8d0735/attachment.bin>