[RADIATOR] Radiator mailing list migration

[Heikki Vatiainen]

Hello list members,

Radiator mailing lists and list archives are migrating to a new server 
soon. This requires no action from you. A message will be posted through 
the migrated list when the operation has finished. This should happen 
later today.

The current mailing list address, radiator@open.com.au, will become an 
alias for the Radiator list address and it will continue to work until 
further notice. The new list address will be radia...@lists.open.com.au 
which is preferred after the migration.

The migrated lists will be running on
https://lists.open.com.au

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

[RADIATOR] Radiator Version 4.17 released - enhancements, new features, security and other fixes

[Heikki Vatiainen]

We are pleased to announce the release of Radiator version 4.17

This version contains enhancements, new features, security and other 
fixes described below.

As usual, the new version is available to current licensees
and evaluators from:
https://www.open.com.au/radiator/downloads.html

Licensees with expired access contracts can renew at:
https://www.open.com.au/renewal.html

An extract from the history file
https://www.open.com.au/radiator/history.html is below:

-

Revision 4.17 (2016-09-21) enhancements, new features, security and 
other fixes

  Selected compatibility notes, enhancements and fixes

radiusd now exits during startup if it can not load the objects
required by the configuration file.

Hooks and custom code that calls get_plaintext_password or
translate_password should be checked for compatibility

AuthBy RADSEC now supports Radiator's Gossip framework for
reachability information

Any hooks or custom code that needs to save data across resumed
EAP-TLS, EAP-TTLS or PEAP authentication sessions must now use
resume context. See EAP.pm for the details.

RADIUS dictionary name space was changed for IANA registered
attributes. Any hooks or custom code that accesses RADIUS
dictionary, or does RADIUS - Diameter conversion may need updates.

JSON time stamp formats were corrected and unified in LogFormat.pm

AuthBy DUO now does pre-authentication by default

AddressAllocator SQL now supports IPv6 prefix allocation

Session resumption for TLS based EAP methods was enhanced

Many new features and options for SessionDatabase modules

AuthBy RADIUS supports configuration parameter Asynchronous for
easier AuthByPolicy handling

New MessageLog clauses for logging RADIUS and other messages

StatsLog updates including cumulative and derivate statistics

HTTP digest authentication must now be enabled per AuthBy basis

Security fixes for AuthBy LDAP2 when used with EAP. OSC
recommends all AuthBy LDAP2 users to review OSC security
advisory OSC-SEC-2016-01
https://www.open.com.au/OSC-SEC-2016-01.html


  Features not in this release yet, known caveats and other notes

OCSP support

Selection of proxy algorithms for AuthBy RADSEC

No testing with OpenSSL 1.1.0. Testing with OpenSSL 1.0.2h,
Net::SSLeay 1.78, IOS 10, Android 7 and Windows 10

PEAP session resumption sometimes fails on Windows. Further
investigation is ongoing

Major documentation update. Radiator reference manual is
available in HTML format again


  Detailed changes

Updated debug log messages for Stream classes. The stream client
and server now log the destination name and its currently
resolved address more clearly in the debug log messages. This
affects log messages for RadSec, Diameter, ServerHTTP and other
Stream based modules.

AuthBy RADSEC now logs packet dumps for the Status-Server
replies it receives from the next hop proxy. The Port
configuration variable is now formatted when RadSec Host is
activated. This allows logging the actual port number instead of
the unformatted configuration value.

Added Gossip support for AuthBy RADSEC. The RadSec Hosts can now
distribute next hop proxy reachability information with Gossip.
The configured Host name, not the current IP address, is used as
the key when determining if the current report should be
processed. The behaviour is currently slightly different from
AuthBy RADIUS. Updated radsec-client.cfg in goodies. Suggested
by Jan Tomasek.

Updated AuthBy RADSEC log messages to be more clear about
destination name, IP address and port.

While loading dictionaries, Radiator now logs a warning when the
vendor has not been defined for a vendor specific attribute.

Correct configuration file names are now logged when there are
errors parsing the included configuration files during radiusd
startup. Previously the file name might have been the main
configuration file name. Reported by Kilian Krause.

Clause ends are now checked for matching starts while the
configuration file is read. Possible mismatches and incorrectly
ended clauses are logged with a warning, but no other action is
currently taken.

Gossip messages sent by one AuthBy RADIUS module will now be
accepted by all the other AuthBy RADIUS modules within the same
radiusd instance. Previously the messages were always ignored
when they originated from the same instance. This behaviour is
now similar to what AuthBy RADSEC does.
AuthRADIUS and AuthRADSEC now include the type of the failed
request in the Gossip messages. A module using
UseStatusServerForFailureDetect will now act only on failed
Status-Server requests. With report and help from Paul Dekkers.

AuthBy LDAP2 now logs the search filter with the query results

Added VENDOR 3GPP 10415 VSA 3GPP-User-Location-Info-Time from
document TS 29.061 version 12.10.0 to dictionary.

AuthBy DYNADDRESS now uses MapAttribute yiaddr when processing
Accounting-Requests. Previously the address was always fetched
from Framed-IP-Address.

Re: [RADIATOR] Radiator and Load Balancer

[Robert Blayzor]

This may be the case now, but pretty sure we went down this road YEARS ago and 
even with BindAddress, packets were still being sourced from the main IP 
address. In the mailing list archives this argument may exist. I vaguely 
remember being told by Hugh that it was not possible in Perl at the time to 
choose the source address to respond from.

Again, not arguing that now; just saying what we ran into in the past.

--
Robert
inoc.net!rblayzor
XMPP: rblayzor.AT.inoc.net
PGP Key: 78BEDCE1 @ pgp.mit.edu




> On Jul 29, 2016, at 6:17 AM, Heikki Vatiainen  wrote:
> 
> When BindAddress is configured, a socket is created and bound for each 
> address defined by BindAddress. In this case the source address of a 
> reply is the specific non-wildcard address the socket was bound to.
> 
> In short: BindAddress can be useful on multi homed hosts. However, if IP 
> addresses are added and removed dynamically, this can cause problems 
> because the addresses are now part of the Radiator configuration too.

___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Radiator and Load Balancer

[Robert Blayzor]

In my experience this is not the case. It will LISTEN on those addresses for 
sure. But it’s return packets are always sourced from the primary IP address of 
the outgoing interface. DSR will work, but the clients will receive a response 
from an IP address that is not of the configure RADIUS server. This may (but 
should not) work for various clients. This may of changed, in recent years. 
YMMV.

--
Robert
inoc.net!rblayzor
XMPP: rblayzor.AT.inoc.net
PGP Key: 78BEDCE1 @ pgp.mit.edu




> On Jul 29, 2016, at 5:19 AM, Hartmaier Alexander 
>  wrote:
> 
> When you configure the VIP as loopback on every radiator server and bind
> radiator to this ip the reply packets should be sent from it.

___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Radiator and Load Balancer

[Heikki Vatiainen]

On 27.07.2016 21:32, Robert Blayzor wrote:

> The problem with this I think is that Radiator responds with a source
> address of where the packet leaves. (at least that’s been my
> experience).

Yes, this happens by default when BindAddress is not configured.

The default is to bind the RADIUS listen ports with the wildcard address 
0.0.0.0. When the replies are sent, they are from the socket that 
received the request. When the socket has been bound with the wildcard 
address, kernel will pick a source address for the reply.

When BindAddress is configured, a socket is created and bound for each 
address defined by BindAddress. In this case the source address of a 
reply is the specific non-wildcard address the socket was bound to.

In short: BindAddress can be useful on multi homed hosts. However, if IP 
addresses are added and removed dynamically, this can cause problems 
because the addresses are now part of the Radiator configuration too.

> Most clients will probably ignore the response as it’s
> coming from a different address.

Yes, they will probably log the replies as unknown messages or something 
similar.

> With Radiator being Perl, I don’t think you can force Radiator to
> answer from a specific source address on the server.

With wildcard bind address things can get complicated. There are socket 
functions that allow querying the address the request was sent to, but 
these are OS specific and may require additional modules for accessing, 
for example sendmsg() and other functions.

The easiest way to handle problems with reply addresses on multi homed 
hosts is to use BindAddress, if possible.

Thanks,
Heikki

-- 
Heikki Vatiainen
Open System Consultants

___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Radiator and Load Balancer

[Hartmaier Alexander]

As a general network design we try to stay away from multihomed servers
as much as possible as the server admins lack networking/routing
know-how which leads to failing connectivity all the time.

Direct server return has its own share of problems which is why we don't
use it anymore but this is protocol dependent and might work for radius
which is udp.

When you configure the VIP as loopback on every radiator server and bind
radiator to this ip the reply packets should be sent from it.

Best regards, Alex


On 2016-07-28 00:48, xcorpse wrote:
> On 27/07/16 19:32, Robert Blayzor wrote:
>> DSR load balancing assumes the real servers know about the load balanced VIP 
>> and is generally configured on a loopback.
>>
>> The problem with this I think is that Radiator responds with a source 
>> address of where the packet leaves. (at least that’s been my experience). 
>> Most clients will probably ignore the response as it’s coming from a 
>> different address.
>>
>> With Radiator being Perl, I don’t think you can force Radiator to answer 
>> from a specific source address on the server.
> i've used radiator with dsr for some fairly large radius installs, works
> fine as long as you set it up correctly. the loopback alias or firewall
> packet mangling rules will make sure that the return packets are not
> ignored ...
>



*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
Notice: This e-mail contains information that is confidential and may be 
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Radiator and Load Balancer

[xcorpse]

On 27/07/16 19:32, Robert Blayzor wrote:
> DSR load balancing assumes the real servers know about the load balanced VIP 
> and is generally configured on a loopback.
>
> The problem with this I think is that Radiator responds with a source address 
> of where the packet leaves. (at least that’s been my experience). Most 
> clients will probably ignore the response as it’s coming from a different 
> address.
>
> With Radiator being Perl, I don’t think you can force Radiator to answer from 
> a specific source address on the server.

i've used radiator with dsr for some fairly large radius installs, works 
fine as long as you set it up correctly. the loopback alias or firewall 
packet mangling rules will make sure that the return packets are not 
ignored ...

-- 
no name ... no slogan
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Radiator and Load Balancer

[Robert Blayzor]

DSR load balancing assumes the real servers know about the load balanced VIP 
and is generally configured on a loopback.

The problem with this I think is that Radiator responds with a source address 
of where the packet leaves. (at least that’s been my experience). Most clients 
will probably ignore the response as it’s coming from a different address.

With Radiator being Perl, I don’t think you can force Radiator to answer from a 
specific source address on the server.


NAT will work via the F5, you just have to make sure that the response traffic 
goes back out to the load balancer it came in on.

--
Robert
inoc.net!rblayzor
XMPP: rblayzor.AT.inoc.net
PGP Key: 78BEDCE1 @ pgp.mit.edu




> On Jul 27, 2016, at 1:38 PM, shaun gibson  wrote:
> 
> i've used direct server return for radius and it seemed to work well :
> 
> http://blog.haproxy.com/2011/07/29/layer-4-load-balancing-direct-server-return-mode/
> https://devcentral.f5.com/articles/the-disadvantages-of-dsr-direct-server-return
> 
> using the f5 for inbound and outbound traffic nat will also work, just
> depends what your requirements are ...

___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Radiator and Load Balancer

[Barry Ard]

Thanks Shaun. This is good reading.

Barry

On Wed, Jul 27, 2016 at 11:38 AM, shaun gibson  wrote:

> On 27/07/2016 18:14, Barry Ard wrote:
>
> > We are running into some challenges configuring a new environment for
> > Eduroam.
> >
> > Recently we have moved away from 2 servers running multiple radiator
> > processes to a multiple VMs behind an F5 load balancer. This has been
> > working well for our wireless infrastructure but has been posing
> > challenges as we are trying to include our Eduroam config.
> >
> > The F5 is NATing to the VMs. The VMs have 2 interfaces: eth0 is a
> > private address facing the F5, eth1 is a public address and is the
> > default gateway.
> >
> > I have created a test enviroment with an external radius server to
> > simulate Eduroam.
> > Initially proxied requests would transit the VMs default gateway which
> > I think is undesriable so I created a static route for the external
> > radius server to force it out the load balancer facing interface. Now
> > proxied requests have a private address which of course will not work.
> >
> > I think the desirable scenario would be for proxied requests to exit
> > through the F5 and be NAT’d to source from the F5 external address. My
> > colleague who admins the load balancer is hesitant to NAT externally
> > using an address that is currently listening on a service. He thinks
> > this is getting too complicated.
> >
> > I am sure others are using a load balancer in this scenario so please
> > tell me what you are doing.
> >
> i've used direct server return for radius and it seemed to work well :
>
>
> http://blog.haproxy.com/2011/07/29/layer-4-load-balancing-direct-server-return-mode/
>
> https://devcentral.f5.com/articles/the-disadvantages-of-dsr-direct-server-return
>
> using the f5 for inbound and outbound traffic nat will also work, just
> depends what your requirements are ...
>
>
> ___
> radiator mailing list
> radiator@open.com.au
> http://www.open.com.au/mailman/listinfo/radiator
>



-- 

Barry Ard   barry@ualberta.ca
IST
University of Alberta
Edmonton, Alberta   Canada
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Radiator and Load Balancer

[shaun gibson]

On 27/07/2016 18:14, Barry Ard wrote:

> We are running into some challenges configuring a new environment for
> Eduroam. 
>
> Recently we have moved away from 2 servers running multiple radiator
> processes to a multiple VMs behind an F5 load balancer. This has been
> working well for our wireless infrastructure but has been posing
> challenges as we are trying to include our Eduroam config. 
>
> The F5 is NATing to the VMs. The VMs have 2 interfaces: eth0 is a
> private address facing the F5, eth1 is a public address and is the
> default gateway.
>
> I have created a test enviroment with an external radius server to
> simulate Eduroam.
> Initially proxied requests would transit the VMs default gateway which
> I think is undesriable so I created a static route for the external
> radius server to force it out the load balancer facing interface. Now
> proxied requests have a private address which of course will not work.
>
> I think the desirable scenario would be for proxied requests to exit
> through the F5 and be NAT’d to source from the F5 external address. My
> colleague who admins the load balancer is hesitant to NAT externally
> using an address that is currently listening on a service. He thinks
> this is getting too complicated.
>
> I am sure others are using a load balancer in this scenario so please
> tell me what you are doing.
>
i've used direct server return for radius and it seemed to work well :

http://blog.haproxy.com/2011/07/29/layer-4-load-balancing-direct-server-return-mode/
https://devcentral.f5.com/articles/the-disadvantages-of-dsr-direct-server-return

using the f5 for inbound and outbound traffic nat will also work, just
depends what your requirements are ...



signature.asc
Description: OpenPGP digital signature
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

[RADIATOR] Radiator and Load Balancer

[Barry Ard]

We are running into some challenges configuring a new environment for
Eduroam.

Recently we have moved away from 2 servers running multiple radiator
processes to a multiple VMs behind an F5 load balancer. This has been
working well for our wireless infrastructure but has been posing challenges
as we are trying to include our Eduroam config.

The F5 is NATing to the VMs. The VMs have 2 interfaces: eth0 is a private
address facing the F5, eth1 is a public address and is the default gateway.

I have created a test enviroment with an external radius server to simulate
Eduroam.
Initially proxied requests would transit the VMs default gateway which I
think is undesriable so I created a static route for the external radius
server to force it out the load balancer facing interface. Now proxied
requests have a private address which of course will not work.

I think the desirable scenario would be for proxied requests to exit
through the F5 and be NAT’d to source from the F5 external address. My
colleague who admins the load balancer is hesitant to NAT externally using
an address that is currently listening on a service. He thinks this is
getting too complicated.

I am sure others are using a load balancer in this scenario so please tell
me what you are doing.

Thanks,
Barry


-- 

Barry Ard   barry@ualberta.ca
IST
University of Alberta
Edmonton, Alberta   Canada
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] radiator never gets to the 2nd authentication phase in PEAP - MSCHAPv2

[Hugo Veiga]

Hi,


Heikki I bow to you. :)


So the problem was this:

(Topology)

Radiator Machine/ IP: 10.253.1.12/24
--Router--wireless switch/IP:10.240.1.1/24

- The radiator machine receives requests from wireless switch.

- Wireless switch never receives the answer.

:: So Radiator machine is a virtual machine and installed by a
colleague of mine (system admin) that inserted the mask 255.0.0.0 in
the network mask. Radiator machine with the supplied mask will try to
contact 10.240.1.1 through arp discovery and will never find it
because it's on a different broadcast domain. The solution was
obvious, insert the correct netmask and it started to work perfectly.


Problem solved.

Many thanks Heikki,

Hugo Veiga




>* Code:   Access-Request
*>* Identifier: 180
*>* Authentic:  <139><3>(<143><10><139>N<158><F<172><194><163><168><135>O
*
Radiator notices this and retransmits its previous reply

>* Tue Jan 26 15:54:57 2016: INFO: Duplicate request id 180 received from
*>* 10.240.1.1(20004): retransmit reply
*>* Tue Jan 26 15:54:57 2016: DEBUG: Packet dump:
*>* *** Sending to 10.240.1.1 port 20004 
*
There are multiple retransmits back and forth and the authentication
does not proceed.

I would check the Wi-Fi controller logs and make sure it is receiving

the responses from Radiator.
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] radiator never gets to the 2nd authentication phase in PEAP - MSCHAPv2

[Hugh Irvine]

Indeed - the old adage is very true:

“Just because a packet can get somewhere does not mean that the reply 
can get back….”

regards

Hugh


> On 1 Feb 2016, at 20:39, Hugo Veiga <hve...@ubi.pt> wrote:
> 
> Hi,
> 
> Heikki I bow to you. :)
> 
> So the problem was this:
> (Topology)
> Radiator Machine/ IP: 10.253.1.12/24 
> --Router--wireless switch/IP:10.240.1.1/24 
> - The radiator machine receives requests from wireless switch.
> - Wireless switch never receives the answer.
> :: So Radiator machine is a virtual machine and installed by a colleague of 
> mine (system admin) that inserted the mask 255.0.0.0 in the network mask. 
> Radiator machine with the supplied mask will try to contact 10.240.1.1 
> through arp discovery and will never find it because it's on a different 
> broadcast domain. The solution was obvious, insert the correct netmask and it 
> started to work perfectly.
> 
> Problem solved.
> Many thanks Heikki,
> Hugo Veiga
> 
> 
> 
> >
>  Code:   Access-Request
> 
> >
>  Identifier: 180
> 
> >
>  Authentic:  <139><3>(<143><10><139>N<158><F<172><194><163><168><135>O
> 
> 
> Radiator notices this and retransmits its previous reply
> 
> >
>  Tue Jan 26 15:54:57 2016: INFO: Duplicate request id 180 received from
> 
> >
>  10.240.1.1(20004): retransmit reply
> 
> >
>  Tue Jan 26 15:54:57 2016: DEBUG: Packet dump:
> 
> >
>  *** Sending to 10.240.1.1 port 20004 
> 
> 
> There are multiple retransmits back and forth and the authentication
> does not proceed.
> 
> I would check the Wi-Fi controller logs and make sure it is receiving
> 
> the responses from Radiator.
> ___
> radiator mailing list
> radiator@open.com.au
> http://www.open.com.au/mailman/listinfo/radiator


--

Hugh Irvine
h...@open.com.au

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, SIM, etc. 
Full source on Unix, Linux, Windows, MacOSX, Solaris, VMS, NetWare etc.

___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] radiator never gets to the 2nd authentication phase in PEAP - MSCHAPv2

[Heikki Vatiainen]

On 01/26/2016 06:05 PM, Hugo Veiga wrote:

> Also tried another certificate but it's doing the same, it gets stuck
> and never reaches the inner handler.

I don't think this is a certificate or handler problem now. Previously
AuthBy INTERNAL was dropping the request, but now when you changed the
configuration, the responses from Radiator are sent back to the Wi-Fi
controller.

This might be a problem with network connectivity, Wi-Fi controller
configuration or something that prevents the Wi-Fi controller from
receiving or processing the responses Radiator sends.

Here's the EAP identity response that starts the authentication. This
comes from the Wi-Fi client side:

> Code:   Access-Request
> Identifier: 180
> Authentic:  <139><3>(<143><10><139>N<158><194><163><168><135>O

This is the response from Radiator that tells to start PEAP.

> Code:   Access-Challenge
> Identifier: 180

This is where things do not go as expected. The first message is resent
to Radiator:

> Code:   Access-Request
> Identifier: 180
> Authentic:  <139><3>(<143><10><139>N<158><194><163><168><135>O

Radiator notices this and retransmits its previous reply

> Tue Jan 26 15:54:57 2016: INFO: Duplicate request id 180 received from
> 10.240.1.1(20004): retransmit reply
> Tue Jan 26 15:54:57 2016: DEBUG: Packet dump:
> *** Sending to 10.240.1.1 port 20004 

There are multiple retransmits back and forth and the authentication
does not proceed.

I would check the Wi-Fi controller logs and make sure it is receiving
the responses from Radiator.

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] radiator never gets to the 2nd authentication phase in PEAP - MSCHAPv2

[Hugo Veiga]

Hi,

I'm sorry Heikki I don't know why but I didn't receive your email (but a
friend of mine in this list as sent me yesterday).

So this is what I've tested/checked so far:

1 - Perl modules: In this list are the ones mentioned in the goodies file
for PEAP/MSCHAPv2 (# Requires Net_SSLeay.pm-1.21 or later; # Requires
openssl 0.9.7beta3 or later from www.openssl.org; # Requires Digest-HMAC; #
Requires Digest-SHA)

