[strongSwan] IKEv1 XAuth EAP Plugin

[Brian O'Connor]

I have the XAuth EAP Plugin enabled in my IPsec VPN responder, along
with a number of eap plugins.  I did not build this version of strongSwan
(5.2.1) but downloaded it from a Raspberry Pi repository.

My /etc/ipsec.secrets file contains entries similar to:

Fred  :  EAP  "1234567"

fred   :  XAUTH  "deadbeef1234567"

Please note the different capitalisation of the letter f for the two different
usernames.


My iPhone 4 Cisco IPsec VPN client has an X.509 entity certificate
and is configured with username=fred and password=1234567

 My /etc/ipsec.conf file is configured as follows:

conn CiscoIPSec
        keyexchange=ikev1
        # forceencaps=yes
        rightauth=pubkey
        rightauth2=xauth
        auto=add

As the iPhone password is not the same as the XAUTH password in
/etc/ipsec.secrets, I was not expecting authentication to succeed.

However [1] notes it may not be this simple.

The /xauth-eap/ plugin is an IKEv1 XAuth server backend. It requests
username/password XAuth credentials and verifies them against
any password based IKEv2 EAP plugin.

My experience suggests the password is checked but not the
username.  I was not expecting Fred's password to successfully
authenticate a request from user fred (note the lower case f).

The following log output suggests username is compared along with password.

01[ENC] <CiscoIPSec|58> generating TRANSACTION request 2160949662 [ HASH CPRQ(X_USER X_PWD) ]
11[ENC] <CiscoIPSec|58> parsed TRANSACTION response 2160949662 [ HASH CPRP(X_USER X_PWD) ]
11[IKE] <CiscoIPSec|58> XAuth authentication of 'fred' successful

The other possible reason for my observed behaviour is that a truncated password is used in the hash
calculation,  but I would doubt that is the case.

My iPhone X.509 certificate has the serverAuth flag set as required by Windows 7 but I don't think
this would explain what I am seeing.

Any help appreciated, thank you.


[1] https://wiki.strongswan.org/projects/strongswan/wiki/XAuthEAP

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20160928/5550fcfb/attachment.html>