[RADIATOR] AuthBy RADIUS and UseExtendedIds, stripped Proxy-State and strange behavior after 256 requests
Hi radiator team, still debugging the nasty bug between radsecproxy and Radiator in the eduroam connection between uni-ulm.de and radiusX.dfn.de, sigh! I have the problem with 'AuthBy RADSEC', where always extendid IDs are used. If someone is stripping/mangling the Proxy-State, the reply can't be mapped to the request and the warning is printed: > WARNING: Unknown reply received in AuthRADSEC for request from 127.0.0.1:2083 The missing request Id can't mapped, therefore the additional blank in the warning between 'request <> from'. There is never a PacketTrace so see the buggy answer. A patch will come soon to dump this, but wait and read to the end of my message. Now I looked for the Radiator behavior for AuthBy RADIUS with extended Ids and stripping Proxy-State. Wondering, it worked! ... But only for the first 256 Requests (8-Bits, 0xff mask in code) and after that I got the same/similar warning: > WARNING: Unknown reply received in AuthRADIUS for request 0 from > 127.0.0.1:1900 ... > WARNING: Unknown reply received in AuthRADIUS for request 1 from > 127.0.0.1:1900 You see, now the request Id is used from the 8-Bit Packet-Identifier, but could notbe mapped to the Proxy-State ExtendedId, since the 8 Bits wrapped: > Proxy-State = OSC-Extended-Id=256 ... > Proxy-State = OSC-Extended-Id=257 This is not optimal, since it works for a while after starting radiusd and after 256 requests you get spurious errors. Please fix this, if you UseExtendedIds in AuthBy RADIUS you should always WARN if the Proxy-State is stripped or mangled. And sure, we need better packet dumps in this case to see the sent/missing/mangled attributes in the reply packet. 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] AuthBy RADIUS and UseExtendedIds, stripped Proxy-State and strange behavior after 256 requests
On 07/14/2013 11:30 AM, Karl Gaissmaier wrote: > Please fix this, if you UseExtendedIds in AuthBy RADIUS you should > always WARN if the Proxy-State is stripped or mangled. Good point. It's a good idea make this separate from getting an unknown reply, which is currently logged for the both cases. > And sure, we need better packet dumps in this case to see the > sent/missing/mangled attributes in the reply packet. We are actually working on this now. There will be two changes at least: - enable PackeTrace for requests received from AuthBy RADIUS and RADSEC - see that packet dump is called so that any Log ... within AuthBy etc. module will be called instead of the dump going just to the main log file Thanks, Heikki -- Heikki Vatiainen Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] documentation typo at 5.51.1 DefaultResultACCEPT
On 07/13/2013 11:30 PM, Karl Gaissmaier wrote: > there is a missing whitespace in the documentation: Noted, thanks! > 5.51.1 > DefaultResult > Specifies how to reply to any request for which there is no more > specific result. The > default is to IGNORE. > # Accept everything not otherwise specified > DefaultResultACCEPT > > Must be: > > DefaultResult ACCEPT -- Heikki Vatiainen Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] SIGHUP restart and AuthByRADSEC opens an additional socket
On 07/10/2013 12:50 PM, Karl Gaissmaier wrote: > a SIGHUP to a running radiator (Version 4.11) opens an additional socket > for AuthByRADSEC: Fixed in the latest patches. Thanks for reporting this, Heikki -- Heikki Vatiainen Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] AuthBy RADIUS and UseExtendedIds, stripped Proxy-State and strange behavior after 256 requests
Hi Heikki, it's sunday, really I can wait for answers from your team after weekend ;-) Am 14.07.2013 10:54, schrieb Heikki Vatiainen: > On 07/14/2013 11:30 AM, Karl Gaissmaier wrote: > >> Please fix this, if you UseExtendedIds in AuthBy RADIUS you should >> always WARN if the Proxy-State is stripped or mangled. > > Good point. It's a good idea make this separate from getting an unknown > reply, which is currently logged for the both cases. > >> And sure, we need better packet dumps in this case to see the >> sent/missing/mangled attributes in the reply packet. > > We are actually working on this now. There will be two changes at least: > - enable PackeTrace for requests received from AuthBy RADIUS and RADSEC > - see that packet dump is called so that any Log ... within AuthBy etc. > module will be called instead of the dump going just to the main log file Thanks for Radiator and for this excellent service! 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] AuthBy RADIUS and UseExtendedIds, stripped Proxy-State and strange behavior after 256 requests
On 07/14/2013 12:17 PM, Karl Gaissmaier wrote: > it's sunday, really I can wait for answers from your > team after weekend ;-) Heh, I thought I'd save you some work since I understood you were gointo to work on the debug log and PacketTrace patch. The Proxy-State mangling is a bit problematic, though. This attribute is the only identifier that currently maps responses to requests with RadSec. If the other proxies mangle it, it would be essential to find and fix them. Thanks, Heikki -- Heikki Vatiainen Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] AuthBy RADIUS and UseExtendedIds, stripped Proxy-State and strange behavior after 256 requests
Hi Heikki, Am 14.07.2013 11:35, schrieb Heikki Vatiainen: > On 07/14/2013 12:17 PM, Karl Gaissmaier wrote: > >> it's sunday, really I can wait for answers from your >> team after weekend ;-) > > Heh, I thought I'd save you some work since I understood you were gointo > to work on the debug log and PacketTrace patch. yep, you saved my (sun)day > > The Proxy-State mangling is a bit problematic, though. This attribute is > the only identifier that currently maps responses to requests with > RadSec. If the other proxies mangle it, it would be essential to find > and fix them. And with RADSEC it's important to dump unknown replies, since the packets are encrypted on wire and without the private-key of the upstream proxy I can't decipher it. I need the dumps from Radiator in the case of 'Unknown replies' even if the attr-values can't be decoded. Best Regards and thanks in advance Charly ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] AuthBy RADIUS and UseExtendedIds, stripped Proxy-State and strange behavior after 256 requests
Am 14.07.2013 11:35, schrieb Heikki Vatiainen: > On 07/14/2013 12:17 PM, Karl Gaissmaier wrote: > >> it's sunday, really I can wait for answers from your >> team after weekend ;-) > > Heh, I thought I'd save you some work since I understood you were gointo > to work on the debug log and PacketTrace patch. > > The Proxy-State mangling is a bit problematic, though. This attribute is > the only identifier that currently maps responses to requests with > RadSec. If the other proxies mangle it, it would be essential to find > and fix them. sure, but it's a problem to show the mangled/stripped attr if I can't decode it. It's just a suspicion, but I've to prove it to force my upstream proxy (german research network) to look into the config and rise the debug level, sorry. Maybe for debug traces in case of unknown replies, you could use heuristic mappings, since the last 8-Bits of the packet Identifier should match a pending extended-id from a request. And you know the host and port from the sender. I don't know your datastructure in detail where you queue pending requests, but maybe you can narrow this heuristically for debugging. Best Regards Charly ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
[RADIATOR] Radiator and radsecproxy, status-server and failover algo, one step forward
Hi radiator team,
now I proved my suspicion, that the upstream radsecproxy is stripping
the radiator proxy-state, at least in status-server requests.
I used monkey patching in AuthBy RADSEC, just quick and dirty
to get the result (you know, it's sunday):
> Sun Jul 14 16:56:43 2013 009313: DEBUG: Packet dump:
> *** Sending request to RadSec radius2.dfn.de:2083
> Code: Status-Server
> Identifier: 5
> Authentic: 4<160><179><224><193><233><154><132>+<190>2O<227>f<205>&
> Attributes:
> Message-Authenticator =
> <0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0>
> Proxy-State = OSC-Extended-Id=5
>
> Sun Jul 14 16:56:43 2013 014566: DEBUG: ### UULM DUMP##
> *** Unmatched Ext-Id in Proxy-State for reply in AuthRADSEC from
> radius2.dfn.de:2083
> Code: Access-Accept
> Identifier: 5
> Authentic: <247><230>&<26><254><245><<134>C<128><219>>p<216><223>I
> Attributes:
>
> Sun Jul 14 16:56:51 2013 115473: DEBUG: Packet dump:
> *** Sending request to RadSec radius1.dfn.de:2083
> Code: Status-Server
> Identifier: 6
> Authentic: 0<217><255><198><172>F<23><213><140><155>2<162>f1{<189>
> Attributes:
> Message-Authenticator =
> <0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0>
> Proxy-State = OSC-Extended-Id=6
>
> Sun Jul 14 16:56:51 2013 138708: DEBUG: ### UULM DUMP##
> *** Unmatched Ext-Id in Proxy-State for reply in AuthRADSEC from
> radius1.dfn.de:2083
> Code: Access-Accept
> Identifier: 6
> Authentic: <233>;<136>k<187><9>s#<200>v<232><208><137><150>Wv
> Attributes:
>
> Sun Jul 14 16:56:53 2013 210994: INFO: AuthRADSEC: No reply from
> radius2.dfn.de:2083 for Status-Server request ()
Now it's clear, that failover between radsecproxy (used at dfn.de) and
Radiator with status-server keepalives could not work. It took me a long
time and I had to dig into the code, since I could not establish
debugging for returned packets in AuthBy RADSEC in production systems
and TLS encryption is unbreakable for me, I'm not the NSA and not
working for PRISM, sigh.
Question: Do you have a working test setup between radsecproxy and
Radiator for 'UseStatusServerForFailureDetect'?
Can you send me your radsecproxy config and tell me the radsecproxy
version number. I'll will send it to DFN to recheck their config.
Worse, it seems that buggy clients with unroutable @Realms trigger
answers with proxy-state stripped. So I get NoreplyTimeouts for
any buggy client request and my upstream connections break away.
Seems that all german @Realms in eduroam using Radiator have the same
problem, because all of them use the same upstream radsecproxy at DFN,
sigh.
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
Am 14.07.2013 17:28, schrieb Karl Gaissmaier: ... > Worse, it seems that buggy clients with unroutable @Realms trigger > answers with proxy-state stripped. So I get NoreplyTimeouts for > any buggy client request and my upstream connections break away. > > Seems that all german @Realms in eduroam using Radiator have the same > problem, because all of them use the same upstream radsecproxy at DFN, > sigh. and here is the prove: > Sun Jul 14 17:49:02 2013 177403: DEBUG: Packet dump: > *** Sending request to RadSec radius1.dfn.de:2083 > Code: Access-Request > Identifier: 42 > Authentic: U<182><136><130>!<141><232><175><230>y)<234>4<239>9y > Attributes: > User-Name = "uni.ulm.test@akad" > Service-Type = Framed-User > NAS-IP-Address = 203.63.154.1 > NAS-Identifier = "203.63.154.1" > NAS-Port = 1234 > Called-Station-Id = "123456789" > Calling-Station-Id = "987654321" > NAS-Port-Type = Async > EAP-Message = <2><0><0><22><1>uni.ulm.test@akad > Message-Authenticator = <231>+b<159>G<135>2<147><185>$N<192>tw<205>] > Proxy-State = OSC-Extended-Id=42 > > Sun Jul 14 17:49:02 2013 199902: DEBUG: ### UULM DUMP## > *** Unmatched Ext-Id in Proxy-State for reply in AuthRADSEC from > radius1.dfn.de:2083 > Code: Access-Reject > Identifier: 42 > Authentic: <246><223><219>M<179>S<234>VE<26><253><236><25><251>r<17> > Attributes: > Reply-Message = "Misconfigured client! Delete spaces at the end of > the realm!" > again the Proxy-State is stripped, radiator can't match the reply to the request, we get a NoreplyTimeout and the connection goes down afetr some retries. Please test the radiator against radsecproxy in your lab. Best Regards Charly ___ 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 As an end site you really shouldn't be sending invalid realms to your national proxy... but there does seem to be something odd gong on here. . their system should be just sending back a straight access reject. If radsecproxy doesn't like extended proxy id (or the config doesn't allow it ) then that would be an issue 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 Alex, hi radiator team, Am 14.07.2013 19:48, schrieb Alan Buxey: > Hi > > As an end site you really shouldn't be sending invalid realms to your > national proxy... but there does seem to be something odd gong on here. I sent it to test this situation. As an eduroam ServiceProvider I don't know if a client is misconfigured. OK, nornmally I reject top-level realms, like the used '@akad' in my test, but some visitors have for example: 1272017248108...@wlan.mnc001.mcc262.3gppnetwork.org and this has the same result. As an endpoint SP, I can't filter for all wrong @realms, I don't know them all ,-) > . their system should be just sending back a straight access reject. If > radsecproxy doesn't like extended proxy id (or the config doesn't allow > it ) then that would be an issue Yes, this is the issue. I don't see the config of the federation-level-radius-proxy and the admins are not very helpful, they state, thats a problem with Radiator using extended Ids in the proxy-styte, e.g. they respomg with RFC 5997, saying that Status-Server MUST NOT be proxied and therefore the Proxy-State attribut isn't allowed. > > 4.4. Proxy Server Handling of Status-Server > > >Many RADIUS servers can act as proxy servers, and can forward >requests to another RADIUS server. Such servers MUST NOT proxy >Status-Server packets. The purpose of Status-Server as specified >here is to permit the client to query the responsiveness of a server >with which it has a direct relationship. Proxying Status-Server >queries would negate any usefulness that may be gained by >implementing support for them. > >Proxy servers MAY be configured to respond to Status-Server queries >from clients, and they MAY act as clients sending Status-Server >queries to other servers. However, those activities MUST be >independent of one another. What shall I do, Radiators AuthBy RADSEC Identifiers are always based on proxy-State. What does the radiator tesm says about RFC 5997. Best Regards Charly ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
[RADIATOR] AuthRADSEC and radsecproxy are incompatible!
Hi radiator team, I looked over the radsecproxy sources and sorry to say it: *Currently the radsecproxy and AuthRADSEC are incompatible!* Whenever radsecproxy *generates* a reply message (Access-Reject or Access-Accept on Satus-Server) it never copies the Proxy-State Attribute from the request packet to the reply packet. The only shortcoming solution as far as I see is, we need a 'UseExtendedIds' in Radiator not only for AuthRADIUS but also for AuthRADSEC with a warning, never to use it when proxying to a radsecproxy. Sorry for the bad news. 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. 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, > 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 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!
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