[root@radius02 radiator]# rpm -qa | grep perl
perl-Scalar-List-Utils-1.42-3.fc23.x86_64
perl-threads-2.02-2.fc23.x86_64
perl-ExtUtils-ParseXS-3.30-1.fc23.noarch
perl-IO-Socket-IP-0.37-347.fc23.noarch
perl-XML-Filter-BufferText-1.01-23.fc23.noarch
perl-Compress-Raw-Bzip2-2.068-347.fc23.x86_64
perl-IO-Socket-SSL-2.019-1.fc23.noarch
perl-GSSAPI-0.28-15.fc23.x86_64
perl-Perl-OSType-1.008-347.fc23.noarch
perl-Params-Check-0.38-346.fc23.noarch
perl-MRO-Compat-0.12-9.fc23.noarch
perl-Getopt-Long-2.48-1.fc23.noarch
perl-Algorithm-Diff-1.1903-3.fc23.noarch
perl-Devel-Size-0.80-3.fc23.x86_64
perl-Error-0.17024-4.fc23.noarch
perl-Pod-Perldoc-3.25-347.fc23.noarch
perl-Exporter-5.72-347.fc23.noarch
perl-WWW-Curl-4.17-6.fc23.x86_64
perl-Data-Dumper-2.158-347.fc23.x86_64
perl-version-0.99.12-4.fc23.x86_64
perl-Digest-SHA-5.95-347.fc23.x86_64
perl-Encode-Locale-1.05-3.fc23.noarch
perl-Business-ISBN-2.09-7.fc23.noarch
perl-XML-NamespaceSupport-1.11-16.fc23.noarch
perl-HTML-Parser-3.71-11.fc23.x86_64
perl-Sub-Install-0.928-6.fc23.noarch
perl-Compress-Bzip2-2.24-1.fc23.x86_64
perl-CPAN-Meta-YAML-0.016-4.fc23.noarch
perl-Time-HiRes-1.9728-1.fc23.x86_64
perl-File-Which-1.18-5.fc23.noarch
perl-Digest-SHA1-2.13-15.fc23.x86_64
perl-Time-Local-1.2300-346.fc23.noarch
perl-Pod-Escapes-1.07-348.fc23.noarch
perl-File-Path-2.09-347.fc23.noarch
perl-Module-CoreList-5.20160120-1.fc23.noarch
perl-Storable-2.53-346.fc23.x86_64
perl-Module-Pluggable-5.10-6.fc23.noarch
perl-File-Temp-0.23.04-346.fc23.noarch
perl-Pod-Simple-3.31-1.fc23.noarch
perl-DBI-1.633-6.fc23.x86_64
perl-ExtUtils-Manifest-1.70-346.fc23.noarch
perl-ExtUtils-Install-2.04-347.fc23.noarch
perl-libs-5.22.1-350.fc23.x86_64
perl-XML-SAX-Base-1.08-14.fc23.noarch
perl-Digest-HMAC-1.03-11.fc23.noarch
perl-Text-Unidecode-1.27-1.fc23.noarch
perl-URI-1.69-1.fc23.noarch
perl-TimeDate-2.30-7.fc23.noarch
perl-XML-SAX-Writer-0.53-9.fc23.noarch
perl-IO-HTML-1.001-4.fc23.noarch
perl-HTTP-Cookies-6.01-11.fc23.noarch
perl-JSON-2.90-5.fc23.noarch
perl-Params-Util-1.07-13.fc23.x86_64
perl-CPAN-Meta-Requirements-2.133-4.fc23.noarch
perl-Locale-Maketext-1.26-347.fc23.noarch
perl-IPC-Cmd-0.92-346.fc23.noarch
perl-Package-Generator-1.106-5.fc23.noarch
perl-Text-Template-1.46-3.fc23.noarch
perl-macros-5.22.1-350.fc23.x86_64
perl-Parse-CPAN-Meta-1.4417-2.fc23.noarch
perl-Socket-2.021-1.fc23.x86_64
perl-Archive-Tar-2.04-347.fc23.noarch
perl-File-HomeDir-1.00-10.fc23.noarch
perl-CPAN-2.11-348.fc23.noarch
perl-common-sense-3.7.4-1.fc23.x86_64
perl-Curses-1.33-1.fc23.x86_64
perl-HTTP-Tiny-0.056-3.fc23.noarch
perl-Text-ParseWords-3.30-346.fc23.noarch
perl-constant-1.33-347.fc23.noarch
perl-YAML-1.15-4.fc23.noarch
perl-Text-Tabs+Wrap-2013.0523-346.fc23.noarch
perl-parent-0.234-3.fc23.noarch
perl-DBD-MySQL-4.033-1.fc23.x86_64
perl-ExtUtils-Command-1.20-346.fc23.noarch
perl-ExtUtils-MakeMaker-7.04-347.fc23.noarch
perl-Digest-MD5-2.54-346.fc23.x86_64
perl-LWP-MediaTypes-6.02-8.fc23.noarch
perl-NTLM-1.09-11.fc23.noarch
perl-Text-Soundex-3.04-296.fc23.x86_64
perl-WWW-RobotRules-6.02-12.fc23.noarch
perl-HTTP-Date-6.02-12.fc23.noarch
perl-Net-SSLeay-1.71-1.fc23.x86_64
perl-HTTP-Message-6.11-1.fc23.noarch
perl-libwww-perl-6.15-1.fc23.noarch
perl-Convert-ASN1-0.27-4.fc23.noarch
perl-Module-Load-0.32-346.fc23.noarch
perl-Data-OptList-0.109-6.fc23.noarch
perl-Locale-Maketext-Simple-0.21-350.fc23.noarch
perl-ExtUtils-CBuilder-0.280224-1.fc23.noarch
perl-Sub-Exporter-0.987-6.fc23.noarch
perl-Software-License-0.103010-5.fc23.noarch
perl-PathTools-3.62-1.fc23.x86_64
perl-CPAN-Meta-2.150005-2.fc23.noarch
perl-5.22.1-350.fc23.x86_64
perl-inc-latest-0.500-3.fc23.noarch
perl-Text-Glob-0.09-13.fc23.noarch
perl-Crypt-SSLeay-0.72-7.fc23.x86_64
perl-BDB-1.91-3.fc23.x86_64
perl-Glib-1.313-1.fc23.x86_64
perl-Term-Cap-1.17-1.fc23.noarch
perl-MIME-Base64-3.15-348.fc23.x86_64
perl-Pod-Usage-1.67-3.fc23.noarch
openssl-perl-1.0.2e-3.fc23.x86_64
perl-Test-Harness-3.36-1.fc23.noarch
perl-Digest-1.17-346.fc23.noarch
perl-libnet-3.08-1.fc23.noarch
perl-Business-ISBN-Data-20140910.002-3.fc23.noarch
perl-File-Listing-6.04-11.fc23.noarch
perl-HTTP-Negotiate-6.01-11.fc23.noarch
perl-LDAP-0.65-3.fc23.noarch
perl-IO-Zlib-1.10-350.fc23.noarch
perl-local-lib-2.18-1.fc23.noarch
perl-JSON-PP-2.27300-347.fc23.noarch
perl-Unicode-Normalize-1.24-1.fc23.x86_64
perl-Module-Build-0.42.14-2.fc23.noarch
perl-Digest-MD4-1.9-8.fc23.x86_64
perl-Net-LibIDN-0.12-22.fc23.x86_64
perl-Term-ANSIColor-4.03-346.fc23.noarch
perl-Encode-2.78-2.fc23.x86_64
perl-threads-shared-1.48-346.fc23.x86_64
perl-Math-BigInt-1.9997-350.fc23.noarch

Re: [RADIATOR] radiator never gets to the 2nd authentication phase in PEAP - MSCHAPv2

[Christian Kratzer]

Hi,

On Tue, 26 Jan 2016, Hugo Veiga wrote:
> Hi Alan,
>
> I have the same config on radiator 4.9 and it works perfectly.
>
> About the stuff order ;) , I use the Authby as "functions" and usually I
> put them before the handlers, this is very practical to reuse code.
>
> As you suggested I tried to put them after the handlers and I have the same
> exact result.

try getting a trace 4 log from the authentication on your 4.9 radiator
so we can see the difference.

Greetings
Christian


>
> Best regards,
> Hugo Veiga
>
>
> 2016-01-25 19:09 GMT+00:00 Alan Buxey :
>
>> Try putting your stuff into order - your inner stuff , handlers et al ,
>> AFTER the realm check (where you are then asking for a particular handler).
>>
>> The goodies directory provides ready to go starting recipes for this stuff
>> (so you can see how handlers/inner work)
>>
>> alan
>

-- 
Christian Kratzer   CK Software GmbH
Email:   c...@cksoft.de   Wildberger Weg 24/2
Phone:   +49 7032 893 997 - 0   D-71126 Gaeufelden
Fax: +49 7032 893 997 - 9   HRB 245288, Amtsgericht Stuttgart
Mobile:  +49 171 1947 843   Geschaeftsfuehrer: Christian Kratzer
Web: http://www.cksoft.de/
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] radiator never gets to the 2nd authentication phase in PEAP - MSCHAPv2

[Hugo Veiga]

Hi Alan,

I have the same config on radiator 4.9 and it works perfectly.

About the stuff order ;) , I use the Authby as "functions" and usually I
put them before the handlers, this is very practical to reuse code.

As you suggested I tried to put them after the handlers and I have the same
exact result.

Best regards,
Hugo Veiga


2016-01-25 19:09 GMT+00:00 Alan Buxey :

> Try putting your stuff into order - your inner stuff , handlers et al ,
> AFTER the realm check (where you are then asking for a particular handler).
>
> The goodies directory provides ready to go starting recipes for this stuff
> (so you can see how handlers/inner work)
>
> alan
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] radiator never gets to the 2nd authentication phase in PEAP - MSCHAPv2

[Christian Kratzer]

Hi,

On Tue, 26 Jan 2016, Hugo Veiga wrote:

> In my original message I have by mistake a AuthBy INTERNAL in the outter
> authentication it's actually a AuthBy SQL clause.

which is exactly why I made you test your 4.9 case.


AuthBy SQL supports EAP.
AuthBy FILE also supports EAP.

and as Heikki said before: AuthBy INTERNAL does not.
>
>
> This is trace from radiator 4.9.
>
> Tue Jan 26 15:01:15 2016: DEBUG: Handling request with Handler
> 'Realm=/^convidado$/i', Identifier ''
> Tue Jan 26 15:01:15 2016: DEBUG:  Deleting session for 1745@convidado,
> 10.240.1.1, 54482
> Tue Jan 26 15:01:15 2016: DEBUG: Handling with Radius::AuthSQL:
> SQLAccounting
> Tue Jan 26 15:01:15 2016: DEBUG: AuthBy SQL result: IGNORE, Ignored due to
> IgnoreAuthentication
> Tue Jan 26 15:01:15 2016: DEBUG: Handling with Radius::AuthSQL: PEAP_CONVIDADO
> Tue Jan 26 15:01:15 2016: DEBUG: Handling with Radius::AuthSQL: PEAP_CONVIDADO

this is proof that the first packet is going into an AuthSQL.  In your
4.16 example it was going into your AuthBy INTERNAL handler.

Your old configuration should from 4.9 should run on 4.16.  Just do not
put swap your AuthBy FILE or AuthBy SQL  for an  AuthBy INTERNAL.

Greetings
Christian

-- 
Christian Kratzer   CK Software GmbH
Email:   c...@cksoft.de   Wildberger Weg 24/2
Phone:   +49 7032 893 997 - 0   D-71126 Gaeufelden
Fax: +49 7032 893 997 - 9   HRB 245288, Amtsgericht Stuttgart
Mobile:  +49 171 1947 843   Geschaeftsfuehrer: Christian Kratzer
Web: http://www.cksoft.de/
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] radiator never gets to the 2nd authentication phase in PEAP - MSCHAPv2

[Hugo Veiga]

In my original message I have by mistake a AuthBy INTERNAL in the outter
authentication it's actually a AuthBy SQL clause.


This is trace from radiator 4.9.

Tue Jan 26 15:01:15 2016: DEBUG: Handling request with Handler
'Realm=/^convidado$/i', Identifier ''
Tue Jan 26 15:01:15 2016: DEBUG:  Deleting session for 1745@convidado,
10.240.1.1, 54482
Tue Jan 26 15:01:15 2016: DEBUG: Handling with Radius::AuthSQL:
SQLAccounting
Tue Jan 26 15:01:15 2016: DEBUG: AuthBy SQL result: IGNORE, Ignored due to
IgnoreAuthentication
Tue Jan 26 15:01:15 2016: DEBUG: Handling with Radius::AuthSQL:
PEAP_CONVIDADO
Tue Jan 26 15:01:15 2016: DEBUG: Handling with Radius::AuthSQL:
PEAP_CONVIDADO
Tue Jan 26 15:01:15 2016: DEBUG: Handling with EAP: code 2, 1, 19, 1
Tue Jan 26 15:01:15 2016: DEBUG: Response type 1
Tue Jan 26 15:01:15 2016: DEBUG: EAP result: 3, EAP PEAP Challenge
Tue Jan 26 15:01:15 2016: DEBUG: AuthBy SQL result: CHALLENGE, EAP PEAP
Challenge
Tue Jan 26 15:01:15 2016: DEBUG: Access challenged for 1745@convidado: EAP
PEAP Challenge
Tue Jan 26 15:01:15 2016: DEBUG: Packet dump:
*** Sending to 10.240.1.1 port 20009 

Packet length = 46
0b 4f 00 2e 37 11 be 25 0c e7 2b ed b6 7b b5 31
79 0b 0d d8 4f 08 01 02 00 06 19 20 50 12 dc 0c
ea 9e 18 75 49 84 2c e3 ba 1b 6c f8 56 79
Code:   Access-Challenge
Identifier: 79
Authentic:  7<17><190>%<12><231>+<237><182>{<181>1y<11><13><216>
Attributes:
EAP-Message = <1><2><0><6><25>
Message-Authenticator =
<0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0>

Tue Jan 26 15:01:15 2016: DEBUG: Handling request with Handler
'Realm=/^convidado$/i', Identifier ''
Tue Jan 26 15:01:15 2016: DEBUG:  Deleting session for 1745@convidado,
10.240.1.1, 54482
Tue Jan 26 15:01:15 2016: DEBUG: Handling with Radius::AuthSQL:
SQLAccounting
Tue Jan 26 15:01:15 2016: DEBUG: AuthBy SQL result: IGNORE, Ignored due to
IgnoreAuthentication
Tue Jan 26 15:01:15 2016: DEBUG: Handling with Radius::AuthSQL:
PEAP_CONVIDADO
Tue Jan 26 15:01:15 2016: DEBUG: Handling with Radius::AuthSQL:
PEAP_CONVIDADO
Tue Jan 26 15:01:15 2016: DEBUG: Handling with EAP: code 2, 2, 122, 25
Tue Jan 26 15:01:15 2016: DEBUG: Response type 25
Tue Jan 26 15:01:15 2016: DEBUG: EAP result: 3, EAP PEAP Challenge
Tue Jan 26 15:01:15 2016: DEBUG: AuthBy SQL result: CHALLENGE, EAP PEAP
Challenge
Tue Jan 26 15:01:15 2016: DEBUG: Access challenged for 1745@convidado: EAP
PEAP Challenge
Tue Jan 26 15:01:15 2016: DEBUG: Packet dump:
*** Sending to 10.240.1.1 port 20009 

Packet length = 1056
0b 50 04 20 18 ae a2 7c d0 65 11 99 e3 db 6e 7c
d3 f3 ac 8d 4f ff 01 03 03 f2 19 c0 00 00 04 4b
16 03 01 00 51 02 00 00 4d 03 01 56 a7 8a 3b ca
c1 23 0c 67 0c d2 a8 e7 16 7a 42 2a 6a b1 b4 2b
f4 f0 1e fb 17 5a d0 2a 9b 99 17 20 bd c3 ec 85
7e 4f e0 28 47 40 6a 12 39 64 da bb 0a b0 78 04
6f b6 68 cd 51 4e 1d d2 6b bf 03 60 00 35 00 00
05 ff 01 00 01 00 16 03 01 03 e7 0b 00 03 e3 00
03 e0 00 03 dd 30 82 03 d9 30 82 02 c1 a0 03 02
01 02 02 09 00 a3 e4 3d af a8 38 8b 21 30 0d 06
09 2a 86 48 86 f7 0d 01 01 0b 05 00 30 81 81 31
0b 30 09 06 03 55 04 06 13 02 50 54 31 14 30 12
06 03 55 04 08 0c 0b 42 65 69 72 61 20 42 61 69
78 61 31 10 30 0e 06 03 55 04 07 0c 07 43 6f 76
69 6c 68 61 31 0c 30 0a 06 03 55 04 0a 0c 03 55
42 49 31 0b 30 09 06 03 55 04 0b 0c 02 53 49 31
11 30 0f 06 03 55 04 03 0c 08 72 61 64 69 75 73
30 31 31 4f ff 1c 30 1a 06 09 2a 86 48 86 f7 0d
01 09 01 16 0d 68 76 65 69 67 61 40 75 62 69 2e
70 74 30 20 17 0d 31 35 31 31 32 37 31 35 30 34
31 34 5a 18 0f 32 30 39 38 30 31 31 35 31 35 30
34 31 34 5a 30 81 81 31 0b 30 09 06 03 55 04 06
13 02 50 54 31 14 30 12 06 03 55 04 08 0c 0b 42
65 69 72 61 20 42 61 69 78 61 31 10 30 0e 06 03
55 04 07 0c 07 43 6f 76 69 6c 68 61 31 0c 30 0a
06 03 55 04 0a 0c 03 55 42 49 31 0b 30 09 06 03
55 04 0b 0c 02 53 49 31 11 30 0f 06 03 55 04 03
0c 08 72 61 64 69 75 73 30 31 31 1c 30 1a 06 09
2a 86 48 86 f7 0d 01 09 01 16 0d 68 76 65 69 67
61 40 75 62 69 2e 70 74 30 82 01 22 30 0d 06 09
2a 86 48 86 f7 0d 01 01 01 05 00 03 82 01 0f 00
30 82 01 0a 02 82 01 01 00 ea e6 b1 7f 27 3e 9c
e2 bf 32 b7 ab cb e4 cc f4 58 49 10 84 90 ca 6f
04 e1 4f ff 11 7e 17 ea 54 ee d8 9e 1f 65 ae 14
c3 38 a6 9a 3f d9 c7 08 a5 4d 96 79 d6 5a 21 3b
11 f2 11 fa 5a d6 17 36 6e 0b 97 52 6d 17 68 64
be 53 3a af a3 a6 44 7f 28 ec 13 9a e6 83 4f 58
cf d2 e4 f1 df c7 66 3c dc 95 b8 30 e9 f0 5c 4b
9f e2 cc 0b a3 bb da aa cc 83 0a 5d ba a7 3c d6
d6 ab 60 23 f0 cd 10 6b 31 8f 9b 71 e5 0e 6a ca
6f 4d 0c 06 fd 26 ee c4 08 0f 50 b4 ef 08 2e 98
93 68 fa a2 cb 16 fe a8 e8 a0 2a 2e 95 b5 e7 04
66 da 8b c1 ef 1a 78 51 6c af db 7a b4 7b 49 49
5d 16 ed e7 a4 7a a7 4b 7b 29 be aa 21 26 f7 9f
3e 7a b1 f0 22 63 36 b3 d7 63 7e 4c a2 2c bc 25
4e 49 2c e5 e5 d1 40 6c 0f ee 9c d0 1d 01 af 49
94 29 4d 61 62 0f b9 55 8e 65 7d a1 ad 82 88 33
a0 92 01 7a 24 91 67 5b 7e 99 59 02 03 01 00 01
a3 50 30 4e 30 1d 06 03 55 1d 0e 04 16 04 14 eb
bb 4f fd f0 27 e9 39 88 fc 26 d0 e8 33 23 73 0f
2d 73 f7 8e 5b 30 1f 06 03 55 1d 23 04 18 30 16
80 14 eb bb f0 27 e9 39 88 fc 26 

Re: [RADIATOR] radiator never gets to the 2nd authentication phase in PEAP - MSCHAPv2

[Hugo Veiga]

Sorry For the waist of your time, and thanks for your point (I was
trying all possible things that I could remember and this went to the list
by mistake).

Also tried another certificate but it's doing the same, it gets stuck and
never reaches the inner handler.

Here is a trace from 4.16 with the SQL clause just like 4.9 (except for the
AuthBy SQL "Accounting" - that's in the 4.9 because its a production
eviroment) with i'm not doing right now for the 4.16.

Best regards,
Hugo Veiga


The config file for 4.16:




Identifier PEAP_CONVIDADO_INNER
DBSource dbi:mysql:radius-temp
DBUsername db_user
DBAuth db_passwd_1234
Timeout 10
SQLRetries 4
FailureBackoffTime 10
EAPType MSCHAP-V2
AuthSelect SELECT password FROM convidado WHERE
username=SUBSTRING('%u',1,LOCATE('@','%u')) AND datai<"%Y-%m-%d %H:%M:%S"
AND dataf>"%Y-%m-%d %H:%M:%S"



Identifier PEAP_CONVIDADO
   DBSource dbi:mysql:radius-temp
DBUsername db_user
DBAuth db_passwd_1234
Timeout 10
SQLRetries 4
FailureBackoffTime 10
EAPType PEAP
EAPAnonymous %u
EAPTLS_PEAPVersion 0
EAPTTLS_NoAckRequired
EAPTLS_CAFile /etc/radiator/hvcert.pem
EAPTLS_CertificateFile /etc/radiator/hvcert.pem
EAPTLS_CertificateType PEM
EAPTLS_PrivateKeyFile /etc/radiator/hvkey.pem
EAPTLS_MaxFragmentSize 1000
AutoMPPEKeys





AuthBy PEAP_CONVIDADO_INNER





AuthByPolicy ContinueAlways
#AuthBy SQLAccounting - Not in for this test used
AuthBy PEAP_CONVIDADO




Dump:

Tue Jan 26 15:54:52 2016: DEBUG: Packet dump:
*** Received from 10.240.1.1 port 20004 

Packet length = 163
01 b4 00 a3 8b 03 28 8f 0a 8b 4e 9e 3c 46 ac c2
a3 a8 87 4f 57 07 41 50 32 2f 31 1f 13 43 34 2d
38 35 2d 30 38 2d 41 36 2d 43 30 2d 32 46 1e 1b
30 30 2d 31 31 2d 38 38 2d 44 32 2d 44 39 2d 39
34 3a 63 63 74 65 73 74 65 06 06 00 00 00 02 4f
15 02 01 00 13 01 31 37 34 35 40 63 6f 6e 76 69
64 61 64 6f 01 10 31 37 34 35 40 63 6f 6e 76 69
64 61 64 6f 05 06 00 00 dc 55 3d 06 00 00 00 13
04 06 0a f0 01 01 20 0b 65 6e 74 65 72 61 73 79
73 50 12 e3 bc 56 bf 10 ec 97 f5 f8 22 c6 7e 96
a4 80 c8
Code:   Access-Request
Identifier: 180
Authentic:  <139><3>(<143><10><139>N<158><194><163><168><135>O
Attributes:
NAS-Port-Id = "AP2/1"
Calling-Station-Id = "C4-85-08-A6-C0-2F"
Called-Station-Id = "00-11-88-D2-D9-94:ccteste"
Service-Type = Framed-User
EAP-Message = <2><1><0><19><1>1745@convidado
User-Name = "1745@convidado"
NAS-Port = 56405
NAS-Port-Type = Wireless-IEEE-802-11
NAS-IP-Address = 10.240.1.1
NAS-Identifier = "enterasys"
Message-Authenticator =
<227><188>V<191><16><236><151><245><248>"<198>~<150><164><128><200>

Tue Jan 26 15:54:52 2016: DEBUG: Handling request with Handler
'Realm=/^convidado$/i', Identifier ''
Tue Jan 26 15:54:52 2016: DEBUG:  Deleting session for 1745@convidado,
10.240.1.1, 56405
Tue Jan 26 15:54:52 2016: DEBUG: Handling with Radius::AuthSQL:
PEAP_CONVIDADO
Tue Jan 26 15:54:52 2016: DEBUG: Handling with Radius::AuthSQL:
PEAP_CONVIDADO
Tue Jan 26 15:54:52 2016: DEBUG: Handling with EAP: code 2, 1, 19, 1
Tue Jan 26 15:54:52 2016: DEBUG: Response type 1
Tue Jan 26 15:54:52 2016: DEBUG: EAP result: 3, EAP PEAP Challenge
Tue Jan 26 15:54:52 2016: DEBUG: AuthBy SQL result: CHALLENGE, EAP PEAP
Challenge
Tue Jan 26 15:54:52 2016: DEBUG: Access challenged for 1745@convidado: EAP
PEAP Challenge
Tue Jan 26 15:54:52 2016: DEBUG: Packet dump:
*** Sending to 10.240.1.1 port 20004 

Packet length = 46
0b b4 00 2e fa a6 ac 2d f7 6f 14 aa 11 5c 6e 0e
a4 24 88 8e 4f 08 01 02 00 06 19 20 50 12 2d 47
b9 13 e4 7d 75 21 1b 7e 14 4b 39 67 16 5e
Code:   Access-Challenge
Identifier: 180
Authentic:  <250><166><172>-<247>o<20><170><17>\n<14><164>$<136><142>
Attributes:
EAP-Message = <1><2><0><6><25>
Message-Authenticator =
<0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0>

Tue Jan 26 15:54:57 2016: DEBUG: Packet dump:
*** Received from 10.240.1.1 port 20004 

Packet length = 163
01 b4 00 a3 8b 03 28 8f 0a 8b 4e 9e 3c 46 ac c2
a3 a8 87 4f 57 07 41 50 32 2f 31 1f 13 43 34 2d
38 35 2d 30 38 2d 41 36 2d 43 30 2d 32 46 1e 1b
30 30 2d 31 31 2d 38 38 2d 44 32 2d 44 39 2d 39
34 3a 63 63 74 65 73 74 65 06 06 00 00 00 02 4f
15 02 01 00 13 01 31 37 34 35 40 63 6f 6e 76 69
64 61 64 6f 01 10 31 37 34 35 40 63 6f 6e 76 69
64 61 64 6f 05 06 00 00 dc 55 3d 06 00 00 00 13
04 06 0a f0 01 01 20 0b 65 6e 74 65 72 61 73 79
73 50 12 e3 bc 56 bf 10 ec 97 f5 f8 22 c6 7e 96
a4 80 c8
Code:   Access-Request
Identifier: 180
Authentic:  <139><3>(<143><10><139>N<158><194><163><168><135>O
Attributes:
NAS-Port-Id = "AP2/1"
Calling-Station-Id = "C4-85-08-A6-C0-2F"
Called-Station-Id = "00-11-88-D2-D9-94:ccteste"
Service-Type = Framed-User
 

Re: [RADIATOR] radiator never gets to the 2nd authentication phase in PEAP - MSCHAPv2

[Alan Buxey]

Try putting your stuff into order - your inner stuff , handlers et al , AFTER 
the realm check (where you are then asking for a particular handler). 

The goodies directory provides ready to go starting recipes for this stuff (so 
you can see how handlers/inner work)

alan___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] radiator never gets to the 2nd authentication phase in PEAP - MSCHAPv2

[Heikki Vatiainen]

On 01/25/2016 07:57 PM, Hugo Veiga wrote:

> I'm upgrading from 4.9 to radiator 4.16 and I'm stuck because I can't
> get radiator to get to the inner authentication phase.

AuthBy INTERNAL does not work with EAP (PEAP in this case). It just
ignores the request by default.

If you had problems with the upgrade and changed your configuration,
make sure that you have Digest::SHA installed. It became an mandatory in
Radiator 4.10. It's part of core Perl since Perl 5.10. For some reason
RHEL and CentOS have packaged it separately, so for those you need to
install perl-Digest-SHA RPM package.

> It simply doesn't dispatch to the inner handler! Am I missing to install
> something?

It's the AuthBy INTERNAL that's causing this. See if you have an older
configuration and compare what has changed.

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] RADIATOR 4.16 clause checks...

[Heikki Vatiainen]

On 16.11.2015 13.32, a.l.m.bu...@lboro.ac.uk wrote:

> seems fussy about the upper/lower case eg

I'll see that this gets changed. I'd say case insensitive check is 
enough here.

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

[RADIATOR] RADIATOR 4.16 clause checks...

[A . L . M . Buxey]

hi,

seems fussy about the upper/lower case eg

WARNING: Clause Authby closed in /etc/radiator/radius.cfg line 121 does not 
match currently open clause AuthBy from /etc/radiator/radius.cfg line 118


# Local test realm

# Strip realm
RewriteUsername s/^([^@]+).*/$1/

# Users file for testing purposes
Filename /etc/radiator/testusers



so,




is it supposed to be this fussy?  :-)

