[RADIATOR] AuthRADSEC and radsecproxy are incompatible!

[Karl Gaissmaier]

Hello,

Am 15.07.2013 07:47, schrieb Stefan Winter:
> Hello,
>
>> Maybe someone can trigger the authors of radsecproxy too, to start
>> implementing Proxy-State RFC 2865 conform when *generating* responses.
>> Seems it makes everthing right on proxying but not on generating
>> packets.
>
> Status-Server is defined in RFC5997. It uses a distinct command-code -
> it's not an Access-Request, it's Status-Server. So all the "rules" of an
> Access-Request and corresponding responses are not relevant.
>
> In particular, the attribute Proxy-State is not expected to be in there.
> See section 5 of that RFC.
>
> Adding to that, there is also no reason to use Proxy-State at all
> because Radiator does not act as proxy - it's acting as a simple RADIUS
> Client, sending an initial request to some other server. Proxy-State (in
> Access-Requests) only comes into play when a server *receives* a packet
> from downstream, then sees that it needs to be sent elsewhere still, and
> then *forwards* it. Only then does it add Proxy-State. None of this is
> true with Status-Server; and proxying Status-Server packets is
> prohibited in section 4.4 of that same RFC.

this may be true for Status-Server but not for the Access-Rejects 
generated by the radsecproxy. This has to be corrected by radsecproxy.

And yes, Radiator AuthRADSEC has to fix the problem with Status-Server.
Both together are incompatible but often used together in eduroam.

Greetings
    Charly

-- 
Karl Gaissmaier
Universität Ulm / Germany