[strongSwan] StrongSwan eap-radius with EAP-TLS, ASN.1 Radius-Username

[Stefan Hartmann]

Hi,

thank you for yout thoughts.

Yes this is a workaround, I created policy.d/strongswan with 
filter_username_custom in it.

But it would be nice to have a readable and sanitized subject DN as 
User-Name attribute.

And what about proxying the request to another home-server with ASN.1 
raw hex User-Name.

Eventuelly I will test EAP-TLS with cisco IOS or ASA and look how they 
mangle the username.


-- 
stefanh
Ingenieurbuero fuer IT/EDV und Netzwerktechnik - Stefan Hartmann


On 03.03.20 15:40, Michael Schwartzkopff wrote:
> On 03.03.20 15:06, Stefan Hartmann wrote:
>> Hello list,
>>
>> I 'm trying to set up a VPN Remote Access aka Road Warrior with
>> EAP-TLS similar as the scenario
>> https://www.strongswan.org/testing/testresults/swanctl/rw-eap-tls-radius/.
>>
>> I want to switch from Cisco ASA to Strongswan.
>>
>> I use strongswan 5.8.1-1 on Debian Bullseye.
>>
>> My Freeradius is 3.0.17+dfsg-1.1 on a Debian Buster and is already
>> running a few years as KDC/LDAP/RADIUS etc:
>>      used for WLAN AAA EAP-TLS, EAP-TTLS/PAP, PEAP-MSCHAPv2
>>      used as AAA server for Cisco ASA ie authn via PAP
>>      used as KDC ...
>>
>> The first setup with strongswan functions perfectly with EAP-TTLS with
>> inner EAP-GTC against the Kerberos KDC.
>>
>>
>> The setup for EAP-TLS functions only, if I comment out the
>> filter_username in sites-enabled/default, otherwise the passed
>> username from strongswan to the AAA server is rejected.
>>
>> # freeradius -X
>> ...
>> } # if (&User-Name =~ / /)  = reject
>> (0)       } # if (&User-Name)  = reject
>> (0)     } # policy filter_username = reject
>> (0)   } # authorize = reject
>> (0) Invalid user (Rejected: User-Name contains whitespace): [0??1?0
>> ??U????DE1I0G??U? ?@Ingenieurbuero fuer IT/EDV und Netzwerktechnik -
>> Stefan Hartmann1?0???U????Users1?0???U??? testuser-ldap] (from client
>> BULLSEYE port 5 cli 172.31.201.100[500])
>>
>>
>> Analyzing with Wireshark shows, that the username is the passed
>> ASN.1-Subject-DN from the certificate:
>> 0000        30 81 81 31 0b 30  09 06 03 55 04 06 13 02   ..0..1.0
>> ...U....
>> 0010  44 45 31 49 30 47 06 03  55 04 0a 0c 40 49 6e 67   DE1I0G..
>> U... at Ing
>> 0020  65 6e 69 65 75 72 62 75  65 72 6f 20 66 75 65 72   enieurbu ero
>> fuer
>> 0030  20 49 54 2f 45 44 56 20  75 6e 64 20 4e 65 74 7a    IT/EDV  und
>> Netz
>> ...
>>
>>
>> # strongswan config
>> # VPN-Gw swanctl.conf
>> connections {
>>      RA-SRV4_IKE2-AUTHN-EAP {
>>      ...
>>      local {
>>          auth = pubkey
>>      certs = BULLSEYE_SAN-DNS-email.cert.pem
>>          }
>>      remote {
>>      auth = eap-radius
>>      id = "C = DE, O = Ingenieurbuero fuer IT/EDV und Netzwerktechnik -
>> Stefan Hartmann, OU = Users, CN = *"
>>          }
>>      ...
>>
>>
>> # Roadwarrior
>> connections {
>>      RA-KLIENT4_IKE2-AUTHN-EAP {
>>      ...
>>      local {
>>      auth = eap-tls
>>      certs = testuser-ldap.cert.pem
>>      aaa_id = "C = DE, O = Ingenieurbuero fuer IT/EDV und
>> Netzwerktechnik - Stefan Hartmann, OU = CA, CN = srv-kdc.hafenthal.de"
>>
>>      # testing
>>      #id = "C = DE, O = Ingenieurbuero fuer IT/EDV und Netzwerktechnik
>> - Stefan Hartmann, OU = Users, CN = testuser-ldap"
>>      #id = testuser-lokal at hafenthal.de
>>      
>>         }
>>
>>
>> Can I configure strongswan client or server or eap-radius-plugin, that
>> it passes either the subject-DN in ASCII or the SubjAltName email?
>>
>> The scenario
>> https://www.strongswan.org/testing/testresults/swanctl/rw-eap-tls-radius/
>> shows also the ASN.1 raw username, therefore I think, this is intended.
>>
>> A possible workaround:
>> write a freeradius policy.d/filter_strongswan unlang function which
>> transforms the username and then do the filter_username check.
>>
>>
>> Nb. With a fake certificate you can pass arbitrarily hex code to the
>> freeradius daemon, from every user on the inet to the auth-server ie
>> heart of your site! This could be/become a nice attack vector - this
>> on my view as a pentester!
>>
>>
>> Thanks for your thoughts and replies!
>>
> 
> Hi,
> 
> 
> RADIUS does not expect a whitespace in the username. strongswan passes
> the ID on the the radius server. In your case is has whitespace. The
> policy filter in freeradius kicks in and rejects the request.
> 
> I'd improve the policy filter in freeradius to accept whitespace IF the
> NAS is your strongswan. Please see the debug output of freeradius for
> the NAS attribute. So you can update your filter like:
> 
> if (&NAS-Identifier == "strongswan") {
> 
>    other policy tests except the whitespace"
> 
> } else {
> 
>   all original filter
> 
> }
> 
> 
> Please see the file /etc/freeradius/3.0/policy.d/filter for the
> preprocess username filter.
> 
> 
> Mit freundlichen Grüßen,
>