alan

___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Radiator Version 4.16 released - security fixes, enhancements and new features

[Heikki Vatiainen]

On 11/03/2015 10:25 PM, Ullfig, Roberto Alfredo wrote:
> Ah, the Android 6 support is in base 4.16 then - my mistake. Thanks!

Yes. 4.16 should do the right thing no matter what the OpenSSL and
Net::SSLeay versions are. It will also log during the startup about the
versions it finds and what they can be done with (if TLS 1.2 is support
and can be enabled etc.).

Besides Android 6, some of the recent Linux distributions ship with
wpa_supplicant that will try to use TLS 1.2, just like Android 6 does.
The working TLS 1.2 support should keep these users happy too.

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] Radiator Version 4.16 released - security fixes, enhancements and new features

[Heikki Vatiainen]

On 11/03/2015 09:54 PM, Ullfig, Roberto Alfredo wrote:
> Also, is it typical for patches to not be released in RPMs?

Yes, the patches work best with the .tgz package:
- untar the release .tgz
- untar the patches on top of this
- then proceed with 'perl Makefile.PL' as described in the installation
manual for the .tgz package.

While it's possible to replace files that were installed with rpm, I'd
do it only when there's a specific need for it.

> We installed the previous version from RPM. Should we remove that RPM before 
> installing this version plus patches?

'rpm -Uvh Radiator-4.16-1.noarch.rpm' should be enough to upgrade if you
do not need patches and want to stay with rpm packaging. If there's
something in the patches you do need, then you could consider switching
to .tgz + patches.

I'd say the current patches are not worth switching from rpm unless you
want to try the RadSec Gossip features.

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] Radiator Version 4.16 released - security fixes, enhancements and new features

[Ullfig, Roberto Alfredo]

Ah, the Android 6 support is in base 4.16 then - my mistake. Thanks!

---
Roberto Ullfig - rull...@uic.edu
ACCC Research Programmer


-Original Message-
From: radiator-boun...@open.com.au [mailto:radiator-boun...@open.com.au] On 
Behalf Of Heikki Vatiainen
Sent: Tuesday, November 03, 2015 2:22 PM
To: radiator@open.com.au
Subject: Re: [RADIATOR] Radiator Version 4.16 released - security fixes, 
enhancements and new features

On 11/03/2015 09:54 PM, Ullfig, Roberto Alfredo wrote:
> Also, is it typical for patches to not be released in RPMs?

Yes, the patches work best with the .tgz package:
- untar the release .tgz
- untar the patches on top of this
- then proceed with 'perl Makefile.PL' as described in the installation manual 
for the .tgz package.

While it's possible to replace files that were installed with rpm, I'd do it 
only when there's a specific need for it.

> We installed the previous version from RPM. Should we remove that RPM before 
> installing this version plus patches?

'rpm -Uvh Radiator-4.16-1.noarch.rpm' should be enough to upgrade if you do not 
need patches and want to stay with rpm packaging. If there's something in the 
patches you do need, then you could consider switching to .tgz + patches.

I'd say the current patches are not worth switching from rpm unless you want to 
try the RadSec Gossip features.

Thanks,
Heikki

--
Heikki Vatiainen <h...@open.com.au>

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
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Radiator Version 4.16 released - security fixes, enhancements and new features

[Ullfig, Roberto Alfredo]

Also, is it typical for patches to not be released in RPMs?

---
Roberto Ullfig – rull...@uic.edu
ACCC Research Programmer


-Original Message-
From: radiator-boun...@open.com.au [mailto:radiator-boun...@open.com.au] On 
Behalf Of Ullfig, Roberto Alfredo
Sent: Tuesday, November 03, 2015 1:48 PM
To: radiator@open.com.au
Subject: Re: [RADIATOR] Radiator Version 4.16 released - security fixes, 
enhancements and new features

We installed the previous version from RPM. Should we remove that RPM before 
installing this version plus patches?

---
Roberto Ullfig – rull...@uic.edu
ACCC Research Programmer


-Original Message-
From: radiator-boun...@open.com.au [mailto:radiator-boun...@open.com.au] On 
Behalf Of Heikki Vatiainen
Sent: Tuesday, October 27, 2015 4:57 AM
To: radiator@open.com.au
Subject: [RADIATOR] Radiator Version 4.16 released - security fixes, 
enhancements and new features

We are pleased to announce the release of Radiator version 4.16

This version contains two important security fixes. Upgrade is recommended. 
Please review OSC security advisory OSC-SEC-2015-02 for more information:
https://www.open.com.au/OSC-SEC-2015-02.html

As usual, the new version is available to current licensees from:
https://www.open.com.au/radiator/downloads/

and to current evaluators from:
https://www.open.com.au/radiator/demo-downloads

Licensees with expired access contracts can renew at:
https://www.open.com.au/renewal.html

An extract from the history file
https://www.open.com.au/radiator/history.html is below:

-

Revision 4.16 (2015-10-27)

   Selected bug fixes, compatibility notes, new features and enhancements

Compatibility update for EAP-based TLS methods for clients that support TLS 
1.2. Examples are the future Apple iOS and OS X releases and Android
6 Marshmallow.

Two important security fixes. OSC recommends all users to review OSC security 
advisory OSC-SEC-2015-02 https://www.open.com.au/OSC-SEC-2015-02.html

TLS session resumption may not currently work with all Windows clients. 
A workaround is to configure the EAPTLS_SessionResumption parameter to 0 or 
wait for the client to retry the authentication.

Radiator now supports new module AddressAllocator DHCPv6 for IPv6 address 
allocation and prefix delegation



   Detailed changes


Created separate directory for PPM files compiled for ActivePerl. Moved files 
from ppm to ppm/activeperl/ and updated the meta file contents.
Win32-Lsa is now compiled for both ActivePerl 5.18 and 5.20 flavours up to Perl 
5.20: 64bit and 32bit with 64bit integer.
Created separate directory for PPM files compiled for Strawberry Perl.
Win32-Lsa is now compiled for all Strawberry Perl flavours up to Perl
5.22: 64bit, 32bit with 32bit integers and 32bit with 64bit integers.

Radiator now logs the Net::SSLeay and SSL/TLS library version during the 
radiusd startup. TLS v1.2 for TLS based EAP methods is not used if it can not 
be determined that the MPPE keys can be correctly calculated. 
These changes enhance compatibility with future Apple iOS, OS X and Android 6 
Marshmallow. If all TLS versions are not available, details of what can be used 
is logged. Net::SSLeay 1.53 or later and OpenSSL 1.0.1 or later is required to 
fully utilise all TLS versions for TLS based EAP methods. Thanks to radiator 
mailing list members for comments and suggestions.

AuthLog SYSLOG and Log SYSLOG clauses now support LogPort configuration 
parameter. This parameter requires Sys::Syslog version 0.28 or later. 
Suggested by Michael and Kilian Krause.

LDAP modules now support BindFailedHook which is called when LDAP bind 
operation fails. The default is to log the failure. Bind password is no longer 
logged. To log the password, configure the hook to log it or configure the LDAP 
clause with the Debug configuration parameter and see the console output. With 
the kind help of Scott Bertilson.

AuthBy LDAP2 now logs PasswordAttr as **obscured** when debugging is enabled. 
Binary attribute values are now logged in text format similarly to RADIUS 
attributes. To debug the password, use the Debug configuration parameter and 
see the console output or configure PasswordLogFileName for the Handler.

Resolver for AuthBy DNSROAM now uses eval to catch exceptions from Net::DNS. 
The Net:DNS API had been changed around version 0.72 to raise exceptions when 
errors occurred. Uncaught exceptions could cause Radiator to crash. Reports and 
help with patches from Bjoern A. Zeeb and Paul Dekkers.

Updated error levels for Resolver log messages. Most of the log messages are 
now using WARNING instead of ERR. These messages are logged for example for DNS 
failures or badly formatted DNS domains.

ServerHTTP authentication now creates a request that can be correctly proxied 
to a remote server. Previously the proxied authentication would always fail.

AuthBy RADIUS and its derived modules still required 'ipv6:' prefix for 
LocalAddress parameter. Reported

Re: [RADIATOR] Radiator Version 4.16 released - security fixes, enhancements and new features

[Ullfig, Roberto Alfredo]

We installed the previous version from RPM. Should we remove that RPM before 
installing this version plus patches?

---
Roberto Ullfig – rull...@uic.edu
ACCC Research Programmer


-Original Message-
From: radiator-boun...@open.com.au [mailto:radiator-boun...@open.com.au] On 
Behalf Of Heikki Vatiainen
Sent: Tuesday, October 27, 2015 4:57 AM
To: radiator@open.com.au
Subject: [RADIATOR] Radiator Version 4.16 released - security fixes, 
enhancements and new features

We are pleased to announce the release of Radiator version 4.16

This version contains two important security fixes. Upgrade is recommended. 
Please review OSC security advisory OSC-SEC-2015-02 for more information:
https://www.open.com.au/OSC-SEC-2015-02.html

As usual, the new version is available to current licensees from:
https://www.open.com.au/radiator/downloads/

and to current evaluators from:
https://www.open.com.au/radiator/demo-downloads

Licensees with expired access contracts can renew at:
https://www.open.com.au/renewal.html

An extract from the history file
https://www.open.com.au/radiator/history.html is below:

-

Revision 4.16 (2015-10-27)

   Selected bug fixes, compatibility notes, new features and enhancements

Compatibility update for EAP-based TLS methods for clients that support TLS 
1.2. Examples are the future Apple iOS and OS X releases and Android
6 Marshmallow.

Two important security fixes. OSC recommends all users to review OSC security 
advisory OSC-SEC-2015-02 https://www.open.com.au/OSC-SEC-2015-02.html

TLS session resumption may not currently work with all Windows clients. 
A workaround is to configure the EAPTLS_SessionResumption parameter to 0 or 
wait for the client to retry the authentication.

Radiator now supports new module AddressAllocator DHCPv6 for IPv6 address 
allocation and prefix delegation



   Detailed changes


Created separate directory for PPM files compiled for ActivePerl. Moved 
files from ppm to ppm/activeperl/ and updated the meta file contents.
Win32-Lsa is now compiled for both ActivePerl 5.18 and 5.20 flavours up 
to Perl 5.20: 64bit and 32bit with 64bit integer.
Created separate directory for PPM files compiled for Strawberry Perl.
Win32-Lsa is now compiled for all Strawberry Perl flavours up to Perl 
5.22: 64bit, 32bit with 32bit integers and 32bit with 64bit integers.

Radiator now logs the Net::SSLeay and SSL/TLS library version during the 
radiusd startup. TLS v1.2 for TLS based EAP methods is not used if it 
can not be determined that the MPPE keys can be correctly calculated. 
These changes enhance compatibility with future Apple iOS, OS X and 
Android 6 Marshmallow. If all TLS versions are not available, details of 
what can be used is logged. Net::SSLeay 1.53 or later and OpenSSL 1.0.1 
or later is required to fully utilise all TLS versions for TLS based EAP 
methods. Thanks to radiator mailing list members for comments and 
suggestions.

AuthLog SYSLOG and Log SYSLOG clauses now support LogPort configuration 
parameter. This parameter requires Sys::Syslog version 0.28 or later. 
Suggested by Michael and Kilian Krause.

LDAP modules now support BindFailedHook which is called when LDAP bind 
operation fails. The default is to log the failure. Bind password is no 
longer logged. To log the password, configure the hook to log it or 
configure the LDAP clause with the Debug configuration parameter and see 
the console output. With the kind help of Scott Bertilson.

AuthBy LDAP2 now logs PasswordAttr as **obscured** when debugging is 
enabled. Binary attribute values are now logged in text format similarly 
to RADIUS attributes. To debug the password, use the Debug configuration 
parameter and see the console output or configure PasswordLogFileName 
for the Handler.

Resolver for AuthBy DNSROAM now uses eval to catch exceptions from 
Net::DNS. The Net:DNS API had been changed around version 0.72 to raise 
exceptions when errors occurred. Uncaught exceptions could cause 
Radiator to crash. Reports and help with patches from Bjoern A. Zeeb and 
Paul Dekkers.

Updated error levels for Resolver log messages. Most of the log messages 
are now using WARNING instead of ERR. These messages are logged for 
example for DNS failures or badly formatted DNS domains.

ServerHTTP authentication now creates a request that can be correctly 
proxied to a remote server. Previously the proxied authentication would 
always fail.

AuthBy RADIUS and its derived modules still required 'ipv6:' prefix for 
LocalAddress parameter. Reported by Claudio Ramirez. Correct address is 
now logged if binding to LocalAddress fails.

Huawei-DNS-Server-IPv6-Address, Huawei-Framed-IPv6-Address, 
Alc-Ipv6-Address, Alc-Ipv6-Primary-Dns and Alc-Ipv6-Secondary-Dns had 
incorrect type ipv6addr. The correct type is ipaddrv6 for IPv6 addresses.

SqlDb now initialises the DBD::ODBC odbc_query_timeout attribute with 
the Timeout configuration parameter value. This attribute is valid only

[RADIATOR] Radiator Version 4.16 released - security fixes, enhancements and new features

[Heikki Vatiainen]

We are pleased to announce the release of Radiator version 4.16

This version contains two important security fixes. Upgrade is 
recommended. Please review OSC security
advisory OSC-SEC-2015-02 for more information:
https://www.open.com.au/OSC-SEC-2015-02.html

As usual, the new version is available to current licensees from:
https://www.open.com.au/radiator/downloads/

and to current evaluators from:
https://www.open.com.au/radiator/demo-downloads

Licensees with expired access contracts can renew at:
https://www.open.com.au/renewal.html

An extract from the history file
https://www.open.com.au/radiator/history.html is below:

-

Revision 4.16 (2015-10-27)

   Selected bug fixes, compatibility notes, new features and enhancements

Compatibility update for EAP-based TLS methods for clients that support 
TLS 1.2. Examples are the future Apple iOS and OS X releases and Android 
6 Marshmallow.

Two important security fixes. OSC recommends all users to review OSC 
security advisory OSC-SEC-2015-02
https://www.open.com.au/OSC-SEC-2015-02.html

TLS session resumption may not currently work with all Windows clients. 
A workaround is to configure the EAPTLS_SessionResumption parameter to 0 
or wait for the client to retry the authentication.

Radiator now supports new module AddressAllocator DHCPv6 for IPv6 
address allocation and prefix delegation



   Detailed changes


Created separate directory for PPM files compiled for ActivePerl. Moved 
files from ppm to ppm/activeperl/ and updated the meta file contents.
Win32-Lsa is now compiled for both ActivePerl 5.18 and 5.20 flavours up 
to Perl 5.20: 64bit and 32bit with 64bit integer.
Created separate directory for PPM files compiled for Strawberry Perl.
Win32-Lsa is now compiled for all Strawberry Perl flavours up to Perl 
5.22: 64bit, 32bit with 32bit integers and 32bit with 64bit integers.

Radiator now logs the Net::SSLeay and SSL/TLS library version during the 
radiusd startup. TLS v1.2 for TLS based EAP methods is not used if it 
can not be determined that the MPPE keys can be correctly calculated. 
These changes enhance compatibility with future Apple iOS, OS X and 
Android 6 Marshmallow. If all TLS versions are not available, details of 
what can be used is logged. Net::SSLeay 1.53 or later and OpenSSL 1.0.1 
or later is required to fully utilise all TLS versions for TLS based EAP 
methods. Thanks to radiator mailing list members for comments and 
suggestions.

AuthLog SYSLOG and Log SYSLOG clauses now support LogPort configuration 
parameter. This parameter requires Sys::Syslog version 0.28 or later. 
Suggested by Michael and Kilian Krause.

LDAP modules now support BindFailedHook which is called when LDAP bind 
operation fails. The default is to log the failure. Bind password is no 
longer logged. To log the password, configure the hook to log it or 
configure the LDAP clause with the Debug configuration parameter and see 
the console output. With the kind help of Scott Bertilson.

AuthBy LDAP2 now logs PasswordAttr as **obscured** when debugging is 
enabled. Binary attribute values are now logged in text format similarly 
to RADIUS attributes. To debug the password, use the Debug configuration 
parameter and see the console output or configure PasswordLogFileName 
for the Handler.

Resolver for AuthBy DNSROAM now uses eval to catch exceptions from 
Net::DNS. The Net:DNS API had been changed around version 0.72 to raise 
exceptions when errors occurred. Uncaught exceptions could cause 
Radiator to crash. Reports and help with patches from Bjoern A. Zeeb and 
Paul Dekkers.

Updated error levels for Resolver log messages. Most of the log messages 
are now using WARNING instead of ERR. These messages are logged for 
example for DNS failures or badly formatted DNS domains.

ServerHTTP authentication now creates a request that can be correctly 
proxied to a remote server. Previously the proxied authentication would 
always fail.

AuthBy RADIUS and its derived modules still required 'ipv6:' prefix for 
LocalAddress parameter. Reported by Claudio Ramirez. Correct address is 
now logged if binding to LocalAddress fails.

Huawei-DNS-Server-IPv6-Address, Huawei-Framed-IPv6-Address, 
Alc-Ipv6-Address, Alc-Ipv6-Primary-Dns and Alc-Ipv6-Secondary-Dns had 
incorrect type ipv6addr. The correct type is ipaddrv6 for IPv6 addresses.

SqlDb now initialises the DBD::ODBC odbc_query_timeout attribute with 
the Timeout configuration parameter value. This attribute is valid only 
for ODBC and is set only when Radiator runs on a Windows host. The 
default value for odbc_query_timeout is 0 which can cause very long 
timeouts on Windows with SQL queries.

While RADIUS dictionaries are loaded, attributes with unknown types are 
logged with trace level WARNING. The treatment of unknown types has not 
changed: the unknown types are treated as binary.

Incorrectly formatted textual IPv6 addresses in configuration files or 
retrieved for example from SQL 

Re: [RADIATOR] Radiator, WPA2, certificates and untrusted

[A . L . M . Buxey]

Hi,

>Oh man!
> 
>In other words it's a waste of good money to pay for a signed certificate.

for your own internal 802.1X (where you are only directly authenticating your 
own users
(and that includes eg eduroam) - yes.  best practice is to use a self-signed CA 
 (you have the
same issues in getting the Root CA onto the clients but there are tools, some 
free, for that
anyway.


for a public 802.1X system where any person wants to join then there are 2 
arguments - ease of use
(go for well known public CA) or security - use a self-signed CA.   I'd hope 
such a public 802.1X
system (and there are some out there nowand increasing due to eg 
HS2.0/passpoint/802.11u) would
have some configuration system/tool and they should use a self-signed CA - any 
$0.01 script kiddie can 
geta  cert from a well known CA for some $$ and fake your AP/network  :/


alan
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Radiator, WPA2, certificates and untrusted

[Jesper Skou Jensen]

Oh man!

In other words it's a waste of good money to pay for a signed certificate. :(

But thanks for the info, that explains why I couldn't get the bloody thing 
working the way I wanted.


Regards
Jesper


Fra: Ole Frendved Hansen [mailto:o...@dtu.dk]
Sendt: 1. september 2015 17:15
Til: Jesper Skou Jensen
Cc: radiator@open.com.au
Emne: Re: [RADIATOR] Radiator, WPA2, certificates and untrusted

Hi Jesper,

I think this is normal behavior.
In eduroam we install the CA's root-certificate in the client/supplicant. (The 
'eduroam CAT' crafted installer does so).

The clients certificate store is the responsibility of the browser (in a 
laptop).
So, in a web context your server-certificate is said to be click-free 
(automatic acknowledged), if the CA has paid to be included in the default 
collection within the certificate store.

I am not into if wi-fi is able to access those certificate stores on some 
platforms.


Best, Ole
--
ole.frendved.han...@deic.dk<mailto:ole.frendved.han...@deic.dk>
DeIC, Danish e-Infrastructure Cooperation, www.deic.dk<http://www.deic.dk>



Den 01/09/2015 kl. 15.48 skrev Jesper Skou Jensen 
<jesper.skou.jen...@stil.dk<mailto:jesper.skou.jen...@stil.dk>>:


Hello people,

I'm in the process of renewing a certificate for our Radiator setup and I've 
run into a bit of problem.

The problem is that I can't get clients to trust the WPA2 certificate when 
connecting to the network. Eg. Windows 7, an iPhone and probably other clients  
too.

On the iOS I keep getting the message "Not Trusted" when logging on to the 
network the first time and on both Windows and iOS I have to accept the 
certificate before getting logged on.

I'm wondering if that's the way it's supposed to work or if I've done something 
wrong with my Radiator config?


It's a Enterprise WPA2 setup.

Running Radiator version 4.15 on Linux.

The certificate is signed by COMODO and should be trusted by various browsers, 
phones, etc.

The certificate specific part of the radiator configuration is like this:

EAPTLS_CAPath %D/certificates/ca-certs
EAPTLS_CertificateChainFile %D/certificates/server-chain
EAPTLS_CertificateType PEM
EAPTLS_PrivateKeyFile %D/certificates/server-key

ca-certs only one file "AddTrustAB.pem" that has the CA Root certificate.
server-key is my private key.
server-chain first has my public key followed by two intermediate certs.


Does that sound about right, or have you got any recommendations?


Regards
Jesper Skou Jensen
___
radiator mailing list
radiator@open.com.au<mailto:radiator@open.com.au>
http://www.open.com.au/mailman/listinfo/radiator

___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Radiator, WPA2, certificates and untrusted

[Ole Frendved Hansen]

Hi Jesper,

I think this is normal behavior.
In eduroam we install the CA’s root-certificate in the client/supplicant. (The 
'eduroam CAT’ crafted installer does so).

The clients certificate store is the responsibility of the browser (in a 
laptop).
So, in a web context your server-certificate is said to be click-free 
(automatic acknowledged), if the CA has paid to be included in the default 
collection within the certificate store.

I am not into if wi-fi is able to access those certificate stores on some 
platforms.


Best, Ole
--
ole.frendved.han...@deic.dk
DeIC, Danish e-Infrastructure Cooperation, www.deic.dk




Den 01/09/2015 kl. 15.48 skrev Jesper Skou Jensen :

> Hello people,
> 
> I’m in the process of renewing a certificate for our Radiator setup and I’ve 
> run into a bit of problem.
> 
> The problem is that I can’t get clients to trust the WPA2 certificate when 
> connecting to the network. Eg. Windows 7, an iPhone and probably other 
> clients  too.
> 
> On the iOS I keep getting the message “Not Trusted” when logging on to the 
> network the first time and on both Windows and iOS I have to accept the 
> certificate before getting logged on.
> 
> I’m wondering if that’s the way it’s supposed to work or if I’ve done 
> something wrong with my Radiator config?
> 
> 
> It’s a Enterprise WPA2 setup.
> 
> Running Radiator version 4.15 on Linux.
> 
> The certificate is signed by COMODO and should be trusted by various 
> browsers, phones, etc.
> 
> The certificate specific part of the radiator configuration is like this:
> 
> EAPTLS_CAPath %D/certificates/ca-certs
> EAPTLS_CertificateChainFile %D/certificates/server-chain
> EAPTLS_CertificateType PEM
> EAPTLS_PrivateKeyFile %D/certificates/server-key
> 
> ca-certs only one file “AddTrustAB.pem” that has the CA Root certificate.
> server-key is my private key.
> server-chain first has my public key followed by two intermediate certs.
> 
> 
> Does that sound about right, or have you got any recommendations?
> 
> 
> Regards
> Jesper Skou Jensen
> ___
> radiator mailing list
> radiator@open.com.au
> http://www.open.com.au/mailman/listinfo/radiator



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

[RADIATOR] Radiator, WPA2, certificates and untrusted

[Jesper Skou Jensen]

Hello people,

I'm in the process of renewing a certificate for our Radiator setup and I've 
run into a bit of problem.

The problem is that I can't get clients to trust the WPA2 certificate when 
connecting to the network. Eg. Windows 7, an iPhone and probably other clients  
too.

On the iOS I keep getting the message "Not Trusted" when logging on to the 
network the first time and on both Windows and iOS I have to accept the 
certificate before getting logged on.

I'm wondering if that's the way it's supposed to work or if I've done something 
wrong with my Radiator config?


It's a Enterprise WPA2 setup.

Running Radiator version 4.15 on Linux.

The certificate is signed by COMODO and should be trusted by various browsers, 
phones, etc.

The certificate specific part of the radiator configuration is like this:

EAPTLS_CAPath %D/certificates/ca-certs
EAPTLS_CertificateChainFile %D/certificates/server-chain
EAPTLS_CertificateType PEM
EAPTLS_PrivateKeyFile %D/certificates/server-key

ca-certs only one file "AddTrustAB.pem" that has the CA Root certificate.
server-key is my private key.
server-chain first has my public key followed by two intermediate certs.


Does that sound about right, or have you got any recommendations?


Regards
Jesper Skou Jensen
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Radiator Version 4.15 released - security fixes and enhancements

[Heikki Vatiainen]

On 16.7.2015 18.10, Hartmaier Alexander wrote:
 On 2015-07-16 15:07, Heikki Vatiainen wrote:

 There's also an example of how to use a custom module, possibly modified
 from Radius/LogFormat.pm, to change the formatting or add new formats.
 I know because I was the one who requested the feature and wrote the Log
 module before you added the hook ;)

Yes, this was more for the other list members :)

 Yes I know. What I'd like to have is a way to *log* the actual chosen
 cipher per EAP-TLS connection, ideally in the AuthLog file.

