[RADIATOR] Bugreport: OTP... PAP

[Patrick Honing]

Hello,

Due to the update of IOS on the iPhone and de OS on the Mac which uses TLSv1.2 we upgraded our RADIUS setup.
The RADIUS-setup is used for our eduroam wireless network as well as for a VmWare VDI environment.

We are using a RedHat Enterprise Linux 5 environment for our RADIUS servers. We first updated the RHEL-delivered perl-Net-SSleay package with a self-build package at version 1.70 (RHEL version was 1.30). Secondly we updated Radiator from 4.08 to 4.15.

After this update our test mac (with new OS) could still not connect to the wireless network..The radiator debug log stated (inner authentication):

Mon Sep 14 14:15:47 2015: DEBUG: Handling request with Handler 'TunnelledByTTLS=1', Identifier ''
Mon Sep 14 14:15:47 2015: DEBUG:  Deleting session for , 145.74.191.244,
Mon Sep 14 14:15:47 2015: DEBUG: Handling with Radius::AuthLDAP2:
Mon Sep 14 14:15:47 2015: DEBUG: Handling with EAP: code 2, 0, 16, 1
Mon Sep 14 14:15:47 2015: DEBUG: Response type 1
Mon Sep 14 14:15:47 2015: ERR: Could not load EAP module Radius::EAP_: Can't locate Radius/EAP_.pm in @INC (@INC contains: . /usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.8 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.8 /usr/lib/perl5/vendor_perl /usr/lib/perl5/5.8.8/i386-linux-thread-multi /usr/lib/perl5/5.8.8 .) at (eval 103) line 3.

Mon Sep 14 14:15:47 2015: DEBUG: EAP result: 1, Unsupported default EAP Response/Identity PAP
Mon Sep 14 14:15:47 2015: DEBUG: AuthBy LDAP2 result: REJECT, Unsupported default EAP Response/Identity PAP
Mon Sep 14 14:15:47 2015: INFO: Access rejected for : Unsupported default EAP Response/Identity PAP
Mon Sep 14 14:15:47 2015: DEBUG: Returned TTLS tunnelled Diameter Packet dump:
Code:       Access-Reject
Identifier: UNDEF
Authentic:  <183><170>L<23><10><234><237>x<9>@$m"<154><4>S
Attributes:
       Reply-Message = "Request Denied"

Because PAP was mentioned in the error, we removed (after trying a few dozen other things) PAP from out EAPtypes (was there historically and isn’t used anymore) as in:

# Handler voor TTLS
<Handler TunnelledByTTLS=1>
   <AuthBy LDAP2>
       Host ldap.han.nl <http://ldap.han.nl/>
       BaseDN dc=han,dc=nl
       SearchFilter (& (uid=%1) (nlHANsubscription=Wireless))
       HoldServerConnection
       EAPType MSCHAP-V2
       UsernameAttr uid
       PasswordAttr HASH
       UsernameMatchesWithoutRealm
       AuthDN uid=radius,,dc=mydomain,dc=com
       AuthPassword **********
   </AuthBy>

This fixes the problem with the mac, but keeps me wondering why PAP gives such a nasty error..

All fine.. Testing the Mac went fine so updating our production RADIUS servers… But this broke our VDI config:

# Handlers voor VDI
<Handler State=OTP>
   <AuthBy OTP>
       PasswordPattern 999999
       ChallengeHook file:"/etc/radius/scripts/otpsms.pl"
       AddToReplyIfNotExist State="OTP"
       StripFromReply Reply-Message
       AddToReply Reply-Message="Geef de code op die u via SMS ontvangen heeft"
   </AuthBy>
</Handler>

<Handler Client-Identifier=vdi>
   RewriteUsername s/^([^@]+).*/$1/
   RewriteUsername tr/A-Z/a-z/
   AuthByPolicy ContinueWhileAccept
   <AuthBy LDAP2>
       Host ldap.mydomain.com <http://ldap.mydomain.com/>
       BaseDN dc=mydomain,dc=com
       ServerChecksPassword
       HoldServerConnection
   </AuthBy>
   <AuthBy OTP>
       PasswordPattern 999999
       ChallengeHook file:"/etc/radius/scripts/otpsms.pl"
       AddToReplyIfNotExist State="OTP"
       StripFromReply Reply-Message
       AddToReply Reply-Message="Geef de code op die u via SMS ontvangen heeft"
   </AuthBy>
</Handler>

We are using 2-factor authentication (with OTP via SMS) for VDI using the AuthOTP module. Our sms-scripts looks like this:

# This hook creates and SMS an one time password (OTP)

use IO::Socket;
use Net::LDAP;

sub {
   my ($self, $user, $p, $context) = @_;
   my $password = $self->generate_password();
   my $ldap = Net::LDAP->new('ldap.mydomain.com <http://ldap.mydomain.com/>') or die "$@";
   my $res = $ldap->search(
       base    => "dc=mydomain,dc=com",
       scope   => "sub",
       filter  => "(uid=$user)",
       attrs   => ['MOBILEPHONE']
   );
   if ($res->count) {
       my $ent = $res->entry(0);
       my $gsm = $ent->get_value("MOBILEPHONE");
       if ($gsm) {
           my $sock = IO::Socket::INET->new('smsserver.mydomain.com <http://smsserver.mydomain.com/>:9988') or die "Can't bind : $@\n";
           die unless ($sock->getline =~ "^SMS SERVER");
           print $sock "auth ******\n";
           die unless ($sock->getline =~ "^OK:");
           print $sock “sendsms ".$gsm." Next response: ".$password."\n";
           die unless ($sock->getline =~ "^OK:");
           print $sock "exit\n";
           $context->{otp_password} = $password;
       }
   }
}

After update the result was always: 'OTP Authentication failed: ()’….

Digging into the code of Radiator (debug log didn’t give any hint) and adding some more debug messages to AuthOTP.pm revealed the problem.

A piece of code from AuthOTP.pm:

#####################################################################
# $submitted_pw is the password being authenticated
# $pw is the correct password if known
# $user is the user name to be authenticated
sub check_plain_password
{
   my ($self, $user, $submitted_pw, $pw, $p, $encrypted) = @_;

   return ($main::ACCEPT) if $self->{NoCheckPassword};

   my $context = &Radius::Context::get("otp:$user", $self->{ContextTimeout});
   if ($submitted_pw eq '')
   {
       # First time, issue a challenge containing the OTP
       # challenge string

Here $submitted_pw is checked, and if empty (first authentication request), an OTP is generated. If not empty, the submitted password is checked with the saved (one time) password….

The problem: since the update of Radiator, the $submitted_pw isn’t empty the first time.. It holds the actual user password. So the check always fails.

In our setup VDI uses PAP for authentication, so above 2 scenario’s (weird error with EAP/PAP and VDI/OTP) both seem to have issue’s with the (new?) PAP implementation in the new Radius server. AuthOTP.pm seems not to have been changed much since the old (working) version.

A 6-digit user-password is not allowed by policy at our institute, so as a work-around I changed the check to:

if (!($submitted_pw =~ /^[0-9]{6}$/))

This is just a (dirty) fix, so I am looking forward for a more structural fix for this problem…

Kind Regards,
Patrick Honing
HAN University, NL
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.open.com.au/pipermail/radiator/attachments/20150924/b2a3d161/attachment.html