[RADIATOR] AuthRADSEC and radsecproxy are incompatible!

[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.

If Radiator generates a Proxy-State (even though it is not acting as a
proxy - so why would it do that?), then it's at fault itself. It should
not have any expectations of getting it back unharmed.

Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
Url : http://www.open.com.au/pipermail/radiator/attachments/20130715/f8b255ba/attachment.bin