That's probably fairly simple to log. Not sure how to get it authlog, 
though. I'll see what can be done for this and get back to you when I 
know more. Maybe the TLS version should be available too and visible in 
the debug logs.

Thanks for the suggestion.
Heikki

-- 
Heikki Vatiainen h...@open.com.au

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] Radiator Version 4.15 released - security fixes and enhancements

[Heikki Vatiainen]

On 16.7.2015 17.04, Nick Lowe wrote:

 In conjunction with https://tools.ietf.org/html/rfc7465 , it is
 probably time for RADIUS servers to comply with this by default unless
 explicitly configured otherwise:

Thanks for the RC4 reminder Nick.

This configuration is now possible with Radiator. It's hard to say how 
the EAP clients use crypto, so the default settings still allow RC4. 
However, the Radiator default settings do not allow export and weak 
ciphers, which are still part of the default ciphersuite set in many 
currently used OSes.

The configuration examples in goodies and reference manual have this as 
an example of cipher spec: DEFAULT:!EXPORT:!LOW:!RC4

I'd say this would comply with RFC 7465 requirements.

 o TLS servers MUST NOT select an RC4 cipher suite when a TLS client
 sends such a cipher suite in the ClientHello message.
   o If the TLS client only offers RC4 cipher suites, the TLS server
 MUST terminate the handshake.  The TLS server MAY send the
 insufficient_security fatal alert in this case.

There are also other sources with valuable information, one of which is 
Mozilla's guide:
https://wiki.mozilla.org/Security/Server_Side_TLS

The list members may want to take a look at this document if they plan 
to experiment with TLS versions and ciphersuites.

Thanks,
Heikki

-- 
Heikki Vatiainen h...@open.com.au

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] Radiator Version 4.15 released - security fixes and enhancements

[Hartmaier Alexander]

Hi Heikki,
that's a great release!

I couldn't find info about CEF and JSON logging in the reference manual,
should be included at least as keywords with a pointer to the
'logformat.cfg' goodies file although I'd prefer having it in the main docs.

Is there a way to log the used TLS version and cipher to find out which
ones are in use before restricting it with the new EAPTLS_Protocols and
EAPTLS_Ciphers config options?

Best regards, Alex

On 2015-07-15 14:40, Heikki Vatiainen wrote:
 We are pleased to announce the release of Radiator version 4.15

 This version contains fixes for an EAP-MSCHAP-V2 and EAP-pwd
 vulnerability. Upgrade is recommended. Please review OSC security
 advisory OSC-SEC-2015-01 for more information:
 https://www.open.com.au/OSC-SEC-2015-01.html

 As usual, the new version is available to current licensees from:
 https://www.open.com.au/radiator/downloads/

 and to current evaluators from:
 https://www.open.com.au/radiator/demo-downloads

 Licensees with expired access contracts can renew at:
 https://www.open.com.au/renewal.html

 An extract from the history file
 https://www.open.com.au/radiator/history.html is below:

 -

 Revision 4.15 (2015-07-15)

   Selected fixes, compatibility notes and enhancements

 Fixes an EAP-MSCHAP-V2 and EAP-pwd vulnerability.
 OSC recommends all users to review OSC security advisory
 OSC-SEC-2015-01 to see if they are affected.
 https://www.open.com.au/OSC-SEC-2015-01.html

 perl-ldap-0.32 or better is required. Should be available in all current
 systems.

 EAP-pwd requires Crypt::OpenSSL::Bignum 0.06 or later from CPAN

 Configurable TLS version and ciphersuite selection for TLS based EAP and
 stream modules

 CRL checks for the entire certificate chain can now be enabled

 Included Gossip framework with Redis based implementation

 Support for Gossip when communicating next hop proxy failures between
 Radiator instances

 Shared duplicate cache for a more simple server farm configuration

 Windows Event log support

 Custom format support for logs, authentication logs and accounting logs.
 CEF and JSON included

 Support for IEEE 802.1AE, also known as MACsec

 All AuthBys now support PostAuthHooks

 Various binary modules are now available from OSC and were removed from
 the Radiator distribution



   Detailed changes

 Added VENDOR STI (Server Technology Inc.) 1718 and multiple STI VSAs to
 dictionary. Contributed by Garry Shtern.

 Added VENDOR PacketDesign 8083 and VSAs PacketDesign-UserClass and
 PacketDesign-FTP to dictionary. Contributed by Garry Shtern.

 Added SN-Software-Version to dictionary. Reported by Bruno Tiago Rodrigues.

 Changed type of VENDORATTR 3076 Cisco-VPN-DHCP-Network-Scope in
 dictionary.cisco-vpn from text to ipaddr. Reported by Kilian Krause.

 Dictionary updates: Added H3C proprietary values H3C-SSH and H3C-Console
 for Login-Service. Changed Lancom LCS-Mac-Address type from string to
 hexadecimal. Added H3C-Priority. All reported by Philip Herbert.

 Zero length writes are now skipped in Stream.pm write_pending() used by
 RadSec, Diameter, SIGTRAN and other stream protocols. SCTP does not
 support 0 length syswrites on all platforms and may close the socket if
 zero length write is done.

 Added VENDOR Airespace 14179 VSAs 7-11 and 13-16 to dictionary.

 AuthBy GROUP now updates current AuthBy for %{AuthBy:parmname}. When
 AuthBy GROUP is used, this special formatting now gets the parameter
 value from the current AuthBy within the group instead of the AuthBy
 GROUP itself.

 Updated VENDOR 1991 Foundry VSAs in dictionary. foundry-privilege-level
 is now a synonym for brocade-privilege-level. Added a number of foundry
 VSAs.

 LDAP Version now defaults to 3 instead of 2. Updated a number of LDAP
 configuration example files in goodies to reflect this change.

 Ldap.pm now uses the LDAP object's disconnect method, instead of closing
 the socket directly.

 AuthBy LDAP2 and AuthBy LDAPDIGIPASS now use escape_filter_value
 provided by Net::LDAP::Util instead of escapeLdapLiteral in Ldap.pm
 Ldap.pm escapeLdapLiteral is now deprecacted and perl-ldap-0.32 or
 better is required.

 RefreshPeriod in ClientListSQL and ClientListLDAP now support special %
 formatting. Suggested by Bengi Sağlam.

 Updated VENDOR 2011 Huawei VSAs in dictionary. Huawei-Input-Basic-Rate
 is now an alias for Huawei-Input-Peak-Rate. Huawei-Output-Basic-Rate was
 changed similarly. Some of the attribute numbers appear to have
 different names and types between different devices. Huawei-User-Type,
 Huawei-MIP-Agent-MN-Flag and Huawei-Requested-APN are now aliases but
 aliasing may be handled with separate dictionary files in the future.
 Huawei-HW-Portal-Mode was renamed to Huawei-Portal-Mode.

 WiMAX dictionary updates: changed WiMAX-Session-Termination-Capability
 type to integer and added one value: Dynamic-Authorization. Changed
 WiMAX-PPAQ TLV Quota-Identifier type to binary. WiMAX subattributes
 within 

Re: [RADIATOR] Radiator Version 4.15 released - security fixes and enhancements

[Heikki Vatiainen]

On 16.7.2015 13.42, Hartmaier Alexander wrote:

 I couldn't find info about CEF and JSON logging in the reference manual,
 should be included at least as keywords with a pointer to the
 'logformat.cfg' goodies file although I'd prefer having it in the main docs.

Good point. I'll see that CEF and JSON will be mentioned in ref.pdf

The configuration sample file 'logformat.cfg' is mentioned where 
LogFormatHook for Log FILE and AuthLog FILE are described. It's also 
mentioned where AcctLogFileFormatHook for accounting messages is described.

The configuration sample shows how to use the new module 
Radius/LogFormat.pm. This module includes CEF and JSON authentication 
log formatting and JSON accounting log formatting.

There's also an example of how to use a custom module, possibly modified 
from Radius/LogFormat.pm, to change the formatting or add new formats.

 Is there a way to log the used TLS version and cipher to find out which
 ones are in use before restricting it with the new EAPTLS_Protocols and
 EAPTLS_Ciphers config options?

I think the ciphers are the ones that can be listed with 'openssl 
ciphers -v' these depend on the SSL/TLS library. Older OpenSSL versions 
seem to have quite different set of ciphers than the most recent 
LibreSSL for example.

In other words the ciphers could be listed by radiusd, but you can also 
see them from the command line. Also, new DEBUG level log message was 
added to show which Net::SSLeay version and SSL/TLS libary is used to 
make sure radiusd uses what you expect it to.

The protocols also depend on what's compiled in the SSL/TLS library. I 
think the recent LibreSSLs do not have SSLv3 support anymore. Are you 
thinking about printing the available SSL/TLS versions before 
restricting them? Note that for TLS based EAPs, TLSv1 is the minimum so 
SSLv3 is not possible which means what you can use is TLSv1 or better.

Thanks,
Heikki

-- 
Heikki Vatiainen h...@open.com.au

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] Radiator Version 4.15 released - security fixes and enhancements

[Nick Lowe]

RC4 is particularly broken now:

https://www.rc4nomore.com
https://www.rc4nomore.com/vanhoef-usenix2015.pdf

In conjunction with https://tools.ietf.org/html/rfc7465 , it is
probably time for RADIUS servers to comply with this by default unless
explicitly configured otherwise:

o TLS servers MUST NOT select an RC4 cipher suite when a TLS client
sends such a cipher suite in the ClientHello message.
 o If the TLS client only offers RC4 cipher suites, the TLS server
MUST terminate the handshake.  The TLS server MAY send the
insufficient_security fatal alert in this case.
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Radiator Version 4.15 released - security fixes and enhancements

[Hartmaier Alexander]

On 2015-07-16 15:07, Heikki Vatiainen wrote:
 On 16.7.2015 13.42, Hartmaier Alexander wrote:

 I couldn't find info about CEF and JSON logging in the reference manual,
 should be included at least as keywords with a pointer to the
 'logformat.cfg' goodies file although I'd prefer having it in the main docs.
 Good point. I'll see that CEF and JSON will be mentioned in ref.pdf

 The configuration sample file 'logformat.cfg' is mentioned where
 LogFormatHook for Log FILE and AuthLog FILE are described. It's also
 mentioned where AcctLogFileFormatHook for accounting messages is described.

 The configuration sample shows how to use the new module
 Radius/LogFormat.pm. This module includes CEF and JSON authentication
 log formatting and JSON accounting log formatting.

 There's also an example of how to use a custom module, possibly modified
 from Radius/LogFormat.pm, to change the formatting or add new formats.
I know because I was the one who requested the feature and wrote the Log
module before you added the hook ;)


 Is there a way to log the used TLS version and cipher to find out which
 ones are in use before restricting it with the new EAPTLS_Protocols and
 EAPTLS_Ciphers config options?
 I think the ciphers are the ones that can be listed with 'openssl
 ciphers -v' these depend on the SSL/TLS library. Older OpenSSL versions
 seem to have quite different set of ciphers than the most recent
 LibreSSL for example.

 In other words the ciphers could be listed by radiusd, but you can also
 see them from the command line. Also, new DEBUG level log message was
 added to show which Net::SSLeay version and SSL/TLS libary is used to
 make sure radiusd uses what you expect it to.

 The protocols also depend on what's compiled in the SSL/TLS library. I
 think the recent LibreSSLs do not have SSLv3 support anymore. Are you
 thinking about printing the available SSL/TLS versions before
 restricting them? Note that for TLS based EAPs, TLSv1 is the minimum so
 SSLv3 is not possible which means what you can use is TLSv1 or better.
Yes I know. What I'd like to have is a way to *log* the actual chosen
cipher per EAP-TLS connection, ideally in the AuthLog file.


 Thanks,
 Heikki

Cheers, Alex


***
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
***
Notice: This e-mail contains information that is confidential and may be 
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
***
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

[RADIATOR] Radiator Version 4.15 released - security fixes and enhancements

[Heikki Vatiainen]

We are pleased to announce the release of Radiator version 4.15

This version contains fixes for an EAP-MSCHAP-V2 and EAP-pwd
vulnerability. Upgrade is recommended. Please review OSC security
advisory OSC-SEC-2015-01 for more information:
https://www.open.com.au/OSC-SEC-2015-01.html

As usual, the new version is available to current licensees from:
https://www.open.com.au/radiator/downloads/

and to current evaluators from:
https://www.open.com.au/radiator/demo-downloads

Licensees with expired access contracts can renew at:
https://www.open.com.au/renewal.html

An extract from the history file
https://www.open.com.au/radiator/history.html is below:

-

Revision 4.15 (2015-07-15)

 Selected fixes, compatibility notes and enhancements

Fixes an EAP-MSCHAP-V2 and EAP-pwd vulnerability.
OSC recommends all users to review OSC security advisory
OSC-SEC-2015-01 to see if they are affected.
https://www.open.com.au/OSC-SEC-2015-01.html

perl-ldap-0.32 or better is required. Should be available in all current
systems.

EAP-pwd requires Crypt::OpenSSL::Bignum 0.06 or later from CPAN

Configurable TLS version and ciphersuite selection for TLS based EAP and
stream modules

CRL checks for the entire certificate chain can now be enabled

Included Gossip framework with Redis based implementation

Support for Gossip when communicating next hop proxy failures between
Radiator instances

Shared duplicate cache for a more simple server farm configuration

Windows Event log support

Custom format support for logs, authentication logs and accounting logs.
CEF and JSON included

Support for IEEE 802.1AE, also known as MACsec

All AuthBys now support PostAuthHooks

Various binary modules are now available from OSC and were removed from
the Radiator distribution



 Detailed changes

Added VENDOR STI (Server Technology Inc.) 1718 and multiple STI VSAs to
dictionary. Contributed by Garry Shtern.

Added VENDOR PacketDesign 8083 and VSAs PacketDesign-UserClass and
PacketDesign-FTP to dictionary. Contributed by Garry Shtern.

Added SN-Software-Version to dictionary. Reported by Bruno Tiago Rodrigues.

Changed type of VENDORATTR 3076 Cisco-VPN-DHCP-Network-Scope in
dictionary.cisco-vpn from text to ipaddr. Reported by Kilian Krause.

Dictionary updates: Added H3C proprietary values H3C-SSH and H3C-Console
for Login-Service. Changed Lancom LCS-Mac-Address type from string to
hexadecimal. Added H3C-Priority. All reported by Philip Herbert.

Zero length writes are now skipped in Stream.pm write_pending() used by
RadSec, Diameter, SIGTRAN and other stream protocols. SCTP does not
support 0 length syswrites on all platforms and may close the socket if
zero length write is done.

Added VENDOR Airespace 14179 VSAs 7-11 and 13-16 to dictionary.

AuthBy GROUP now updates current AuthBy for %{AuthBy:parmname}. When
AuthBy GROUP is used, this special formatting now gets the parameter
value from the current AuthBy within the group instead of the AuthBy
GROUP itself.

Updated VENDOR 1991 Foundry VSAs in dictionary. foundry-privilege-level
is now a synonym for brocade-privilege-level. Added a number of foundry
VSAs.

LDAP Version now defaults to 3 instead of 2. Updated a number of LDAP
configuration example files in goodies to reflect this change.

Ldap.pm now uses the LDAP object's disconnect method, instead of closing
the socket directly.

AuthBy LDAP2 and AuthBy LDAPDIGIPASS now use escape_filter_value
provided by Net::LDAP::Util instead of escapeLdapLiteral in Ldap.pm
Ldap.pm escapeLdapLiteral is now deprecacted and perl-ldap-0.32 or
better is required.

RefreshPeriod in ClientListSQL and ClientListLDAP now support special %
formatting. Suggested by Bengi Sağlam.

Updated VENDOR 2011 Huawei VSAs in dictionary. Huawei-Input-Basic-Rate
is now an alias for Huawei-Input-Peak-Rate. Huawei-Output-Basic-Rate was
changed similarly. Some of the attribute numbers appear to have
different names and types between different devices. Huawei-User-Type,
Huawei-MIP-Agent-MN-Flag and Huawei-Requested-APN are now aliases but
aliasing may be handled with separate dictionary files in the future.
Huawei-HW-Portal-Mode was renamed to Huawei-Portal-Mode.

WiMAX dictionary updates: changed WiMAX-Session-Termination-Capability
type to integer and added one value: Dynamic-Authorization. Changed
WiMAX-PPAQ TLV Quota-Identifier type to binary. WiMAX subattributes
within single Vendor-Specific attribute are now correctly decoded.

Dictionary updates for Huawei: Reverted the recent aliasing changes. The
conflicting attributes are now in a new Huawei specific dictionary file
goodies/dictionary.huawei1. This new dictionary file contains attributes
used by, for example, Huawei packet gateway / Wi-Fi controller. Since
Huawei seems to use device specific dictionaries, additional dictionary
files are added as needed.

Added new AuthLog EVENTLOG and Log EVENTLOG modules for logging to
Windows Event Log. Added eventlog.cfg in goodies for 

Re: [RADIATOR] [Radiator] Error connecting to readonly RADMIN Mysql DB

[Heikki Vatiainen]

On 03/19/2015 02:49 PM, Heikki Vatiainen wrote:
 On 03/19/2015 12:18 PM, Laurent Duru wrote:
 
 Thu Mar 19 11:11:11 2015: ERR: Execute failed for 'select PASS_WORD,
 STATICADDRESS, TIMELEFT, MAXLOGINS, SERVICENAME, BADLOGINS, VALIDFROM,
 VALIDTO from RADUSERS where USERNAME=‘X'': Can't call method
 prepare on an undefined value at /usr/lib/perl5/Radius/SqlDb.pm line 287.
 
 I have not seen this before. Can you reply with your configuration. I'd
 like to see what kind of configuration triggers this problem.
 
 I'd say using read-only database should work. The configuration would
 also help understanding what your requirements are.

This problem was solved off-list, but I thought I'd summarise the cause
and fix.

The AuthBy RADMIN default LogQuery was still trying to write to the
read-only SQL DB. Since the writer was a logger, the SQL error that
occurred during logging was not passed to the logger anymore. This is to
stop the log messages caused by logging from creating infinite log loops.

When LogQuery is configured with empty value, the query is skipped.

We are considering options, such as logging to stderr, to help debugging
these kinds of cases with logs.

Thanks,
Heikki

-- 
Heikki Vatiainen h...@open.com.au

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

[RADIATOR] [Radiator] Error connecting to readonly RADMIN Mysql DB

[Laurent Duru]

Hello,

My configuration as is :

Blue server : Radiator + Radmin + Mysql Master
Red Server : Mysql Slave

There is a Master-Slave Replication between blue and red, I need to avoid 
Radiator writes on Red.

In my Radiator config I use a Read/Write account to connect to Blue and a Read 
Only account to connect to red.

When Blue Mysql is down, requests failover to Red server but I get this error 
message :


Thu Mar 19 11:11:11 2015: ERR: Execute failed for 'select PASS_WORD, 
STATICADDRESS, TIMELEFT, MAXLOGINS, SERVICENAME, BADLOGINS, VALIDFROM, VALIDTO 
from RADUSERS where USERNAME=‘X'': Can't call method prepare on an 
undefined value at /usr/lib/perl5/Radius/SqlDb.pm line 287.

When I use Read/Write account for Red there is no error …

Is this configuration feasable ?
Have you encountered this error ?

Thanks a lot for your help,

Laurent
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] [Radiator] Error connecting to readonly RADMIN Mysql DB

[Heikki Vatiainen]

On 03/19/2015 12:18 PM, Laurent Duru wrote:

 Thu Mar 19 11:11:11 2015: ERR: Execute failed for 'select PASS_WORD,
 STATICADDRESS, TIMELEFT, MAXLOGINS, SERVICENAME, BADLOGINS, VALIDFROM,
 VALIDTO from RADUSERS where USERNAME=‘X'': Can't call method
 prepare on an undefined value at /usr/lib/perl5/Radius/SqlDb.pm line 287.

I have not seen this before. Can you reply with your configuration. I'd
like to see what kind of configuration triggers this problem.

I'd say using read-only database should work. The configuration would
also help understanding what your requirements are.

Thanks,
Heikki

-- 
Heikki Vatiainen h...@open.com.au

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

[RADIATOR] Radiator Load Balancing

[Ullfig, Roberto Alfredo]

Hello,

Right now we are using Radiator's own load balancer. Would using an F5 Load 
Balancer to load balance make any sense and would it work? Their product is 
here:

https://f5.com

We use it for other services but they are all tcp based. Thanks!

---
Roberto Ullfig - rull...@uic.edu
ACCC Research Programmer

___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Radiator+Mikrotik

[sergio]

hello

It is possible to create a package for the Mikrotik? MikrotikSessionMIB.pm


 -Original Message-
 From: nath...@fsr.com
 Sent: Mon, 8 Dec 2014 05:30:26 -0800
 To: m.abdelsa...@wimd.com.kw, radiator@open.com.au
 Subject: Re: [RADIATOR] Radiator+Mikrotik
 
 On Monday, December 08, 2014 12:16 AM, Mahmoud Abdelsalam wrote:
 
 Hello all,
 
 As Mikrotik doesn't support COA for PPPoE, so I used Disconnect-Request,
 the hook script will send Disconnect-Request to Mikrotik once the
 session
 exceeds the quota, here is how i send Disconnect-Request:
 
 [snip]
 
 This works fine but the problem is that user can't re-authenticate again
 because it reaches Maxsessions although I have this in my config file:
 
 [snip]
 
 The user would successfully authenticate again when I manually remove
 the
 session from RADONLINE by executing the DeleteQuery.
 
 It has been a while since I have had to look at/think about this, but as
 I recall, this is how it works:
 
 DeleteQuery doesn't get executed unless the Radiator server receives
 Accounting-Stop from the MikroTik.
 
 PoD/Disconnect-Request may or may not cause Accounting-Stop to be issued
 by MikroTik RouterOS; I can't remember and I will have to simulate this
 later and run a packet capture to see what happens.  (Maybe if you are
 running an older version of RouterOS, try upgrading?  It could be a bug
 that got fixed later, and they have definitely had their share of RADIUS
 client bugs in the past.)
 
 In any case, you can work around a problem where Radiator does not
 receive Accounting-Stop by having Radiator verify that any active
 sessions for the user that are recorded in the RADONLINE table are valid
 at the moment that the user tries to authenticate again.  Radiator does
 this by executing an SNMP query to the NAS that is on record for each
 session to see if the Session-ID for that row in the table is still
 valid.  If the NAS does not return anything for the OID, then Radiator
 assumes the session is dead and purges that entry from RADONLINE,
 reducing MaxSessions count by 1.
 
 To enable this functionality, you need to make sure that SNMP is enabled
 and configured on each MikroTik NAS, you need to make sure that Net-SNMP
 is installed and configured on the Radiator server, and you need to add
 these options to your Client clause in your Radiator config file:
 
 Client DEFAULT
 [...]
 # MikroTik supports this MIB
 NasType CiscoSessionMIB
 SNMPCommunity public
 /Client
 
 Replace 'public' with the SNMP community string that you have configured
 on the MikroTik.
 
 We also made a slight change to the Radiator code, because by default, if
 Radiator does not get a response back from its SNMP get to the
 MikroTik, it gives the benefit of the doubt to RADONLINE.  We have found
 that more often than not, it is better to give the benefit of the doubt
 to the user.  That way, a user is not unfairly punished by problems with
 our NAS or problems on our network that might make it impossible for
 Radiator to communicate with our NAS.  Here is the patch to make that
 change in behavior:
 
 diff -r -d -u -N Radius/Nas/CiscoSessionMIB.pm
 Radius-patched/Nas/CiscoSessionMIB.pm
 --- Radius/Nas/CiscoSessionMIB.pm 2009-10-26 15:23:55.0 -0700
 +++ Radius-patched/Nas/CiscoSessionMIB.pm 2014-12-08 05:20:02.0
 -0800
 @@ -39,7 +39,7 @@
