Sam Hartman wrote:
> Unfortunately, when FreeRADIUS is a RADIUS server. So internally it
> converts the incoming message from Diameter to RADIUS. When it does
> that, it fails the entire authentication if it finds Diameter attributes
> that cannot be mapped to RADIUS attributes.
> This is bad. It means that if you try to perform Moonshot authentication
> against an unmodified FreeRADIUS server, it will completely fail.
It's pretty bad. I'm not even sure why I did that in the first place.
It's easy enough to fix. I've put a fix into git (v2.1.x) which will
make it into the next release.
The solution is to allow all well-formed Diameter attributes.
However, only ones which can be converted to RADIUS attributes are
converted. All others are silently ignored.
> Unfortunately, FreeRADIUS also fails the EAP-TTLS authentication if
> there is an unknown RADIUS attribute in an EAP-TTLS message.
Now that's just stupid. Who was the idiot who wrote that code?
> Also, note that we have no reason to believe things are better with
> other EAP servers. We just happen to know the behavior for FreeRADIUS.
Ah, the benefits of Open Source. You *know* how bad it is. :)
> There's another option we've thought of. We can squat on some attribute
> that's guaranteed to already be in the FReeRADIUS dictionary but that
> has no place in an EAP-TTLS tunnel. The architectural impurity of this
> solution should be obvious.
> However at least with FreeRADIUS it provides backwards compatibility.
A horrid solution would be to use attribute 26 (Vendor-Specific).
IIRC, it's forbidden in Diameter proper. However, RFC 5281 (TTLS) says:
RADIUS vendor-specific attributes use RADIUS
attribute 26 and include Vendor-ID, vendor-specific attribute
code, and length; see [RFC2865] for details.
So you could just packet a JANET VSA into it, and it would work. The
FreeRADIUS diameter decoding does *not* look for RADIUS VSAs. In this
case, it would just create an attribute of type 26, type "octets".
I could go poke the code to look for VSAs in the TTLS diameter
decoding, and create them. In the 3.0 "master" branch, this is actually
> Secondly, we could use input on the tradeoffs between architectural
> impurity and working with backward compatibility.
My guess is that using attribute 26 would work everywhere. But I'd
want to get information from the other RADIUS vendors to be sure.