Re: [RADIATOR] AuthRADSEC and radsecproxy are incompatible!
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 ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Radiator and radsecproxy, status-server and failover algo, one step forward
Hi, 1272017248108...@wlan.mnc001.mcc262.3gppnetwork.org 3gppnetwork realms are invalid. ..just like hotmail, gmail, yahoo etc - until a notice comes from eduroam stating that these realms now have agreed relationship, they are public realms and not within the private scheme of eduroam. RFC 5997, saying that Status-Server MUST NOT be proxied and therefore the Proxy-State attribut isn't allowed. status-server musnt be proxiedits only for the first-hop check of a remote proxy and not the end target - but that surely isnt the issue? a Status-Server message is easy to deal with - you just send something back to show you are alive - RADIATOR has been sending a basic statts page back for status-server queries to it for years. alan ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Radiator and radsecproxy, status-server and failover algo, one step forward
Hi, status-server musnt be proxiedits only for the first-hop check of a remote proxy and not the end target - but that surely isnt the issue? a Status-Server message is easy to deal with - you just send something back to show you are alive - RADIATOR has been sending a basic statts page back for status-server queries to it for years. This is about Status-Server requests *originating* from Radiator to check another server's alive state. Radiator sends a Proxy-State in the request (which is not supposed to be done), and then complains that it doesn't get it back (which is only supposed to happen with Access-Requests, not Status-Server). 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 signature.asc Description: OpenPGP digital signature ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] AuthRADSEC and radsecproxy are incompatible!
Hi, 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. Yes, the lack of returning Proxy-State when radsecproxy crafts its own Rejects is definitely a problem of radsecproxy; it violates RFC2865, section 5.33: This Attribute is available to be sent by a proxy server to another server when forwarding an Access-Request and MUST be returned unmodified in the Access-Accept, Access-Reject or Access-Challenge. I've sent a notice to the radsecproxy mailing list, notifying them of the problem. I'm hoping to see a next release with a proper fix. 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 signature.asc Description: OpenPGP digital signature ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Radiator and radsecproxy, status-server and failover algo, one step forward
Hi, Am 15.07.2013 09:15, schrieb a.l.m.bu...@lboro.ac.uk: Hi, 1272017248108...@wlan.mnc001.mcc262.3gppnetwork.org 3gppnetwork realms are invalid. ..just like hotmail, gmail, yahoo etc - until a notice comes from eduroam stating that these realms now have agreed relationship, they are public realms and not within the private scheme of eduroam. thats's not the point, I had (again) a wrong example choosen. Some users have just typos in their realms, an endpoint eduroam SP can not handle all typos, we proxy it upstream. If the upstream Rejects it, it should not strip the Proxy-State Attribut. RFC 5997, saying that Status-Server MUST NOT be proxied and therefore the Proxy-State attribut isn't allowed. status-server musnt be proxiedits only for the first-hop check of a remote proxy and not the end target - but that surely isnt the issue? a Status-Server message is easy to deal with - you just send something back to show you are alive - RADIATOR has been sending a basic statts page back for status-server queries to it for years. Radiator doesn't proxy the Status-Server requests, he generates it and has a wrong scheme to deal with the limited 8-Bits of Request Identifiers. Again: 1.)Radiator has to fix AuthRADSEC. The user has to choose to use extended-Ids in the Proxy-State Attribut if the upstream proxy will handle this. By default it should use 8 Bit Identifiers. 2.)radsecproxy has to fix the self generated Access-Rejects. If a Proxy-State Attribut was present in the Access-Request, the generated Access-Reject must copy this attribut and send it back. Best Regards Charly -- Karl Gaissmaier Universität Ulm / Germany ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] AuthRADSEC and radsecproxy are incompatible!
Hello, Am 15.07.2013 09:27, schrieb Stefan Winter: Hi, 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. Yes, the lack of returning Proxy-State when radsecproxy crafts its own Rejects is definitely a problem of radsecproxy; it violates RFC2865, section 5.33: This Attribute is available to be sent by a proxy server to another server when forwarding an Access-Request and MUST be returned unmodified in the Access-Accept, Access-Reject or Access-Challenge. I've sent a notice to the radsecproxy mailing list, notifying them of the problem. I'm hoping to see a next release with a proper fix. Thanks, you got the point and saved my day! Best Regards Charly -- Karl Gaissmaier Universität Ulm / Germany ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Radiator and radsecproxy, status-server and failover algo, one step forward
Hi, 1.)Radiator has to fix AuthRADSEC. The user has to choose to use extended-Ids in the Proxy-State Attribut if the upstream proxy will handle this. By default it should use 8 Bit Identifiers. 2.)radsecproxy has to fix the self generated Access-Rejects. If a Proxy-State Attribut was present in the Access-Request, the generated Access-Reject must copy this attribut and send it back. I agree with both points. both servers are doing something wrong..and the interop causes issues. alan ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] AuthRADSEC and radsecproxy are incompatible!
Hi, anyway it's a bit proprietary that Radiator ignores the correct identifier in an Access-Reject packet. The Identifier is also part of RFC2865: Identifier The Identifier field is one octet, and aids in matching requests and replies. The RADIUS server can detect a duplicate request if it has the same client source IP address and source UDP port and Identifier within a short span of time. Freeradius has never complained about these Access-Reject packets generated by radsecproxy. Because these packages can be matched by the identifier. Also there is no doubt that radsexcproxy might violate RFC 2865 and Radiator violates RFC5997, it is always not very useful ignoring part of a standard header and insist on a Ext-Id to match an Access-Reject. Best wishes Ralf On Jul 15, 2013, at 9:35 AM, Karl Gaissmaier karl.gaissma...@uni-ulm.de wrote: Hello, Am 15.07.2013 09:27, schrieb Stefan Winter: Hi, 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. Yes, the lack of returning Proxy-State when radsecproxy crafts its own Rejects is definitely a problem of radsecproxy; it violates RFC2865, section 5.33: This Attribute is available to be sent by a proxy server to another server when forwarding an Access-Request and MUST be returned unmodified in the Access-Accept, Access-Reject or Access-Challenge. I've sent a notice to the radsecproxy mailing list, notifying them of the problem. I'm hoping to see a next release with a proper fix. Thanks, you got the point and saved my day! Best Regards Charly -- Karl Gaissmaier Universität Ulm / Germany ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator -- Verein zur Förderung eines Deutschen Forschungsnetzes e.V. Alexanderplatz 1, D - 10178 Berlin Tel.: 030 88 42 99 23 Fax: 030 88 42 99 70 http://www.dfn.de smime.p7s Description: S/MIME cryptographic signature ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
[RADIATOR] documentation typo at 13.1.33 DefineFormattedGlobalVarsystem
Hi radiator team, there is a missing whitespace in the documentation: 13.1.33 Variable names prefixed with GlobalVar: The attribute to be compared is taken from a GlobalVar. GlobalVar variables can be set from the command line, or with the DefineFormattedGlobalVar parameter. This can be useful for activating different sets of users in multiple instances of Radiator. # In the config file: DefineFormattedGlobalVarsystem mysystem # in a users file: username Password=fred,GlobalVar:system=mysystem Must be: DefineFormattedGlobalVar system mysystem Best Regards Charly ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