$client-{SNMPCommunity},
$Radius::Nas::CiscoMIB.9.150.1.1.3.1.2.$session_id);
 
 -return 1 if (!$result || $result =~ /no response/i); # Could not
 SNMP. Assume still there
 +return 0 if (!$result || $result =~ /no response/i); # Could not
 SNMP. Give benefit of doubt to user.
  return 0 if $result =~ /no such variable/i;  # Not in the MIB means
 no such session
  return uc($1) eq uc($name)
   if ($result =~ /^.*\([^]+).*$/);
 
 Hope this helps,
 
 --
 Nathan Anderson
 First Step Internet, LLC
 nath...@fsr.com
 ___
 radiator mailing list
 radiator@open.com.au
 http://www.open.com.au/mailman/listinfo/radiator


Can't remember your password? Do you need a strong and secure password?
Use Password manager! It stores your passwords  protects your account.
Check it out at http://mysecurelogon.com/password-manager


___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Radiator+Mikrotik

[Nathan Anderson]

I'm not sure that I see what the point of that would be. RouterOS uses the same 
MIB as Cisco does, so having to keep 2 nearly-identical modules in sync with 
each other would be silly.

To be clear, the modification I made to the CiscoSessionMIB wasn't for the sake 
of compatibility with RouterOS. It was to change Radiator's behavior in the 
event that it got no SNMP response from the NAS. This modification would be 
equally valuable to someone using a Cisco NAS who wanted the same behavior. If 
anything, it would be nice to have this as a configurable option in Radiator.

--
Nathan Anderson
First Step Internet, LLC
nath...@fsr.com


sergio ser...@inbox.com wrote:


hello

It is possible to create a package for the Mikrotik? MikrotikSessionMIB.pm


 -Original Message-
 From: nath...@fsr.com
 Sent: Mon, 8 Dec 2014 05:30:26 -0800
 To: m.abdelsa...@wimd.com.kw, radiator@open.com.au
 Subject: Re: [RADIATOR] Radiator+Mikrotik

 On Monday, December 08, 2014 12:16 AM, Mahmoud Abdelsalam wrote:

 Hello all,

 As Mikrotik doesn't support COA for PPPoE, so I used Disconnect-Request,
 the hook script will send Disconnect-Request to Mikrotik once the
 session
 exceeds the quota, here is how i send Disconnect-Request:

 [snip]

 This works fine but the problem is that user can't re-authenticate again
 because it reaches Maxsessions although I have this in my config file:

 [snip]

 The user would successfully authenticate again when I manually remove
 the
 session from RADONLINE by executing the DeleteQuery.

 It has been a while since I have had to look at/think about this, but as
 I recall, this is how it works:

 DeleteQuery doesn't get executed unless the Radiator server receives
 Accounting-Stop from the MikroTik.

 PoD/Disconnect-Request may or may not cause Accounting-Stop to be issued
 by MikroTik RouterOS; I can't remember and I will have to simulate this
 later and run a packet capture to see what happens.  (Maybe if you are
 running an older version of RouterOS, try upgrading?  It could be a bug
 that got fixed later, and they have definitely had their share of RADIUS
 client bugs in the past.)

 In any case, you can work around a problem where Radiator does not
 receive Accounting-Stop by having Radiator verify that any active
 sessions for the user that are recorded in the RADONLINE table are valid
 at the moment that the user tries to authenticate again.  Radiator does
 this by executing an SNMP query to the NAS that is on record for each
 session to see if the Session-ID for that row in the table is still
 valid.  If the NAS does not return anything for the OID, then Radiator
 assumes the session is dead and purges that entry from RADONLINE,
 reducing MaxSessions count by 1.

 To enable this functionality, you need to make sure that SNMP is enabled
 and configured on each MikroTik NAS, you need to make sure that Net-SNMP
 is installed and configured on the Radiator server, and you need to add
 these options to your Client clause in your Radiator config file:

 Client DEFAULT
 [...]
 # MikroTik supports this MIB
 NasType CiscoSessionMIB
 SNMPCommunity public
 /Client

 Replace 'public' with the SNMP community string that you have configured
 on the MikroTik.

 We also made a slight change to the Radiator code, because by default, if
 Radiator does not get a response back from its SNMP get to the
 MikroTik, it gives the benefit of the doubt to RADONLINE.  We have found
 that more often than not, it is better to give the benefit of the doubt
 to the user.  That way, a user is not unfairly punished by problems with
 our NAS or problems on our network that might make it impossible for
 Radiator to communicate with our NAS.  Here is the patch to make that
 change in behavior:

 diff -r -d -u -N Radius/Nas/CiscoSessionMIB.pm
 Radius-patched/Nas/CiscoSessionMIB.pm
 --- Radius/Nas/CiscoSessionMIB.pm 2009-10-26 15:23:55.0 -0700
 +++ Radius-patched/Nas/CiscoSessionMIB.pm 2014-12-08 05:20:02.0
 -0800
 @@ -39,7 +39,7 @@
$client-{SNMPCommunity},
$Radius::Nas::CiscoMIB.9.150.1.1.3.1.2.$session_id);

 -return 1 if (!$result || $result =~ /no response/i); # Could not
 SNMP. Assume still there
 +return 0 if (!$result || $result =~ /no response/i); # Could not
 SNMP. Give benefit of doubt to user.
  return 0 if $result =~ /no such variable/i;  # Not in the MIB means
 no such session
  return uc($1) eq uc($name)
   if ($result =~ /^.*\([^]+).*$/);

 Hope this helps,

 --
 Nathan Anderson
 First Step Internet, LLC
 nath...@fsr.com
 ___
 radiator mailing list
 radiator@open.com.au
 http://www.open.com.au/mailman/listinfo/radiator


Can't remember your password? Do you need a strong and secure password?
Use Password manager! It stores your passwords  protects your account.
Check it out at http://mysecurelogon.com/password

Re: [RADIATOR] Radiator+Mikrotik

[Hugh Irvine]

Hello Sergio -

Yes - have a look at the current packages in the “Radius/Nas/…” directory of 
the Radiator-4.14 distribution.

regards

Hugh


 On 23 Jan 2015, at 13:41, sergio ser...@inbox.com wrote:
 
 hello
 
 It is possible to create a package for the Mikrotik? MikrotikSessionMIB.pm
 
 
 -Original Message-
 From: nath...@fsr.com
 Sent: Mon, 8 Dec 2014 05:30:26 -0800
 To: m.abdelsa...@wimd.com.kw, radiator@open.com.au
 Subject: Re: [RADIATOR] Radiator+Mikrotik
 
 On Monday, December 08, 2014 12:16 AM, Mahmoud Abdelsalam wrote:
 
 Hello all,
 
 As Mikrotik doesn't support COA for PPPoE, so I used Disconnect-Request,
 the hook script will send Disconnect-Request to Mikrotik once the
 session
 exceeds the quota, here is how i send Disconnect-Request:
 
 [snip]
 
 This works fine but the problem is that user can't re-authenticate again
 because it reaches Maxsessions although I have this in my config file:
 
 [snip]
 
 The user would successfully authenticate again when I manually remove
 the
 session from RADONLINE by executing the DeleteQuery.
 
 It has been a while since I have had to look at/think about this, but as
 I recall, this is how it works:
 
 DeleteQuery doesn't get executed unless the Radiator server receives
 Accounting-Stop from the MikroTik.
 
 PoD/Disconnect-Request may or may not cause Accounting-Stop to be issued
 by MikroTik RouterOS; I can't remember and I will have to simulate this
 later and run a packet capture to see what happens.  (Maybe if you are
 running an older version of RouterOS, try upgrading?  It could be a bug
 that got fixed later, and they have definitely had their share of RADIUS
 client bugs in the past.)
 
 In any case, you can work around a problem where Radiator does not
 receive Accounting-Stop by having Radiator verify that any active
 sessions for the user that are recorded in the RADONLINE table are valid
 at the moment that the user tries to authenticate again.  Radiator does
 this by executing an SNMP query to the NAS that is on record for each
 session to see if the Session-ID for that row in the table is still
 valid.  If the NAS does not return anything for the OID, then Radiator
 assumes the session is dead and purges that entry from RADONLINE,
 reducing MaxSessions count by 1.
 
 To enable this functionality, you need to make sure that SNMP is enabled
 and configured on each MikroTik NAS, you need to make sure that Net-SNMP
 is installed and configured on the Radiator server, and you need to add
 these options to your Client clause in your Radiator config file:
 
 Client DEFAULT
[...]
# MikroTik supports this MIB
NasType CiscoSessionMIB
SNMPCommunity public
 /Client
 
 Replace 'public' with the SNMP community string that you have configured
 on the MikroTik.
 
 We also made a slight change to the Radiator code, because by default, if
 Radiator does not get a response back from its SNMP get to the
 MikroTik, it gives the benefit of the doubt to RADONLINE.  We have found
 that more often than not, it is better to give the benefit of the doubt
 to the user.  That way, a user is not unfairly punished by problems with
 our NAS or problems on our network that might make it impossible for
 Radiator to communicate with our NAS.  Here is the patch to make that
 change in behavior:
 
 diff -r -d -u -N Radius/Nas/CiscoSessionMIB.pm
 Radius-patched/Nas/CiscoSessionMIB.pm
 --- Radius/Nas/CiscoSessionMIB.pm2009-10-26 15:23:55.0 -0700
 +++ Radius-patched/Nas/CiscoSessionMIB.pm2014-12-08 05:20:02.0
 -0800
 @@ -39,7 +39,7 @@
   $client-{SNMPCommunity},
   $Radius::Nas::CiscoMIB.9.150.1.1.3.1.2.$session_id);
 
 -return 1 if (!$result || $result =~ /no response/i); # Could not
 SNMP. Assume still there
 +return 0 if (!$result || $result =~ /no response/i); # Could not
 SNMP. Give benefit of doubt to user.
 return 0 if $result =~ /no such variable/i;  # Not in the MIB means
 no such session
 return uc($1) eq uc($name)
  if ($result =~ /^.*\([^]+).*$/);
 
 Hope this helps,
 
 --
 Nathan Anderson
 First Step Internet, LLC
 nath...@fsr.com
 ___
 radiator mailing list
 radiator@open.com.au
 http://www.open.com.au/mailman/listinfo/radiator
 
 
 Can't remember your password? Do you need a strong and secure password?
 Use Password manager! It stores your passwords  protects your account.
 Check it out at http://mysecurelogon.com/password-manager
 
 
 ___
 radiator mailing list
 radiator@open.com.au
 http://www.open.com.au/mailman/listinfo/radiator


--

Hugh Irvine
h...@open.com.au

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

Re: [RADIATOR] Radiator+Mikrotik

[Nathan Anderson]

Well! I stand corrected.

-- Nathan

Hugh Irvine h...@open.com.au wrote:


Hello Sergio -

Yes - have a look at the current packages in the “Radius/Nas/…” directory of 
the Radiator-4.14 distribution.

regards

Hugh


 On 23 Jan 2015, at 13:41, sergio ser...@inbox.com wrote:

 hello

 It is possible to create a package for the Mikrotik? MikrotikSessionMIB.pm


 -Original Message-
 From: nath...@fsr.com
 Sent: Mon, 8 Dec 2014 05:30:26 -0800
 To: m.abdelsa...@wimd.com.kw, radiator@open.com.au
 Subject: Re: [RADIATOR] Radiator+Mikrotik

 On Monday, December 08, 2014 12:16 AM, Mahmoud Abdelsalam wrote:

 Hello all,

 As Mikrotik doesn't support COA for PPPoE, so I used Disconnect-Request,
 the hook script will send Disconnect-Request to Mikrotik once the
 session
 exceeds the quota, here is how i send Disconnect-Request:

 [snip]

 This works fine but the problem is that user can't re-authenticate again
 because it reaches Maxsessions although I have this in my config file:

 [snip]

 The user would successfully authenticate again when I manually remove
 the
 session from RADONLINE by executing the DeleteQuery.

 It has been a while since I have had to look at/think about this, but as
 I recall, this is how it works:

 DeleteQuery doesn't get executed unless the Radiator server receives
 Accounting-Stop from the MikroTik.

 PoD/Disconnect-Request may or may not cause Accounting-Stop to be issued
 by MikroTik RouterOS; I can't remember and I will have to simulate this
 later and run a packet capture to see what happens.  (Maybe if you are
 running an older version of RouterOS, try upgrading?  It could be a bug
 that got fixed later, and they have definitely had their share of RADIUS
 client bugs in the past.)

 In any case, you can work around a problem where Radiator does not
 receive Accounting-Stop by having Radiator verify that any active
 sessions for the user that are recorded in the RADONLINE table are valid
 at the moment that the user tries to authenticate again.  Radiator does
 this by executing an SNMP query to the NAS that is on record for each
 session to see if the Session-ID for that row in the table is still
 valid.  If the NAS does not return anything for the OID, then Radiator
 assumes the session is dead and purges that entry from RADONLINE,
 reducing MaxSessions count by 1.

 To enable this functionality, you need to make sure that SNMP is enabled
 and configured on each MikroTik NAS, you need to make sure that Net-SNMP
 is installed and configured on the Radiator server, and you need to add
 these options to your Client clause in your Radiator config file:

 Client DEFAULT
[...]
# MikroTik supports this MIB
NasType CiscoSessionMIB
SNMPCommunity public
 /Client

 Replace 'public' with the SNMP community string that you have configured
 on the MikroTik.

 We also made a slight change to the Radiator code, because by default, if
 Radiator does not get a response back from its SNMP get to the
 MikroTik, it gives the benefit of the doubt to RADONLINE.  We have found
 that more often than not, it is better to give the benefit of the doubt
 to the user.  That way, a user is not unfairly punished by problems with
 our NAS or problems on our network that might make it impossible for
 Radiator to communicate with our NAS.  Here is the patch to make that
 change in behavior:

 diff -r -d -u -N Radius/Nas/CiscoSessionMIB.pm
 Radius-patched/Nas/CiscoSessionMIB.pm
 --- Radius/Nas/CiscoSessionMIB.pm2009-10-26 15:23:55.0 -0700
 +++ Radius-patched/Nas/CiscoSessionMIB.pm2014-12-08 05:20:02.0
 -0800
 @@ -39,7 +39,7 @@
   $client-{SNMPCommunity},
   $Radius::Nas::CiscoMIB.9.150.1.1.3.1.2.$session_id);

 -return 1 if (!$result || $result =~ /no response/i); # Could not
 SNMP. Assume still there
 +return 0 if (!$result || $result =~ /no response/i); # Could not
 SNMP. Give benefit of doubt to user.
 return 0 if $result =~ /no such variable/i;  # Not in the MIB means
 no such session
 return uc($1) eq uc($name)
  if ($result =~ /^.*\([^]+).*$/);

 Hope this helps,

 --
 Nathan Anderson
 First Step Internet, LLC
 nath...@fsr.com
 ___
 radiator mailing list
 radiator@open.com.au
 http://www.open.com.au/mailman/listinfo/radiator

 
 Can't remember your password? Do you need a strong and secure password?
 Use Password manager! It stores your passwords  protects your account.
 Check it out at http://mysecurelogon.com/password-manager


 ___
 radiator mailing list
 radiator@open.com.au
 http://www.open.com.au/mailman/listinfo/radiator


--

Hugh Irvine
h...@open.com.au

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

Re: [RADIATOR] Radiator does not allow LEFT OUTER JOIN in SQL statement? - Solved - config typo

[karel.vandervelden]

Sorry,

Just a typo in the radius config file... Sorry to cause this trouble

Met vriendelijke groeten/With kind regards,
   Karel van der Velden

[KPN-logo]
Ananke
Goddess of necessity, inevitability and compulsion
Godin van de noodzakelijkheid, onvermijdelijkheid en dwangmatigheid
NETCO FO NSD Service Development
Reitemakersrijge 13
9711 HT Groningen
Vast: 050 - 5881003
Fax: 050 - 3186347

This message is for the designated recipient only and may contain privileged, 
proprietary, or otherwise private information. If you have received it in 
error, please notify the sender immediately and delete the original. Any other 
use of the email by you is prohibited

Van: Velden, Karel van der
Verzonden: vrijdag 23 januari 2015 8:05
Aan: 'radiator@open.com.au'
Onderwerp: Radiator does not allow LEFT OUTER JOIN in SQL statement?

Hello,

Today I tried to do an AuthSelect statement including a 'LEFT OUTER JOIN' but 
it failed with the error message:
ERR: Unknown keyword 'LEFT' in 

The sql statement works perfectly in a db environment. Why doesn't radiator 
accept it?

With kind regards,
   Karel van der Velden

NETCO FO NSD Service Development

This message is for the designated recipient only and may contain privileged, 
proprietary, or otherwise private information. If you have received it in 
error, please notify the sender immediately and delete the original. Any other 
use of the email by you is prohibited

___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Radiator Authorization Cisco ASA

[Hartmaier Alexander]

You need to specify the cmd-arg multiple times, one for each space
separated argument:

authorizedgroup readonly group deny service=shell cmd=changeto 
cmd-arg=context cmd-arg=system
authorizedgroup readonly group permit service=shell cmd=changeto 
cmd-arg=context cmd-arg=other context name
authorizedgroup readonly group deny .*

BR Alex

On 2015-01-05 15:25, Heikki Vatiainen wrote:
 On 5.1.2015 15.34, Steve Normoyle wrote:

 I have a Cisco ASA with multiple context.  I am trying to deny the use
 of the command changeto context system, but allow authorized group to
 be able to change to any of the other context.  When user types in the
 command they get denied.
 Hello Steve,

 does it work if you reorder the first two lines? That is, deny the more
 specific first and allow the less specific then.

 If this does not help, please reply with more debug logs that shows the
 authorization request from ASA with the processing Radiator does.

 I have entered
 authorizedgroup readonly group permit service=shell cmd=changeto
 cmd-arg=context other context name
 authorizedgroup readonly group deny service=shell cmd=changeto
 cmd-arg=context system
 authorizedgroup readonly group deny .*
 Just to make sure: the configuration parameter is AuthorizeGroup (no d
 and with capital A and G). There should especially be no d.

 Thanks,
 Heikki




***
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
***
Notice: This e-mail contains information that is confidential and may be 
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
***
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

[RADIATOR] Radiator Authorization Cisco ASA

[Steve Normoyle]

I have a Cisco ASA with multiple context.  I am trying to deny the use of the 
command changeto context system, but allow authorized group to be able to 
change to any of the other context.  When user types in the command they get 
denied.

I have entered
authorizedgroup readonly group permit service=shell cmd=changeto 
cmd-arg=context other context name
authorizedgroup readonly group deny service=shell cmd=changeto 
cmd-arg=context system
authorizedgroup readonly group deny .*

  ___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Radiator Authorization Cisco ASA

[Heikki Vatiainen]

On 5.1.2015 15.34, Steve Normoyle wrote:

 I have a Cisco ASA with multiple context.  I am trying to deny the use
 of the command changeto context system, but allow authorized group to
 be able to change to any of the other context.  When user types in the
 command they get denied.

Hello Steve,

does it work if you reorder the first two lines? That is, deny the more 
specific first and allow the less specific then.

If this does not help, please reply with more debug logs that shows the 
authorization request from ASA with the processing Radiator does.

 I have entered
 authorizedgroup readonly group permit service=shell cmd=changeto
 cmd-arg=context other context name
 authorizedgroup readonly group deny service=shell cmd=changeto
 cmd-arg=context system
 authorizedgroup readonly group deny .*

Just to make sure: the configuration parameter is AuthorizeGroup (no d 
and with capital A and G). There should especially be no d.

Thanks,
Heikki

-- 
Heikki Vatiainen h...@open.com.au

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

[RADIATOR] Radiator+Mikrotik

[Mahmoud Abdelsalam]

Hello all,

As Mikrotik doesn't support COA for PPPoE, so I used Disconnect-Request, the 
hook script will send Disconnect-Request to Mikrotik once the session exceeds 
the quota, here is how i send Disconnect-Request:

  my @coa_attrs = (User-Name=$user_name, Acct-Session-Id=$sess_id, 
Framed-IP-Address=$framed_ipaddress);
my @cmd_args = (-noacct, -noauth, -time,-code, 
Disconnect-Request);
   push @cmd_args, (-trace, 4, -bind_address, 0.0.0.0, 
-auth_port, 3799, -secret, bla, -s, 10.11.11.2);
   my @cmd = (radpwtst);
   system (@cmd, @cmd_args, @coa_attrs);

This works fine but the problem is that user can't re-authenticate again 
because it reaches Maxsessions although I have this in my config file:

SessionDatabase SQL

Identifier  tamesql
DBSourcedbi:ODBC:IRONMAN
DBUsername  user
DBAuth  pass

 AddQueryinsert into RADONLINE \


 (USERNAME, NASIDENTIFIER, NASPORT, ACCTSESSIONID, TIME_STAMP, 
FRAMEDIPADDRESS, NASPORTTYPE, SERVICETYPE) \
 values \
 ('%n', '%N', %{NAS-Port}, '%{Acct-Session-Id}', %{Timestamp}, 
'%{Framed-IP-Address}', '%{NAS-Port-Type}', '%{Service-Type}')

 DeleteQuery delete from RADONLINE where USERNAME='%n' and 
NASIDENTIFIER='%N' and NASPORT=%{NAS-Port}

 ClearNasQuery   delete from RADONLINE where NASIDENTIFIER='%N'

 CountQuery  select NASIDENTIFIER, NASPORT, ACCTSESSIONID, 
FRAMEDIPADDRESS from RADONLINE where USERNAME='%n'

/SessionDatabase
   

The user would successfully authenticate again when I manually remove the 
session from RADONLINE by executing the DeleteQuery.

Best Regards,

Mahmoud Abdelsalam.

___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Radiator+Mikrotik

[Nathan Anderson]

On Monday, December 08, 2014 12:16 AM, Mahmoud Abdelsalam wrote:

 Hello all,
 
 As Mikrotik doesn't support COA for PPPoE, so I used Disconnect-Request,
 the hook script will send Disconnect-Request to Mikrotik once the session
 exceeds the quota, here is how i send Disconnect-Request:  

[snip]

 This works fine but the problem is that user can't re-authenticate again
 because it reaches Maxsessions although I have this in my config file: 

[snip]

 The user would successfully authenticate again when I manually remove the
 session from RADONLINE by executing the DeleteQuery. 

It has been a while since I have had to look at/think about this, but as I 
recall, this is how it works:

DeleteQuery doesn't get executed unless the Radiator server receives 
Accounting-Stop from the MikroTik.

PoD/Disconnect-Request may or may not cause Accounting-Stop to be issued by 
MikroTik RouterOS; I can't remember and I will have to simulate this later and 
run a packet capture to see what happens.  (Maybe if you are running an older 
version of RouterOS, try upgrading?  It could be a bug that got fixed later, 
and they have definitely had their share of RADIUS client bugs in the past.)

In any case, you can work around a problem where Radiator does not receive 
Accounting-Stop by having Radiator verify that any active sessions for the user 
that are recorded in the RADONLINE table are valid at the moment that the user 
tries to authenticate again.  Radiator does this by executing an SNMP query to 
the NAS that is on record for each session to see if the Session-ID for that 
row in the table is still valid.  If the NAS does not return anything for the 
OID, then Radiator assumes the session is dead and purges that entry from 
RADONLINE, reducing MaxSessions count by 1.

To enable this functionality, you need to make sure that SNMP is enabled and 
configured on each MikroTik NAS, you need to make sure that Net-SNMP is 
installed and configured on the Radiator server, and you need to add these 
options to your Client clause in your Radiator config file:

Client DEFAULT
[...]
# MikroTik supports this MIB
NasType CiscoSessionMIB
SNMPCommunity public
/Client

Replace 'public' with the SNMP community string that you have configured on the 
MikroTik.

We also made a slight change to the Radiator code, because by default, if 
Radiator does not get a response back from its SNMP get to the MikroTik, it 
gives the benefit of the doubt to RADONLINE.  We have found that more often 
than not, it is better to give the benefit of the doubt to the user.  That way, 
a user is not unfairly punished by problems with our NAS or problems on our 
network that might make it impossible for Radiator to communicate with our NAS. 
 Here is the patch to make that change in behavior:

diff -r -d -u -N Radius/Nas/CiscoSessionMIB.pm 
Radius-patched/Nas/CiscoSessionMIB.pm
--- Radius/Nas/CiscoSessionMIB.pm   2009-10-26 15:23:55.0 -0700
+++ Radius-patched/Nas/CiscoSessionMIB.pm   2014-12-08 05:20:02.0 
-0800
@@ -39,7 +39,7 @@
 $client-{SNMPCommunity},
 $Radius::Nas::CiscoMIB.9.150.1.1.3.1.2.$session_id);
 
-return 1 if (!$result || $result =~ /no response/i); # Could not SNMP. 
Assume still there
+return 0 if (!$result || $result =~ /no response/i); # Could not SNMP. 
Give benefit of doubt to user.
 return 0 if $result =~ /no such variable/i;  # Not in the MIB means no 
such session
 return uc($1) eq uc($name)
if ($result =~ /^.*\([^]+).*$/);

Hope this helps,

-- 
Nathan Anderson
First Step Internet, LLC
nath...@fsr.com
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

[RADIATOR] Radiator Version 4.14 released - includes a fix for EAP authentication vulnerability

[Heikki Vatiainen]

We are pleased to announce the release of Radiator version 4.14

This version contains a fix for an EAP authentication vulnerability. 
Upgrade is strongly recommended. Please review OSC security advisory 
OSC-SEC-2014-01 for more information:
https://www.open.com.au/OSC-SEC-2014-01.html

As usual, the new version is available to current licensees from:
https://www.open.com.au/radiator/downloads/

and to current evaluators from:
https://www.open.com.au/radiator/demo-downloads

Licensees with expired access contracts can renew at:
https://www.open.com.au/renewal.html

An extract from the history file
https://www.open.com.au/radiator/history.html is below:

-

Revision 4.14 (2014-12-03)

 Selected fixes, compatibility notes and enhancements

Fixes a vulnerability and very significant bug in EAP authentication.
OSC recommends all users to review OSC security advisory
OSC-SEC-2014-01 to see if they are affected.
https://www.open.com.au/OSC-SEC-2014-01.html

Client findAddress() was changed to lookup CIDR clients before DEFAULT
client. Affects ServerTACACSPLUS and in some cases SessionDatabase
modules.

Added support for non-blocking sockets on Windows

SessionDatabase SQL queries now support bind variables



 Detailed changes

Added VENDOR Allot 2603 and VSA Allot-User-Role to dictionary.

Added Diameter AVP flag hints in the Diameter Credit-Control
Application dictionary.

Prevented crash during startup when configured to support a Diameter
application for which no dictionary module was not present. Reported
by Arthur. Improved logging of loading of Diameter application
dictionary modules.

Improvements to AuthBy SIP2 to add support for SIP2Hook. SIP2Hook can
be used for patron authorisation and/or authentication. Added an
example hook goodies/sip2hook.pl. Added a new optional parameter
UsePatronInformationRequest for configurations in which Patron Status
Request is not sufficient.

Fixed a problem with SNMPAgent which could cause a crash if the
configuration had no Clients.

Stream and StreamServer sockets are now set to nonblocking mode on
Windows too. This allows for example, RadSec to use nonblocking
sockets on Windows.

radpwtst now honours -message_authenticator option for all request
types specified with the -code parameter.

Client.pm findAddress() was changed to look up CIDR clients before
DEFAULT client. This is the same order Client lookup for incoming
RADIUS requests uses. This affects mostly
ServerTACACSPLUS. SessionDatabase DBM, INTERNAL and SQL also use
findAddress() and are affected when Clients have NasType configured
for Simultaneous-Use online checking. Client lookup was simplified in
ServerTACACSPLUS.

Added VENDOR Cambium 17713 and four Cambium-Canopy VSAs to
dictionary. RADIUS Attributes for IEEE 802 Networks is now RFC
7268. Updated some of its attribute types.

AuthBy MULTICAST now checks first, not after, if the next hop host is
working before creating the request to forward. This will save cycles
when the next hop is not working.

Added VENDOR Apcon 10830 and VSA Apcon-User-Level to
dictionary. Contributed by Jason Griffith.

Added support for custom password hashes and other user defined
password check methods. When the new configuration parameter
CheckPasswordHook is defined for an AuthBy and the password retrieved
from the user database starts with leading '{OSC-pw-hook}', the
request, the submitted password and the retrieved password are passed
to the CheckPasswordHook. The hook must return true if the submitted
password is deemed correct. TranslatePasswordHook runs before
CheckPasswordHook and can be used to add '{OSC-pw-hook}' to the
retrieved passwords.

AuthLog SYSLOG and Log SYSLOG now check LogOpt during the
configuration check phase. Any problems are now logged with the
loggers Identifier.

The defaults for SessionDatabase SQL AddQuery and CountQuery now use
%0 where username is needed. Updated the documentation to clarify the
value of %0 for AddQuery, CountQuery, ReplaceQuery, UpdateQuery and
DeleteQuery: %0 is the quoted original username. However, if
SessionDatabaseUseRewrittenName is set for the Handler and the check
is done by Handler (MaxSessions) or AuthBy (DefaultSimultaneousUse),
then %0 is the rewritten username. For per-user session database
queries %0 is always the original username. Updated the documentation
for CountQuery to include %0 and %1. For CountQuery %1 is the value of
the simultaneous use limit.

Enhanced resolution of vendor names to Vendor-Id values for
SupportedVendorIds, VendorAuthApplicationIds and
VendorAcctApplicationIds. Keyword DictVendors for SupportedVendorIds
now includes vendors from all dictionaries that are loaded. Vendor
name in Vendor*ApplicationIds can be in any of the loaded dictionaries
in addition of being listed in DiaMsg module.

Added VENDOR InMon 4300 and VSA InMon-Access-Level to
dictionary. Contributed by Garry Shtern.

Added ReplyTimeoutHook to AuthBy RADIUS, called if no reply is heard

[RADIATOR] Radiator evaluation - now available as virtual machine

[Heikki Vatiainen]

We are pleased to announce the availability of the first release of
preconfigured Radiator and RAdmin evaluation virtual machine.

The virtual machine image is available from the usual location:
http://www.open.com.au/radiator/

The virtual machine is configured to respond to RADIUS, TACACS+ and
Diameter requests. The default configuration supports multiple
authentication protocols and EAP methods from plain passwords to PEAP
and EAP-TLS.

The users are authenticated by default from MySQL database. These user
accounts can be managed with RAdmin or directly with MySQL tools.

Additional software has been installed to help integrating Radiator with
different systems and user databases. Some examples are: LDAP and SQL
servers, Active Directory over NTLM, hardware and software token based
authentication systems and integration with Micros Opera and Mikrotik.

Connections to Oracle and Microsoft SQL databases have been prepared. A
simple download from the respective vendors is required to complete the
set up.

As always, any comments and suggestions are welcome.

Thanks,
Heikki

-- 
Heikki Vatiainen h...@open.com.au

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] Radiator / Radmin - EAP TLS certificates on Android phone

[Imanol Fuidio]

Hi Heikki,

The same problems with the certificates :(

Thanks for your this suggestion,

Imanol


On Thu, Jun 19, 2014 at 9:17 PM, Heikki Vatiainen h...@open.com.au wrote:

 On 06/19/2014 12:46 AM, Imanol Fuidio wrote:

  I have repeated the test on an iphone with IOS7 configuring a TLS
  profile with the CA in der format. The same problem.
  The log is also in https://gist.github.com/ifdm001/57c03984282f33406aec

 Maybe you could try with the certificates that come with Radiator? See
 the certificates/ directory in the distribution. Those certificates have
 been used with EAP-TLS, so they could help building an initial working
 configuration before switching to different certificates.

 Thanks,
 Heikki

 --
 Heikki Vatiainen h...@open.com.au

 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.




-- 

Imanol Fuidio Díaz-Maroto

Fon Labs
RD engineerimanol.fui...@fon.com
skype: imanol.fon
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Radiator / Radmin - EAP TLS certificates on Android phone

[Heikki Vatiainen]

On 06/19/2014 12:46 AM, Imanol Fuidio wrote:

 I have repeated the test on an iphone with IOS7 configuring a TLS
 profile with the CA in der format. The same problem.
 The log is also in https://gist.github.com/ifdm001/57c03984282f33406aec

Maybe you could try with the certificates that come with Radiator? See
the certificates/ directory in the distribution. Those certificates have
been used with EAP-TLS, so they could help building an initial working
configuration before switching to different certificates.

Thanks,
Heikki

-- 
Heikki Vatiainen h...@open.com.au

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

[RADIATOR] Radiator / Radmin - EAP TLS certificates on Android phone

[Imanol Fuidio]

Hi everyone,

In the company we have performed some tests on EAP TLS.
We are using Radiator-4.13 with the goodie eap_tls.cfg.

We have created self-signed certificates through the script: script.sh
(You can find the script, as well as the certificates in
https://gist.github.com/ifdm001/57c03984282f33406aec )

During the tests, we have installed the cert-clt.p12 cert file on a Galaxy
S3 with Android 4.1.2
We have also installed the CA file cacert.pem.

The WiFi configuration is: EAP method TLS, Phase 2 PAP, User certificate,
Identiy user

We also have added the identity user to the file database.

When we have not configured the CA file in the WiFi configuration profile,
everything works. It is strange there is no message from Android saying
that the server certificate will be not verified, also there is no
checklist option to validate this ( as there is in microsoft, see.
https://support.microsoft.com/kb/814394).

When we configure the CA file in the WiFi configuration profile on the
Android phone, we found the following error in Radiator:

Wed Jun 18 11:49:35 2014: DEBUG: Handling request with Handler
'Realm=DEFAULT', Identifier ''
Wed Jun 18 11:49:35 2014: DEBUG:  Deleting session for user, 10.1.0.9,
Wed Jun 18 11:49:35 2014: DEBUG: Handling with Radius::AuthFILE:
Wed Jun 18 11:49:35 2014: DEBUG: Handling with EAP: code 2, 255, 200, 13
Wed Jun 18 11:49:35 2014: DEBUG: Response type 13
Wed Jun 18 11:49:35 2014: DEBUG: Certificate Subject Name is
/C=ES/ST=Biscay/L=Getxo/O=Fon/OU=Fon Labs/CN=user
Wed Jun 18 11:49:35 2014: DEBUG: Matched certificate CN user with User-Name
user or identity user
Wed Jun 18 11:49:35 2014: DEBUG: Reading users file ./users
Wed Jun 18 11:49:35 2014: DEBUG: Radius::AuthFILE looks for match with user
[user]
Wed Jun 18 11:49:35 2014: DEBUG: Radius::AuthFILE ACCEPT: : user [user]
Wed Jun 18 11:49:35 2014: ERR: EAP TLS error: -1, 1, 8592, 0,  22411: 1 -
error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number

Wed Jun 18 11:49:35 2014: DEBUG: EAP Failure, elapsed time 0.179251
Wed Jun 18 11:49:35 2014: DEBUG: EAP result: 1, EAP TLS error
Wed Jun 18 11:49:35 2014: DEBUG: AuthBy FILE result: REJECT, EAP TLS error
Wed Jun 18 11:49:35 2014: INFO: Access rejected for user: EAP TLS error
Wed Jun 18 11:49:35 2014: DEBUG: Packet dump:
*** Sending to 10.1.0.9 port 54719 
Code:   Access-Reject
Identifier: 189
Authentic:
 194153-2042001218917616819624180148210i
Attributes:
EAP-Message = 425504
Message-Authenticator = 
Reply-Message = Request Denied

The full log is in the file eap_tls.log file, also in
https://gist.github.com/ifdm001/57c03984282f33406aec

Any help with this problem, we will be grateful.

Thanks,

Imanol

-- 

Imanol Fuidio Díaz-Maroto

Fon Labs
RD engineerimanol.fui...@fon.com
skype: imanol.fon
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Radiator / Radmin - EAP TLS certificates on Android phone

[Heikki Vatiainen]

On 06/18/2014 02:04 PM, Imanol Fuidio wrote:

 The WiFi configuration is: EAP method TLS, Phase 2 PAP, User
 certificate, Identiy user

Phase 2 PAP looks odd. This would make sense with EAP-TTLS, but I am not
sure what it could mean with EAP-TLS.

 Wed Jun 18 11:49:35 2014: ERR: EAP TLS error: -1, 1, 8592, 0,  22411: 1
 - error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number

Can you try with other settings for Phase 2, such as none, off or
something else to turn off any Phase 2 authentication off. I'd say the
above message might come from something that the client adds and appears
as bad TLS record to the server.

Thanks,
Heikki

-- 
Heikki Vatiainen h...@open.com.au

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] Radiator / Radmin - EAP TLS certificates on Android phone

[Imanol Fuidio]

Hi Heikki,

The same test repeated with Second Phase as none and the same problem.
As you have said, this should have nothing to do with EAP TLS.

I have repeated the test on an iphone with IOS7 configuring a TLS profile
with the CA in der format. The same problem.
The log is also in https://gist.github.com/ifdm001/57c03984282f33406aec

Thanks for the contribution,

Imanol


On Wed, Jun 18, 2014 at 10:05 PM, Heikki Vatiainen h...@open.com.au wrote:

 On 06/18/2014 02:04 PM, Imanol Fuidio wrote:

  The WiFi configuration is: EAP method TLS, Phase 2 PAP, User
  certificate, Identiy user

 Phase 2 PAP looks odd. This would make sense with EAP-TTLS, but I am not
 sure what it could mean with EAP-TLS.

  Wed Jun 18 11:49:35 2014: ERR: EAP TLS error: -1, 1, 8592, 0,  22411: 1
  - error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number

 Can you try with other settings for Phase 2, such as none, off or
 something else to turn off any Phase 2 authentication off. I'd say the
 above message might come from something that the client adds and appears
 as bad TLS record to the server.

 Thanks,
 Heikki

 --
 Heikki Vatiainen h...@open.com.au

 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.




-- 

Imanol Fuidio Díaz-Maroto

Fon Labs
RD engineerimanol.fui...@fon.com
skype: imanol.fon
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Radiator / Radmin - bulk add users

[Michael Bellears]

Excellent - Thanks Hugh.


-Original Message-
From: Hugh Irvine [mailto:h...@open.com.au] 
Sent: Thursday, 12 June 2014 4:05 PM
To: Michael Bellears
Cc: radiator@open.com.au
Subject: Re: [RADIATOR] Radiator / Radmin - bulk add users


Hello Michael -

See buildsql in the main Radiator distribution directory.

See also section 10.0 in the Radiator 4.13 reference manual (doc/ref.pdf).

Here is the help for buildsql:


Radiator-4.13 hugh$ perl buildsql -h

usage: buildsql [-h] -dbsource dbi:drivername:option
[-dbusername dbusername] [-dbauth auth] [-password | -dbm | -flat]
[-z] [-u] [-f] [-d username] [-l username] [-t dbmtype]
[-tablename name] [-v]
[-username_column columnname]
[-password_column columnname]
[-encryptedpassword]
[-checkattr_column columnname]
[-replyattr_column columnname] filename ...



regards

Hugh


On 12 Jun 2014, at 12:45, Michael Bellears mbelle...@gcomm.com.au wrote:

 Hi,
  
 We have a need to add ~150users to Radmin - Doing this via the (Radmin) web 
 interface would be tedious/error-prone - Is anyone aware of a script to bulk 
 add users?
  
 Cheers.
 ___
 radiator mailing list
 radiator@open.com.au
 http://www.open.com.au/mailman/listinfo/radiator


--

Hugh Irvine
h...@open.com.au

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, SIM, etc. 
Full source on Unix, Linux, Windows, MacOSX, Solaris, VMS, NetWare etc.

___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Radiator / Radmin - bulk add users

[Hugh Irvine]

Hello Michael -

See buildsql in the main Radiator distribution directory.

See also section 10.0 in the Radiator 4.13 reference manual (“doc/ref.pdf”).

Here is the help for buildsql:


Radiator-4.13 hugh$ perl buildsql -h

usage: buildsql [-h] -dbsource dbi:drivername:option
[-dbusername dbusername] [-dbauth auth] [-password | -dbm | -flat]
[-z] [-u] [-f] [-d username] [-l username] [-t dbmtype]
[-tablename name] [-v]
[-username_column columnname]
[-password_column columnname]
[-encryptedpassword]
[-checkattr_column columnname]
[-replyattr_column columnname] filename ...



regards

Hugh


On 12 Jun 2014, at 12:45, Michael Bellears mbelle...@gcomm.com.au wrote:

 Hi,
  
 We have a need to add ~150users to Radmin – Doing this via the (Radmin) web 
 interface would be tedious/error-prone – Is anyone aware of a script to bulk 
 add users?
  
 Cheers.
 ___
 radiator mailing list
 radiator@open.com.au
 http://www.open.com.au/mailman/listinfo/radiator


--

Hugh Irvine
h...@open.com.au

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, SIM, etc. 
Full source on Unix, Linux, Windows, MacOSX, Solaris, VMS, NetWare etc.

___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

[RADIATOR] Radiator / Radmin - bulk add users

[Michael Bellears]

Hi,

We have a need to add ~150users to Radmin - Doing this via the (Radmin) web 
interface would be tedious/error-prone - Is anyone aware of a script to bulk 
add users?

Cheers.
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Radiator Version 4.13 released

[Heikki Vatiainen]

On 05/02/2014 03:24 PM, Hartmaier Alexander wrote:

 I've configured the outer PEAP Handler with EAPTLS_MaxFragmentSize 1350
 and removed the value 1250 (1300 which we use for wired dot1x seems to
 be too large) from the inner TLS handler which makes it fail the same
 way as when configuring 1300.
 Is the other value too large or how is the inner size calculated?

The inner size simply uses the outer fragment size minus 40 bytes. It
appears this number is not large enough for all cases then.

The correct number in your case is something between 1250 and 1300 when
you have outer fragment size 1350? That is, when you have 1350 as outer
fragment size, 1250 works but 1300 does not.

Thanks,
Heikki

-- 
Heikki Vatiainen h...@open.com.au

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] Radiator Version 4.13 released

[Hartmaier Alexander]

On 2014-05-05 13:53, Heikki Vatiainen wrote:
 On 05/02/2014 03:24 PM, Hartmaier Alexander wrote:

 I've configured the outer PEAP Handler with EAPTLS_MaxFragmentSize 1350
 and removed the value 1250 (1300 which we use for wired dot1x seems to
 be too large) from the inner TLS handler which makes it fail the same
 way as when configuring 1300.
 Is the other value too large or how is the inner size calculated?
 The inner size simply uses the outer fragment size minus 40 bytes. It
 appears this number is not large enough for all cases then.

 The correct number in your case is something between 1250 and 1300 when
 you have outer fragment size 1350? That is, when you have 1350 as outer
 fragment size, 1250 works but 1300 does not.
So what you're saying is that 1350 for the outer results in an inner
calcuated one of 1310 bytes which is too large?

Which fragment size should be configured, the outer or the inner one?
If the inner is calculated from the outer I shouldn't configure the
inner one but simply reduce the outer one until it works?

The value is the number of bytes the EAP messages are split into and
transmitted via the EAP-Message radius attribute, correct?
So the number is depended on how much bytes all other radius attributes
consume from the MTU which should be 1500 for both wired and wireless in
our case?



 Thanks,
 Heikki

BR Alex


***
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
***
Notice: This e-mail contains information that is confidential and may be 
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
***
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Radiator Version 4.13 released

[Heikki Vatiainen]

On 05/05/2014 03:01 PM, Hartmaier Alexander wrote:

 The correct number in your case is something between 1250 and 1300 when
 you have outer fragment size 1350? That is, when you have 1350 as outer
 fragment size, 1250 works but 1300 does not.
 So what you're saying is that 1350 for the outer results in an inner
 calcuated one of 1310 bytes which is too large?

Yes, the inner EAP-TLS creates fragments of size 1310 and based on your
message, I understand when these are given to outer PEAP for TLS
tunneling and transport, the result is too large: it does not fit in 1350.

 Which fragment size should be configured, the outer or the inner one?
 If the inner is calculated from the outer I shouldn't configure the
 inner one but simply reduce the outer one until it works?

It should have worked so that the inner fragmentation matches the outer.
However, since it does not, you should configure the outer handler
MaxFragmentSize to as large value as possible, for example 1350 and then
configure the MaxFragmentSize for the inner AuthBy to as large value as
possible. It seems 1250 seems to work for you.

 The value is the number of bytes the EAP messages are split into and
 transmitted via the EAP-Message radius attribute, correct?

Yes, with the addition, that if you have for example an EAP message that
is 1300 bytes long, it needs to be broken into EAP-Message attributes
which have payload size of 253 bytes.

 So the number is depended on how much bytes all other radius attributes
 consume from the MTU which should be 1500 for both wired and wireless in
 our case?

Yes. Also the inner AuthBy's MaxFragmentSize must track the outer
fragment size so that the chunks that inner AuthBy produces do not grow
too large after TLS processing. This is not a problem with EAP-MSCHAP-V2
but when EAP-TLS is the inner protocol, then the inner AuthBy requires
MaxFragmentSize.

Thanks,
Heikki

-- 
Heikki Vatiainen h...@open.com.au

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] Radiator Version 4.13 released

[Hartmaier Alexander]

On 2014-05-05 15:02, Heikki Vatiainen wrote:
 On 05/05/2014 03:01 PM, Hartmaier Alexander wrote:

 The correct number in your case is something between 1250 and 1300 when
 you have outer fragment size 1350? That is, when you have 1350 as outer
 fragment size, 1250 works but 1300 does not.
 So what you're saying is that 1350 for the outer results in an inner
 calcuated one of 1310 bytes which is too large?
 Yes, the inner EAP-TLS creates fragments of size 1310 and based on your
 message, I understand when these are given to outer PEAP for TLS
 tunneling and transport, the result is too large: it does not fit in 1350.
Can you add a critical logging for that case so the problem can quickly
be found? With a calculated suggested value maybe?


 Which fragment size should be configured, the outer or the inner one?
 If the inner is calculated from the outer I shouldn't configure the
 inner one but simply reduce the outer one until it works?
 It should have worked so that the inner fragmentation matches the outer.
 However, since it does not, you should configure the outer handler
 MaxFragmentSize to as large value as possible, for example 1350 and then
 configure the MaxFragmentSize for the inner AuthBy to as large value as
 possible. It seems 1250 seems to work for you.

 The value is the number of bytes the EAP messages are split into and
 transmitted via the EAP-Message radius attribute, correct?
 Yes, with the addition, that if you have for example an EAP message that
 is 1300 bytes long, it needs to be broken into EAP-Message attributes
 which have payload size of 253 bytes.
Where does the 253 come from?


 So the number is depended on how much bytes all other radius attributes
 consume from the MTU which should be 1500 for both wired and wireless in
 our case?
 Yes. Also the inner AuthBy's MaxFragmentSize must track the outer
 fragment size so that the chunks that inner AuthBy produces do not grow
 too large after TLS processing. This is not a problem with EAP-MSCHAP-V2
 but when EAP-TLS is the inner protocol, then the inner AuthBy requires
 MaxFragmentSize.
So the new feature in 4.13 only helps for PEAP-MSCHAPv2, not for PEAP-TLS?


 Thanks,
 Heikki




***
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
***
Notice: This e-mail contains information that is confidential and may be 
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
***
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Radiator Version 4.13 released

[Heikki Vatiainen]

On 05/05/2014 04:18 PM, Hartmaier Alexander wrote:

 Yes, the inner EAP-TLS creates fragments of size 1310 and based on your
 message, I understand when these are given to outer PEAP for TLS
 tunneling and transport, the result is too large: it does not fit in 1350.

 Can you add a critical logging for that case so the problem can quickly
 be found? With a calculated suggested value maybe?

Good idea. I'll ask if it's possible to detect if the inner request fits in.

 Yes, with the addition, that if you have for example an EAP message that
 is 1300 bytes long, it needs to be broken into EAP-Message attributes
 which have payload size of 253 bytes.
 Where does the 253 come from?

It's just the RADIUS attribute format: one byte for type, one for length
and 253 for the payload size since the length field is only one octet long.

 Yes. Also the inner AuthBy's MaxFragmentSize must track the outer
 fragment size so that the chunks that inner AuthBy produces do not grow
 too large after TLS processing. This is not a problem with EAP-MSCHAP-V2
 but when EAP-TLS is the inner protocol, then the inner AuthBy requires
 MaxFragmentSize.
 So the new feature in 4.13 only helps for PEAP-MSCHAPv2, not for PEAP-TLS?

PEAP/EAP-MSCHAP-V2 should not run into fragmentation issue the
EAP-MSCHAP-V2 message are short. It was meant for PEAP/EAP-TLS since
EAP-TLS can create long requests.

Any configuration that worked before 4.13 should work with 4.13 too. The
idea was to make sure any new configurations would not need to worry
about fragmentation issues when EAP-TLS was the tunnelled protocol.

Thanks,
Heikki

-- 
Heikki Vatiainen h...@open.com.au

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] Radiator Version 4.13 released

[Hartmaier Alexander]

On 2014-05-05 15:39, Heikki Vatiainen wrote:
 On 05/05/2014 04:18 PM, Hartmaier Alexander wrote:

 Yes, the inner EAP-TLS creates fragments of size 1310 and based on your
 message, I understand when these are given to outer PEAP for TLS
 tunneling and transport, the result is too large: it does not fit in 1350.
 Can you add a critical logging for that case so the problem can quickly
 be found? With a calculated suggested value maybe?
 Good idea. I'll ask if it's possible to detect if the inner request fits in.
Thanks!


 Yes, with the addition, that if you have for example an EAP message that
 is 1300 bytes long, it needs to be broken into EAP-Message attributes
 which have payload size of 253 bytes.
 Where does the 253 come from?
 It's just the RADIUS attribute format: one byte for type, one for length
 and 253 for the payload size since the length field is only one octet long.
So one RADIUS attribute can't get longer than 253 bytes so the EAP
message is split into multiple EAP-Message attributes across multiple
RADIUS request packets as well as multiple times in a single packet?


 Yes. Also the inner AuthBy's MaxFragmentSize must track the outer
 fragment size so that the chunks that inner AuthBy produces do not grow
 too large after TLS processing. This is not a problem with EAP-MSCHAP-V2
 but when EAP-TLS is the inner protocol, then the inner AuthBy requires
 MaxFragmentSize.
 So the new feature in 4.13 only helps for PEAP-MSCHAPv2, not for PEAP-TLS?
 PEAP/EAP-MSCHAP-V2 should not run into fragmentation issue the
 EAP-MSCHAP-V2 message are short. It was meant for PEAP/EAP-TLS since
 EAP-TLS can create long requests.

 Any configuration that worked before 4.13 should work with 4.13 too. The
 idea was to make sure any new configurations would not need to worry
 about fragmentation issues when EAP-TLS was the tunnelled protocol.
Yes, the manual configured values continued to work, our wireless
PEAP-TLS config is a new one, the old used 1024/800.
I just hoped that I could simplify the config and it still works.
Should I try removing MaxFragmentSize from both the PEAP and the TLS
handler?

 Thanks,
 Heikki




***
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
***
Notice: This e-mail contains information that is confidential and may be 
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
***
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Radiator Version 4.13 released

[Hartmaier Alexander]

Hi,
the following new feature seems to not work as I'd expect it:
PEAP and EAP-TTLS now make maximum fragment size available for inner
authentication protocols. EAP-TLS was improved to use this information.
This allows PEAP/EAP-TLS and EAP-TTLS/EAP-TLS to work better with
environments with variable Framed-MTU sizes.

I've configured the outer PEAP Handler with EAPTLS_MaxFragmentSize 1350
and removed the value 1250 (1300 which we use for wired dot1x seems to
be too large) from the inner TLS handler which makes it fail the same
way as when configuring 1300.
Is the other value too large or how is the inner size calculated?

Thanks, Alex

On 2014-04-16 14:45, Heikki Vatiainen wrote:
 We are pleased to announce the release of Radiator version 4.13

 This version contains one new module for authenticating against YubiKey
 validation server and YubiHSM, some significant new features and bug fixes.

 As usual, the new version is available to current licensees from:
 https://www.open.com.au/radiator/downloads/

 and to current evaluators from:
 https://www.open.com.au/radiator/demo-downloads/

 Licensees with expired access contracts can renew at:
 https://www.open.com.au/renewal.html

 An extract from the history file
 https://www.open.com.au/radiator/history.html is below:

 -

 Revision 4.13 (2014-04-16) Radius proxying, IPv6, TACACS+, Diameter and
 other enhancements. Bug fixes


 Selected compatibility notes and enhancements

 Unknown attributes can now be proxied instead of being dropped

 Diameter enhancements may require changes to custom Diameter modules

 Major IPv6 enhancements include: Attributes with IPv6 values can now be
 proxied without IPv6 support, Socket6 is no longer an absolute
 prerequisite. 'ipv6:' prefix is now optional and not prepended in
 attribute values

 TACACS+ authentication and authorization can now be decoupled

 Bind variables are now available for AuthLog SQL and Log SQL.

 Status-Server requests without correct Message-Identifier are ignored.
 Status-Server responses are now configurable.

 LDAP attributes can now be fetched with base scope after subtree scoped
 search. Useful for example, tokenGroups AD attributes which are not
 otherwise available

 Newly added check for CVE-2014-0160, the OpenSSL Heartbleed
 vulnerability may log false positives

 New AuthBy for authenticating against YubiKey validation server added

 See Radiator SIM pack revision history for supported SIM pack versions



 Detailed changes

 Added the attributes from RFC 6911 to dictionary (Framed-IPv6-Address,
 DNS-Server-IPv6-Address, Route-IPv6-Information,
 Delegated-IPv6-Prefix-Pool and Stateful-IPv6-Address-Pool). These
 attributes override a number of attributes that were previously
 commandeered by Ascend and Merit. The Ascend ones are still available in
 ascend.dictionary. The Merit attributes were added under the existing
 Merit VSA entry and the non-VSA Merit attributes were removed from the
 main dictionary. The non-VSA Merit attributes will continue to be
 available in a new file goodies/dictionary.merit

 AuthBy RADIUS and all its subclasses e.g., AuthBy SQLRADIUS, LDAPRADIUS,
 MULTICAST and proxy algorithm AuthBys, now support special characters in
 AuthPort and AcctPort. Suggested by David Zych.

 Added in dictionary: Huawei-Loopback-Address, vendor 6139
 (Alcatel-Lucent OmniAccess), vendor 20942 (China Telecom-Guangzhou
 Research and Development Center) and vendor 27262 DANTE Ltd.

 Unknown attributes can now be proxied when the new global configuration
 flag ProxyUnknownAttributes is set to true. Unknown attributes are now
 alwasy available with special names such as Unknown-9048-120, where 9048
 is the vendor id and 120 is the vendor attribute number. Unknown
 attributes are now logged with level WARNING instead of ERR. A warning
 is logged for each attribute once per sender IP address. Attribute names
 starting with Unknown are reserved in dictionary and ignored when the
 dictionary is loaded.

 Added in dictionary: Attributes from RFC 5447, RFC 6519, RFC 6677 and
 RFC 6930.

 Added support for dictionary type ipv4prefix required by RFC 6572. An
 example of ipv4prefix format is '192.168.1.0/24'. Added attributes from
 RFC 6572 in dictionary.

 Change in 4.12 caused ServerDIAMETER to always create new peer instances
 for new connections. This caused mainly WatchdogState DOWN log litter.

 AuthBy DIAMETER and other DiameterClient derived classes, such as
 Diameter Wx based EAP-SIM, EAP-AKA and EAP-AKAPRIME AuthBys, now support
 new option SCTPPeer. This option allows defining multiple SCTP peers for
 the initial SCTP association attempt.

 Added vendor Arista in dictionary. Updated Netscreen values. Contributed
 by Garry Shtern.

 Fixed AuthBy NTLM so it will not leave zombie processes around during
 reconfigure. Reported by Garry Shtern.

 AuthBy RATELIMIT now supports optional parameter MaxRateResult, which
 allows specifying the result when MaxRate 

[RADIATOR] Radiator Version 4.13 released

[Heikki Vatiainen]

We are pleased to announce the release of Radiator version 4.13

This version contains one new module for authenticating against YubiKey
validation server and YubiHSM, some significant new features and bug fixes.

As usual, the new version is available to current licensees from:
https://www.open.com.au/radiator/downloads/

and to current evaluators from:
https://www.open.com.au/radiator/demo-downloads/

Licensees with expired access contracts can renew at:
https://www.open.com.au/renewal.html

An extract from the history file
https://www.open.com.au/radiator/history.html is below:

-

Revision 4.13 (2014-04-16) Radius proxying, IPv6, TACACS+, Diameter and
other enhancements. Bug fixes


Selected compatibility notes and enhancements

Unknown attributes can now be proxied instead of being dropped

Diameter enhancements may require changes to custom Diameter modules

Major IPv6 enhancements include: Attributes with IPv6 values can now be
proxied without IPv6 support, Socket6 is no longer an absolute
prerequisite. 'ipv6:' prefix is now optional and not prepended in
attribute values

TACACS+ authentication and authorization can now be decoupled

Bind variables are now available for AuthLog SQL and Log SQL.

Status-Server requests without correct Message-Identifier are ignored.
Status-Server responses are now configurable.

LDAP attributes can now be fetched with base scope after subtree scoped
search. Useful for example, tokenGroups AD attributes which are not
otherwise available

Newly added check for CVE-2014-0160, the OpenSSL Heartbleed
vulnerability may log false positives

New AuthBy for authenticating against YubiKey validation server added

See Radiator SIM pack revision history for supported SIM pack versions



Detailed changes

Added the attributes from RFC 6911 to dictionary (Framed-IPv6-Address,
DNS-Server-IPv6-Address, Route-IPv6-Information,
Delegated-IPv6-Prefix-Pool and Stateful-IPv6-Address-Pool). These
attributes override a number of attributes that were previously
commandeered by Ascend and Merit. The Ascend ones are still available in
ascend.dictionary. The Merit attributes were added under the existing
Merit VSA entry and the non-VSA Merit attributes were removed from the
main dictionary. The non-VSA Merit attributes will continue to be
available in a new file goodies/dictionary.merit

AuthBy RADIUS and all its subclasses e.g., AuthBy SQLRADIUS, LDAPRADIUS,
MULTICAST and proxy algorithm AuthBys, now support special characters in
AuthPort and AcctPort. Suggested by David Zych.

Added in dictionary: Huawei-Loopback-Address, vendor 6139
(Alcatel-Lucent OmniAccess), vendor 20942 (China Telecom-Guangzhou
Research and Development Center) and vendor 27262 DANTE Ltd.

Unknown attributes can now be proxied when the new global configuration
flag ProxyUnknownAttributes is set to true. Unknown attributes are now
alwasy available with special names such as Unknown-9048-120, where 9048
is the vendor id and 120 is the vendor attribute number. Unknown
attributes are now logged with level WARNING instead of ERR. A warning
is logged for each attribute once per sender IP address. Attribute names
starting with Unknown are reserved in dictionary and ignored when the
dictionary is loaded.

Added in dictionary: Attributes from RFC 5447, RFC 6519, RFC 6677 and
RFC 6930.

Added support for dictionary type ipv4prefix required by RFC 6572. An
example of ipv4prefix format is '192.168.1.0/24'. Added attributes from
RFC 6572 in dictionary.

Change in 4.12 caused ServerDIAMETER to always create new peer instances
for new connections. This caused mainly WatchdogState DOWN log litter.

AuthBy DIAMETER and other DiameterClient derived classes, such as
Diameter Wx based EAP-SIM, EAP-AKA and EAP-AKAPRIME AuthBys, now support
new option SCTPPeer. This option allows defining multiple SCTP peers for
the initial SCTP association attempt.

Added vendor Arista in dictionary. Updated Netscreen values. Contributed
by Garry Shtern.

Fixed AuthBy NTLM so it will not leave zombie processes around during
reconfigure. Reported by Garry Shtern.

AuthBy RATELIMIT now supports optional parameter MaxRateResult, which
allows specifying the result when MaxRate is exceeded. MaxRateResult
defaults to IGNORE.

Significant IPv6 changes. Socket6.pm is no longer required if the core
Socket module provides the required IPv6 support. Attributes with IPv6
address or prefix type are now handled as binary if there is no Socket
or Socket6 for IPv6 support. This fixes the problem with proxying when
Socket6 was not installed. Prefix 'ipv6:' for IPv6 addresses is no
longer required but will be accepted. Decoded values for IPv6 address
type attributes will no longer have 'ipv6:' prefix. Startup log messages
now contain information about the IPv6 support.

Updated 3GPP (vendor 10415) attributes in dictionary.
3GPP-Allocate-IP-Type, 3GPP-External-Identifier and 3GPP-TWAN-Identifier
were added. 3GPP-Charging-Gateway-Address,

[RADIATOR] Radiator SIM support version 1.42 with SIM cards for EAP-SIM, EAP-AKA and EAP-AKA' released

[Heikki Vatiainen]

Hello Everyone,

Radiator SIM support version 1.42 is now released. This version supports
Radiator 4.13 and provides small updates to the recently released
version 1.41.

We are also pleased to announce the availability of SIM cards for those
who evaluate Radiator SIM support. We can provide mini, micro and nano
sized SIM cards with the authentication information to help with
EAP-SIM, EAP-AKA and EAP-AKA' evaluation. The SIM cards are provided
free of charge.

This allows you to set up a test environment for different SIM based
authentication methods, test with real equipment such as phones and
tablets running Apple IOS, Android and Windows Phone.

The Radiator SIM support includes a simple Diameter Wx and SWx HSS which
you can use while setting up your environment. When everything works as
required, you can change Radiator to use a real HSS and switch to the
operator provided SIM cards. All that is needed is a simple
configuration change to direct Radiator to the different HSS.

With our SIM cards and HSS it is easy to set up SIM based
authentication. There is no need for full access to operator HSS while
the system is being set up, configured and tested.

We have tested the SIM cards with:
- EAP-AKA with Android 4.1 and 4.2, IOS 7.1, Nokia Symbian S60 v3.0 and
v3.1.
- EAP-SIM with the above and Nokia Windows Phone 8, 8.1 developer
preview and Nokia Symbian S80 v2.0.
- EAP-AKA', EAP-AKA and EAP-SIM with wpa_supplicant software which
Android devices use

For more information about the Radiator SIM support, please see:
https://www.open.com.au/eap-sim/history.html

For the full revision history, please see:
https://www.open.com.au/eap-sim/history.html


Thanks,
Heikki

-- 
Heikki Vatiainen h...@open.com.au

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] Radiator/AuthWimax.pm BS ID Questions

[Heikki Vatiainen]

On 04/14/2014 07:07 AM, Adam O'Reilly wrote:

 Just wanting to find out the reasoning behind this:

 200 my $bsid = $p-get_attr('WiMAX-BS-ID');
 201 ($napid, $bsid) = unpack('a3 a3', $bsid)
 
 The reason is we are seeing WiMAX-BS-ID come in like this
 WiMAX-BS-ID = 000XXXX001
 
 (Removed the identifying parts)
 
 The AuthWimax Code then inserts irt into the device_session table as:
 
   bsid: 000
 
 Any help would be greatly appreciated.

I think the reason is this:
http://resources.wimaxforum.org/sites/wimaxforum.org/files/technical_document/2009/07/WMF-T33-001-R010v04_Network-Stage3-Base.pdf

Section 5.4.2.46 BS-ID says about the attribute value:

  Octet-String (6 Octets). Representing NAP operator identifier
  (first 3 Octets) and the Base Station ID (next 3 Octets).

Looking at a more recent doc,
WMF-T33-001-R015v03
WMF Approved
(2011-11-14)

the same definition is also there, unchanged.

Maybe your equipment has a configuration option to use different format?

Thanks,
Heikki


-- 
Heikki Vatiainen h...@open.com.au

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

[RADIATOR] Radiator/AuthWimax.pm BS ID Questions

[Adam O'Reilly]

Hello Everyone,

 

Just wanting to find out the reasoning behind this:

22 # $Id: AuthWIMAX.pm,v 1.21 2012/12/13 20:19:47 mikem Exp $

.

200 my $bsid = $p-get_attr('WiMAX-BS-ID');

201 ($napid, $bsid) = unpack('a3 a3', $bsid)

202 if (defined $bsid);

 

The reason is we are seeing WiMAX-BS-ID come in like this

 

WiMAX-BS-ID = 000XXXX001

 

(Removed the identifying parts)

 

The AuthWimax Code then inserts irt into the device_session table as:

 

  bsid: 000

 

Any help would be greatly appreciated.

 

Thanks

 

Adam

___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Radiator using WPA2-Enterprise and dynamic VLAN Assignment (Part 1)

[Hartmaier Alexander]

On 2014-03-26 18:40, Roberto Pantoja wrote:
I have a problem trying to assign dynamic VLANs to users on a  WPA2-Enterprise 
configuration. Users have successful authentication and if I don't send the 
Radius Attribute Tunnel-Private-Group-ID The Wireless Controller connects me 
to the default VLan for the SSID, but when I send Tunnel-Private-Group-ID, 
the Wireless Controller simply drops out my connection. The Wireless controller 
documentation says the required attributes in the Access-Accept Reply are 
Tunnel-Type=VLAN, Tunnel-Medium-Type=802, Tunnel-Private-Group-ID=Name of 
VLAN.  Everything works fine using Ignition Server (Avaya's Radius Server). 
But on product's documentation says WC8180 comply with RFC Standards and 
mentions to be compatible and validated with freeradius and Microsoft IAS, so 
I think my case is a configuration issue.

Regards.

Radiator Version: 4.12.1
Wireless Controller: AVAYA WC8180
Wireless Access Points: AVAYA AP8120

Config file:
*** Config File ***
# radius.cfg

Foreground
LogStdout
LogDir  /var/log/radius
LogFile %L/logfile.%Y.%m.%d
DbDir   /etc/radiator
# User a lower trace level in production systems:
Trace   4
AuthPort 1812
AcctPort 1813

Client 10.0.30.254
Secret verysecret
PacketTrace
Identifier Avaya WC8180
/Client

Handler TunnelledByPEAP=1
AuthBy FILE
Filename %D/users
EAPType MSCHAP-V2
/AuthBy
/Handler

Handler
AuthBy FILE
Filename %D/users
EAPType PEAP
EAPTLS_CAFile %D/certificates/cacert.pem
#   EAPTLS_CAPath
EAPTLS_CertificateFile %D/certificates/radiator-cert.pem
EAPTLS_CertificateType PEM
EAPTLS_PrivateKeyFile %D/certificates/radiator-key.pem
EAPTLS_PrivateKeyPassword verysecret
#   EAPTLS_RandomFile %D/certificates/random
EAPTLS_MaxFragmentSize 1024
#   EAPTLS_DHFile %D/certificates/cert/dh
#EAPTLS_CRLCheck
#EAPTLS_CRLFile %D/certificates/crl.pem
#EAPTLS_CRLFile %D/certificates/revocations.pem
AutoMPPEKeys
#EAPTLS_SessionResumption 0
#EAPTLS_SessionResumptionLimit 10
EAPAnonymous anonymous@localhost
EAPTLS_PEAPVersion 0
EAPTTLS_NoAckRequired
/AuthBy
/Handler
*** EOF Config File ***


Users file:
mikem user without VLAN default VLAN - Quarantine - no IP address
mikem1 user with VLAN Empleados - IP address range 10.0.21.0/24
mikem2 user with VLAN ATI - IP address range 10.0.19.0/24
*** Users file ***
# users
# This is an example of how to set up simple user for
# AuthBy FILE.
# The example user mikem has a password of fred, and will
# receive reply attributes suitable for most NASs.
# You can do many more interesting things. See the Radiator reference
# manual for more details
#
# You can test this user with the command
#  perl radpwtst

mikem   User-Password=fred
Service-Type = Framed-User,
Tunnel-Medium-Type = 802,
Tunnel-Type = VLAN

mikem1  User-Password=fred
Service-Type = Framed-User,
Tunnel-Private-Group-ID = Empleados,
Tunnel-Medium-Type = 802,
Tunnel-Type = VLAN

mikem2  User-Password=fred
Service-Type = Framed-User,
Tunnel-Private-Group-ID = ATI,
Tunnel-Medium-Type = 802,
Tunnel-Type = VLAN

*** EOF users file ***

We're doing that with Cisco WLCs without problems but in our case by sending 
the VLAN ID, not its name like for wired dot1x where Cisco IOS switches want 
the VLAN name:

AddToReply Tunnel-Type=VLAN,\
   Tunnel-Medium-Type=802, \
   Tunnel-Private-Group-ID=123


--
---
Roberto Carlos Pantoja Valdizón
Analista de Sistemas
ATI/GDEI/LaGeo



This message has been scanned for malware by Websense. 
www.websense.comhttp://www.websense.com/



___
radiator mailing list
radiator@open.com.aumailto:radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator



***
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
***
Notice: This e-mail contains information that is confidential and may be 
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
***
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Radiator using WPA2-Enterprise and dynamic VLAN Assignment (Part 1)

[Klara Mall]

Hi,

On 03/26/2014 06:40 PM, Roberto Pantoja wrote:
 I have a problem trying to assign dynamic VLANs to users on a 
 WPA2-Enterprise configuration. Users have successful authentication and
 if I don't send the Radius Attribute Tunnel-Private-Group-ID The
 Wireless Controller connects me to the default VLan for the SSID, but
 when I send Tunnel-Private-Group-ID, the Wireless Controller simply
 drops out my connection. The Wireless controller documentation says the
 required attributes in the Access-Accept Reply are Tunnel-Type=VLAN,
 Tunnel-Medium-Type=802, Tunnel-Private-Group-ID=Name of VLAN. 
 Everything works fine using Ignition Server (Avaya's Radius Server). But
 on product's documentation says WC8180 comply with RFC Standards and
 mentions to be compatible and validated with freeradius and Microsoft
 IAS, so I think my case is a configuration issue.

Are you sure that it's
Tunnel-Type=VLAN, Tunnel-Medium-Type=802, Tunnel-Private-Group-ID=Name
of VLAN
for your wireless controller?

We have an HP ProCurve WLAN Controller and I have to send:
Tunnel-Type = 13, Tunnel-Medium-Type = 6, Tunnel-Private-Group-ID =
vlan-id

It's the same for our LANCOM Access Points which are autonomous (no
controller).

I found a document Avaya WLAN 8100 Fundamentals regarding AVAYA WC8180
WLAN Controller. They say WC8180 is part of the WLAN 8100 solution.
http://198.152.212.23/css/P8/documents/100161076 (PDF file)

On page 87 they talk about authorization attributes:
Tunnel-Private-Group-Id: Mobility VLAN Name
Tunnel-Medium-Type: The value is 6 (IEEE 802)
Tunnel-Type: The value is 13 (VLAN)

So perhaps you have to send

Tunnel-Type=13, Tunnel-Medium-Type=6, Tunnel-Private-Group-ID=Name of VLAN

Apart from that: is it possible to proxy the request of the controller
through radiator to the Ignition Server i.e. to configure the radiator
server as a client on the Ignition Server? Then you'd see all attributes
that the Ignition Server is sending in the radiator debug log.

Regards
Klara

-- 
Karlsruher Institut für Technologie (KIT)
Steinbuch Centre for Computing (SCC)

Klara Mall
Netze und Telekommunikation (NET)
Hermann-von-Helmholtz-Platz 1
76344 Eggenstein-Leopoldshafen
Telefon: +49 721 608-28630
Telefon: +49 721 608-48946
E-Mail: klara.m...@kit.edu
Web: http://www.scc.kit.edu

KIT - Universität des Landes Baden-Württemberg und
nationales Forschungszentrum in der Helmholtz-Gemeinschaft
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Radiator using WPA2-Enterprise and dynamic VLAN Assignment (Part 1)

[Roberto Pantoja]

Thank you for your promptly answer, but I have the same effect if I put
the VLAN name or numeric ID. Do you have any other idea that can help me
to resolve this problem.

Best regards.

On 03/26/2014 11:37 AM, Hartmaier Alexander wrote:
 On 2014-03-26 18:40, Roberto Pantoja wrote:
 I have a problem trying to assign dynamic VLANs to users on a 
 WPA2-Enterprise configuration. Users have successful authentication
 and if I don't send the Radius Attribute Tunnel-Private-Group-ID
 The Wireless Controller connects me to the default VLan for the SSID,
 but when I send Tunnel-Private-Group-ID, the Wireless Controller
 simply drops out my connection. The Wireless controller documentation
 says the required attributes in the Access-Accept Reply are
 Tunnel-Type=VLAN, Tunnel-Medium-Type=802,
 Tunnel-Private-Group-ID=Name of VLAN.  Everything works fine using
 Ignition Server (Avaya's Radius Server). But on product's
 documentation says WC8180 comply with RFC Standards and mentions to
 be compatible and validated with freeradius and Microsoft IAS, so I
 think my case is a configuration issue.

 Regards.

 Radiator Version: 4.12.1
 Wireless Controller: AVAYA WC8180
 Wireless Access Points: AVAYA AP8120

 Config file:
 *** Config File ***
 # radius.cfg

 Foreground
 LogStdout
 LogDir  /var/log/radius
 LogFile %L/logfile.%Y.%m.%d
 DbDir   /etc/radiator
 # User a lower trace level in production systems:
 Trace   4
 AuthPort 1812
 AcctPort 1813

 Client 10.0.30.254
 Secret verysecret
 PacketTrace
 Identifier Avaya WC8180
 /Client

 Handler TunnelledByPEAP=1
 AuthBy FILE
 Filename %D/users
 EAPType MSCHAP-V2
 /AuthBy
 /Handler

 Handler
 AuthBy FILE
 Filename %D/users
 EAPType PEAP
 EAPTLS_CAFile %D/certificates/cacert.pem
 #   EAPTLS_CAPath
 EAPTLS_CertificateFile %D/certificates/radiator-cert.pem
 EAPTLS_CertificateType PEM
 EAPTLS_PrivateKeyFile %D/certificates/radiator-key.pem
 EAPTLS_PrivateKeyPassword verysecret
 #   EAPTLS_RandomFile %D/certificates/random
 EAPTLS_MaxFragmentSize 1024
 #   EAPTLS_DHFile %D/certificates/cert/dh
 #EAPTLS_CRLCheck
 #EAPTLS_CRLFile %D/certificates/crl.pem
 #EAPTLS_CRLFile %D/certificates/revocations.pem
 AutoMPPEKeys
 #EAPTLS_SessionResumption 0
 #EAPTLS_SessionResumptionLimit 10
 EAPAnonymous anonymous@localhost
 EAPTLS_PEAPVersion 0
 EAPTTLS_NoAckRequired
 /AuthBy
 /Handler
 *** EOF Config File ***


 Users file:
 mikem user without VLAN default VLAN - Quarantine - no IP address
 mikem1 user with VLAN Empleados - IP address range 10.0.21.0/24
 mikem2 user with VLAN ATI - IP address range 10.0.19.0/24
 *** Users file ***
 # users
 # This is an example of how to set up simple user for
 # AuthBy FILE.
 # The example user mikem has a password of fred, and will
 # receive reply attributes suitable for most NASs.
 # You can do many more interesting things. See the Radiator reference
 # manual for more details
 #
 # You can test this user with the command
 #  perl radpwtst

 mikem   User-Password=fred
 Service-Type = Framed-User,
 Tunnel-Medium-Type = 802,
 Tunnel-Type = VLAN

 mikem1  User-Password=fred
 Service-Type = Framed-User,
 Tunnel-Private-Group-ID = Empleados,
 Tunnel-Medium-Type = 802,
 Tunnel-Type = VLAN

 mikem2  User-Password=fred
 Service-Type = Framed-User,
 Tunnel-Private-Group-ID = ATI,
 Tunnel-Medium-Type = 802,
 Tunnel-Type = VLAN

 *** EOF users file ***

 We're doing that with Cisco WLCs without problems but in our case by
 sending the VLAN ID, not its name like for wired dot1x where Cisco IOS
 switches want the VLAN name:

 AddToReply Tunnel-Type=VLAN,\
Tunnel-Medium-Type=802, \
Tunnel-Private-Group-ID=123

 -- 
 ---
 Roberto Carlos Pantoja Valdizón
 Analista de Sistemas
 ATI/GDEI/LaGeo


 This message has been scanned for malware by Websense.
 www.websense.com http://www.websense.com/



 ___
 radiator mailing list
 radiator@open.com.au
 http://www.open.com.au/mailman/listinfo/radiator



 ***
 T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
 Handelsgericht Wien, FN 79340b
 ***
 Notice: This e-mail contains information that is confidential and may
 be privileged.
 If you are not the intended recipient, please notify the sender and then
 delete this e-mail immediately.
 ***


 Click here
 

Re: [RADIATOR] Radiator using WPA2-Enterprise and dynamic VLAN Assignment (Part 1)

[Sami Keski-Kasari]

/



 ___
 radiator mailing list
 radiator@open.com.au
 http://www.open.com.au/mailman/listinfo/radiator



 ***
 T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
 Handelsgericht Wien, FN 79340b
 ***
 Notice: This e-mail contains information that is confidential and may
 be privileged.
 If you are not the intended recipient, please notify the sender and then
 delete this e-mail immediately.
 ***


 Click here
 https://www.mailcontrol.com/sr/X7j9AwsBAS3GX2PQPOmvUmkxeMeR4%21FmwYL%21b%21gsSiAI7lo7et4NX6Fo9FCU0sXr2U9s6bVQO2bgE3KctAewCA==
 to report this email as spam.



 ___
 radiator mailing list
 radiator@open.com.au
 http://www.open.com.au/mailman/listinfo/radiator
 
 
 
 
 ___
 radiator mailing list
 radiator@open.com.au
 http://www.open.com.au/mailman/listinfo/radiator
 


-- 
Sami Keski-Kasari sam...@open.com.au

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] Radiator using WPA2-Enterprise and dynamic VLAN Assignment (Part 1)

[Roberto Pantoja]

 This message has been scanned for malware by Websense.
 www.websense.com http://www.websense.com/



 ___
 radiator mailing list
 radiator@open.com.au
 http://www.open.com.au/mailman/listinfo/radiator


 ***
 T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
 Handelsgericht Wien, FN 79340b
 ***
 Notice: This e-mail contains information that is confidential and may
 be privileged.
 If you are not the intended recipient, please notify the sender and then
 delete this e-mail immediately.
 ***


 Click here
 https://www.mailcontrol.com/sr/X7j9AwsBAS3GX2PQPOmvUmkxeMeR4%21FmwYL%21b%21gsSiAI7lo7et4NX6Fo9FCU0sXr2U9s6bVQO2bgE3KctAewCA==
 to report this email as spam.



 ___
 radiator mailing list
 radiator@open.com.au
 http://www.open.com.au/mailman/listinfo/radiator



 ___
 radiator mailing list
 radiator@open.com.au
 http://www.open.com.au/mailman/listinfo/radiator




-- 
---
Roberto Carlos Pantoja Valdizón
Analista de Sistemas
ATI/GDEI/LaGeo

___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

[RADIATOR] Radiator sotp to respond to request : stuck in a script : I/O error Interrupted

[Pascal Beauregard]

Hi,
yesterday we have experienced twice a situation where Radiator stops to respond 
to requests apparently because the server was stuck in the execution of a 
script.

Here is what we saw in the logfile :

Tue Jan 14 13:13:56 2014: DEBUG:  Deleting session for demk2801, 10.40.0.130, 1
Tue Jan 14 13:13:56 2014: DEBUG: Handling with Radius::AuthFILE:
Tue Jan 14 13:13:56 2014: DEBUG: Handling with EAP: code 2, 11, 43, 25
Tue Jan 14 13:13:56 2014: DEBUG: Response type 25
Tue Jan 14 13:13:56 2014: DEBUG: EAP Success, elapsed time 0.267233
Tue Jan 14 13:13:56 2014: DEBUG: EAP result: 0,
Tue Jan 14 13:13:56 2014: DEBUG: AuthBy FILE result: ACCEPT,
Tue Jan 14 13:13:56 2014: DEBUG: Running aeriusSecurise_VLAN: for user demk2801 
(Jan 14, 2014 13:13) : Accept
Tue Jan 14 13:13:56 2014: DEBUG: Running aeriusSecurise_VLAN: verify demk2801 
is memberOf... for VLAN selection
13:47
Tue Jan 14 13:24:23 2014: ERR: Error in PostAuthHook(): I/O Error Interrupted 
system call at /etc/radiator/hooks/ADI.pm line 111, GEN1 line 16081.

Here is what we have at line 111 of ADI.pm

#print  Bind LDAP session with user $ldapuser \n;
   my $mesg = $ldap-bind($ldapuser,
 password = pack('H*',$ldappass))
 or die $@;

Is there a way to make sure that if a bind does not work we exit the script 
after a period of time ?


__
Pascal Beauregard
Analyste en télécommunications
Service des Technologies de l'information
Université de Sherbrooke

Tél. : 819-821-7770
Courriel : pascal.beaureg...@usherbrooke.ca


___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Radiator on Linux using LDAP2, MS Active Directory, MSCHAP-V2

[Heikki Vatiainen]

On 10/15/2013 10:41 PM, Sevilla, Norman A wrote:

 The only function that we are unable to migrate successfully is 8021.x
 wireless authentication.  The Windows-based version used Authby LSA so
 the MSCHAP-V2 challenge worked successfully.  On the Linux-based system,
 Authby LDAP2 is finding my user account in AD but is failing with
 MSCHAP-V2 authentication failure.

Hello Norm,

the AD LDAP interface allows you to fetch a lot of information but it
does not expose the password or password hash. It appears to be
impossible to configure AD to do so. For MSCHAP-V2 you would need either
plain text password or NTHASH of password. Since neither are available
over LDAP from AD, this is why it fails.

 I’ve tried using the nt-hash
 conversion script in the goodies directory but I am not seeing
 ‘User-Password’ anywhere to be converted.  I’ve seen several threads
 stating that my best bet is to just stick to a Windows-based system but
 I’m hoping someone can help me figure out how to get this to work with
 on a Linux platform.

You would need to use AuthBy NTLM on Linux. This would provide you with
the authentication functionality.  If needed, you could then use AuthBy
LDAP2 for authorization (checking group memberships etc.).

Thanks,
Heikki

-- 
Heikki Vatiainen h...@open.com.au

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

[RADIATOR] RADIATOR issue with particular attribute (NAS-IPv6-Address)

[A . L . M . Buxey]

hi,

RADIATOR has a definition for the NAS-IPv6-Address attribute in
its dictionary file. 

ATTRIBUTE   NAS-IPv6-Address95  ipaddrv6

however, it appears that this attribute type (ipaddrv6) has
some interplay problem with the server. ie If you have a RADIUS packet
going through RADIATOR on a host that isnt doing IPv6 - ie it doesnt have
PERL Socket6 library installed, then the 18byte attribute is mangled
to 2 bytes. the result of that? other servers such as NPS will just silently 
drop the packet (well, it logs malformed RADIUS packet but remote servers
think server is dead). in a highly federated environment (eg eduroam)
this leads to quite elongated/obtuse issues. May I ask that this 
handling of the packet be seperated from IPv6 functionality (standard
IPv4 servers should just pass known packets through as is) - 
perhaps as simple as changing the type of that attribute?

many thanks

alan
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

[RADIATOR] Radiator Version 4.12.1 released

[Heikki Vatiainen]

We are pleased to announce the release of Radiator version 4.12.1

This version contains one bug fix and one enhancement. A bug in AuthBy
SQL prevented it from loading with certain configurations.

As usual, the new version is available to current licensees from:
http://www.open.com.au/radiator/downloads/

and to current evaluators from:
http://www.open.com.au/radiator/demo-downloads

Licensees with expired access contracts can renew at:
http://www.open.com.au/renewal.php

An extract from the history file
http://www.open.com.au/radiator/history.html is below:

-

Revision 4.12.1 (2013-09-17)

Fixed a bug that prevented AuthBy SQL from loading when it was defined
outside of Realm or Handler.

Unknown Diameter attribute types are now logged with a warning when
Diameter dictionaries are loaded. Diameter encoder and decoder now use
Integer32 and Integer64 for signed 32 bit and 64 bit types instead of
Signed32 and Signed64.


-- 
Heikki Vatiainen h...@open.com.au

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] Radiator LoadBalancing Optimization

[Sami Keski-Kasari]

Hello Michael,

CachePasswords doesn't work with EAP, it works only with PAP 
authentication. So it won't help you in this situation.

My advice is that you should add more hosts for authentication or if you 
have a lot of accounting traffic then it might a good solution if you 
have separate instances for accounting and authentication.

Best Regards,
  Sami

On 09/12/2013 05:37 PM, Michael Hulko wrote:
 In a previous discussion regarding Loadbalancing radius requests, we 
 instituted the AuthBy EAPBALANCE method to proxy requests to departmental 
 radius servers.  We have been running this method for close to 6 months and 
 have been pretty satisfied with the result.  Of late, however, the client 
 traffic has increased, and the time for an authentication to complete is a 
 tad longer than the users are willing to accept.  My reading of the 
 documentation provided by OSC, suggests the use of CachePasswords; 
 CacheOnNoReply; and CachePasswordExpiry would assist in the performance.

 I understand that the trade-off of implementing these features is memory.  So 
 to that end, first, is anyone using these parameters?.  What is the number of 
 clients supported and related memory usage?  I anticipate approx. 3-4K 
 simultaneous users for the particular AuthBy clause.  What would be the 
 recommended Password expiry timer be?

 Any info would be appreciated.  Below is the current config snippet of the 
 AuthBy we are using.  User connections are retried after a 45 min. period.

 #IVEY
 # Proxies auth requests to the IVEY IAS radius servers using a loadbalance 
 algorithm.
 AuthBy EAPBALANCE
   Identifier IVEY
  Retries 3
  RetryTimeout 5
  FailureBackoffTime 20
  AuthPort 1645
  AcctPort 1646
  Secret x
  LocalAddress xx
   #
  Host xxx
  /Host
   #
  Host 
  /Host
   #
  Host 
  /Host

 /AuthBy


 The last server is the slower of the 3 hosts available which I believe is the 
 bottleneck.

 Thanks


 Michael Hulko
 Network Analyst

 Western University Canada
 Network Operations Centre
 Information Technology Services
 1393 Western Road, SSB 3300CC
 London, Ontario  N6G 1G9

 tel: 519-661-2111 x81390
 e-mail: mihu...@uwo.ca mailto:mihu...@uwo.ca





 ___
 radiator mailing list
 radiator@open.com.au
 http://www.open.com.au/mailman/listinfo/radiator



-- 
Sami Keski-Kasari sam...@open.com.au

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] Radiator LoadBalancing Optimization

[Michael Hulko]

Thanks for the response too bad though.  Unfortunately, we can only have 
one radius server instance per NAS (and a backup), but this particular NAS 
supports the radius proxy clients which are the problem.

M

On 2013-09-13, at 6:39 AM, Sami Keski-Kasari wrote:

 Hello Michael,
 
 CachePasswords doesn't work with EAP, it works only with PAP authentication. 
 So it won't help you in this situation.
 
 My advice is that you should add more hosts for authentication or if you have 
 a lot of accounting traffic then it might a good solution if you have 
 separate instances for accounting and authentication.
 
 Best Regards,
 Sami
 
 On 09/12/2013 05:37 PM, Michael Hulko wrote:
 In a previous discussion regarding Loadbalancing radius requests, we 
 instituted the AuthBy EAPBALANCE method to proxy requests to departmental 
 radius servers.  We have been running this method for close to 6 months and 
 have been pretty satisfied with the result.  Of late, however, the client 
 traffic has increased, and the time for an authentication to complete is a 
 tad longer than the users are willing to accept.  My reading of the 
 documentation provided by OSC, suggests the use of CachePasswords; 
 CacheOnNoReply; and CachePasswordExpiry would assist in the performance.
 
 I understand that the trade-off of implementing these features is memory.  
 So to that end, first, is anyone using these parameters?.  What is the 
 number of clients supported and related memory usage?  I anticipate approx. 
 3-4K simultaneous users for the particular AuthBy clause.  What would be the 
 recommended Password expiry timer be?
 
 Any info would be appreciated.  Below is the current config snippet of the 
 AuthBy we are using.  User connections are retried after a 45 min. period.
 
 #IVEY
 # Proxies auth requests to the IVEY IAS radius servers using a loadbalance 
 algorithm.
 AuthBy EAPBALANCE
  Identifier IVEY
 Retries 3
 RetryTimeout 5
 FailureBackoffTime 20
 AuthPort 1645
 AcctPort 1646
 Secret x
 LocalAddress xx
  #
 Host xxx
 /Host
  #
 Host 
 /Host
  #
 Host 
 /Host
 
 /AuthBy
 
 
 The last server is the slower of the 3 hosts available which I believe is 
 the bottleneck.
 
 Thanks
 
 
 Michael Hulko
 Network Analyst
 
 Western University Canada
 Network Operations Centre
 Information Technology Services
 1393 Western Road, SSB 3300CC
 London, Ontario  N6G 1G9
 
 tel: 519-661-2111 x81390
 e-mail: mihu...@uwo.ca mailto:mihu...@uwo.ca
 
 
 
 
 
 ___
 radiator mailing list
 radiator@open.com.au
 http://www.open.com.au/mailman/listinfo/radiator
 
 
 
 -- 
 Sami Keski-Kasari sam...@open.com.au
 
 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.



Michael Hulko
Network Analyst

Western University Canada
Network Operations Centre
Information Technology Services
1393 Western Road, SSB 3300CC
London, Ontario  N6G 1G9

tel: 519-661-2111 x81390
e-mail: mihu...@uwo.ca mailto:mihu...@uwo.ca





___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

[RADIATOR] Radiator LoadBalancing Optimization

[Michael Hulko]

In a previous discussion regarding Loadbalancing radius requests, we instituted 
the AuthBy EAPBALANCE method to proxy requests to departmental radius 
servers.  We have been running this method for close to 6 months and have been 
pretty satisfied with the result.  Of late, however, the client traffic has 
increased, and the time for an authentication to complete is a tad longer than 
the users are willing to accept.  My reading of the documentation provided by 
OSC, suggests the use of CachePasswords; CacheOnNoReply; and 
CachePasswordExpiry would assist in the performance.

I understand that the trade-off of implementing these features is memory.  So 
to that end, first, is anyone using these parameters?.  What is the number of 
clients supported and related memory usage?  I anticipate approx. 3-4K 
simultaneous users for the particular AuthBy clause.  What would be the 
recommended Password expiry timer be? 

Any info would be appreciated.  Below is the current config snippet of the 
AuthBy we are using.  User connections are retried after a 45 min. period.

#IVEY
# Proxies auth requests to the IVEY IAS radius servers using a loadbalance 
algorithm.
AuthBy EAPBALANCE
Identifier IVEY
Retries 3
RetryTimeout 5  
   
FailureBackoffTime 20
AuthPort 1645
AcctPort 1646
Secret x
LocalAddress xx
 # 
Host xxx
/Host
 # 
Host 
/Host
 # 
Host 
/Host

/AuthBy


The last server is the slower of the 3 hosts available which I believe is the 
bottleneck.

Thanks


Michael Hulko
Network Analyst

Western University Canada
Network Operations Centre
Information Technology Services
1393 Western Road, SSB 3300CC
London, Ontario  N6G 1G9

tel: 519-661-2111 x81390
e-mail: mihu...@uwo.ca mailto:mihu...@uwo.ca





___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

[RADIATOR] Radiator Version 4.12 released

[Heikki Vatiainen]

We are pleased to announce the release of Radiator version 4.12

This version contains two new modules, AuthBy DUO and AuthBy DIAMETER,
some significant new features and bug fixes.

As usual, the new version is available to current licensees from:
http://www.open.com.au/radiator/downloads/

and to current evaluators from:
http://www.open.com.au/radiator/demo-downloads

Licensees with expired access contracts can renew at:
http://www.open.com.au/renewal.php

An extract from the history file
http://www.open.com.au/radiator/history.html is below:

-

Revision 4.12 (2013-09-06)

Improvements to EAP-MD5 handling: in the event of an authentication
failure, the reason messages are more descriptive of the reason why.

Updated Mikrotic VSAs in dictionary.

Added a number of VSAs for Alcatel-ESAM to dictionary.

Fixed a potential crash if there were many unfinished EAP-GTC
authentication conversiations through AuthBy ACE. Reported by Richard
Fairhall.

Added support for a number of new check items for AuthBy SQL:
Max-All-Session, Max-Hourly-Session, Max-Daily-Session,
Max-Monthly-Session, Max-All-Octets, Max-All-Gigawords,
Max-Hourly-Octets, Max-Hourly-Gigawords, Max-Daily-Octets,
Max-Daily-Gigawords, Max-Monthly-Octets, Max-Monthly-Gigawords. AuthBy
SQL supports the foillowing corrsponding configurable queries:
AcctTotalQuery, AcctTotalSinceQuery, AcctTotalSinceQuery,
AcctTotalSinceQuery, AcctTotalOctetsQuery, AcctTotalGigawordsQuery,
AcctTotalOctetsSinceQuery, AcctTotalGigawordsSinceQuery,
AcctTotalOctetsSinceQuery, AcctTotalGigawordsSinceQuery,
AcctTotalOctetsSinceQuery, AcctTotalGigawordsSinceQuery. With the kind
assistance of Richard Fairhall.

Updated AuthLog SYSLOG so that it honours the same %0 and %1 in
SuccessFormat and FailureFormat as other loggers.

Changed all instances of the poorly defined 'octets' type attributes
in dictionary to 'binary'.

Added F5 BigIP VSAs to dictionary, per
http://support.f5.com/kb/en-us/solutions/public/11000/400/sol11431.html,
as sent by Alexander Hartmaier.

Added further Trapeze VSAs for MSS 8.0 and later to dictionary, as
sent by Vandenbroucke Luc.

Altered AuthBy RADIUS and AuthBy RADSEC handleReply so that
failedRequests and start_failure_grace_time are updated even if there
is no $op-{rp}.

Performance improvements for TTLS and PEAP: when used with OpenSSL
1.0.1 and later, NetSSLeay 1.52+latest patches and later, the native
OpenSSL tls1_PRF function is used.

Altered AuthBy RADIUS and AuthBy RADSEC handleReply so that in the
event of an Access-Reject from a proxied request, AuthLog* can log the
actual Reply-Message from the reply instead of 'Proxied'. Requested by
David Zych.

Improvements to AuthBy RADIUS and AuthBy RADSEC to detect obvious
routing loops and to ignore attempts to proxy a packet to the same
BindAddress/port a packet was received on.

Fixed a problem in SessionDatabase SQL that could cause a crash if
UpdateQuery is defined and an Accounting Alive packet was
received. Reported by Chris Millington.

Improvements to AuthBy SQL AuthColumnDef. Can now have a trailing ,
formatted keyword in an AuthColumnDef. This will cause the value
retrieved from the database in that column to be subject to special
character processing before its value is used, and can therefore
contain %{something} forms which will be replaced at authentication
time. The general format is now:
  AuthColumnDef n, attributename, type[, formatted]

 For example:
  AuthColumnDef 1, Filter-Id, reply, formatted

Improvements to AuthBy LDAP2 AuthAttrDef. Can now have a trailing ,
formatted keyword in an AuthAttrDef. This will cause the value(s)
retrieved from LDAP to be subject to special character processing
before its value is used, and can therefore contain %{something} forms
which will be replaced at authentication time. The general format is
now:
  AuthAttrDef ldapattributename, radiusattributename, type[, formatted]

 For example:
  AuthAttrDef filter, Filter-Id, reply, formatted

All configuration parameters of type 'flag' can now use special
characters. This is especially useful to be able to control flags with
GlobalVar's.

Added example hook to hooks.txt: showing a way to call PostAuthHook
with additional fixed arguments set at startup time.

Fixed some typos in DiaClient that incorrectly mentioned RadSec.

AuthBy RADIUS and AuthBy RADSEC now remove unnecessary Timestamp
attribute (meant for internal use only) from proxied requests.

Improvements to Handler: the reply packet is not set if there is
already one present. Useful when AuthBy HANDLER or a hook redespatches
a request to another Handler: reply items added by earlier Handlers
and AuthBys will not be lost.

Added Ericsson redback VSAs 207-213 to dictionary. Also added some
alternate values for RB-Framed-IPv6-Prefix, RB-Framed-IPv6-Route,
RB-Framed-IPv6-Pool, as used by SmartEdge.

Added A-10 Networks VSAs to dictionary.

Improvements to SYSLOG loggers to be more compatible with later
versions of 

Re: [RADIATOR] Radiator and radsecproxy, status-server and failover algo, one step forward

[A . L . M . Buxey]

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

[Stefan Winter]

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] Radiator and radsecproxy, status-server and failover algo, one step forward

[Karl Gaissmaier]

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] Radiator and radsecproxy, status-server and failover algo, one step forward

[A . L . M . Buxey]

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

[RADIATOR] Radiator and radsecproxy, status-server and failover algo, one step forward

[Karl Gaissmaier]

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:  4160179224193233154132+1902O227f205
 Attributes:
 Message-Authenticator = 
 
 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:  24723026254245134C128219p216223I
 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:  0217255198172F232131401552162f1{189
 Attributes:
 Message-Authenticator = 
 
 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;136k1879s#200v232208137150Wv
 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

[Karl Gaissmaier]

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:  U182136130!141232175230y)23442399y
 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 = 200221uni.ulm.test@akad
 Message-Authenticator = 231+b159G1352147185$N192tw205]
 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:  246223219M179S234VE2625323625251r17
 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

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

[Karl Gaissmaier]

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

Re: [RADIATOR] Radiator + libtnc + tpm platform authentication IMC

[Heikki Vatiainen]

On 07/11/2013 07:31 PM, Florian Kabus wrote:

 We would like to authenticate Win 7 endpoints with certificates stored 
 on the TPM and thus based on the identity deny or permit access to the 
 enterprise network.

Hello Florian,

this sounds like a normal EAP-TLS setup from the RADIUS/EAP server's
perspective. Please see goodies/eap_tls.cfg for EAP-TLS examples. I do
not think it matters to the servers side whether the private key is
stored in a TPM chip or in a file.

Thanks,
Heikki

-- 
Heikki Vatiainen h...@open.com.au

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] Radiator + libtnc + tpm platform authentication IMC

[Florian Kabus]

Am 12.07.2013 11:28, schrieb Heikki Vatiainen:
 this sounds like a normal EAP-TLS setup from the RADIUS/EAP server's
 perspective. Please see goodies/eap_tls.cfg for EAP-TLS examples. I do
 not think it matters to the servers side whether the private key is
 stored in a TPM chip or in a file.

Hello,

thanks for the reply. That´s right. As far is I know Radiator should 
support EAP-TNC inside a TTLS-Tunnel. So the servers side should be fine 
(not tested yet!).

More of a problem is the _Windows_ client side implementation with 
apropriate libraries like a TNC-compatible Supplicant, apropriate TSS 
and in particular an IMC to check platform identity.

I just asking if there are possibly any experiences here with libtnc and 
an implementation like that, because I´m a little bit lost.

Thanks,
Flo
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

[RADIATOR] Radiator + libtnc + tpm platform authentication IMC

[Florian Kabus]

Hello,

I know this is maybe not the right place to ask, but as my last hope:

Are there any experiences, resources, hints regarding implementation of 
an TPM platform authentication on windows clients in conjunction with 
radiator?

classic scenario:
We would like to authenticate Win 7 endpoints with certificates stored 
on the TPM and thus based on the identity deny or permit access to the 
enterprise network.

Regards,

Florian Kabus
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator