[strongSwan] Strongswan client support for the XAUTH_PASSCODE attribute

[Noel Kuntze]

Hi,

Yw.

There's also no support for dynamic prompting for EAP credentials.
I envisioned to implement that using VICI some time later. It'd be the natural choice.
Switching to IKEv2 won't solve the problem for you right now.

Kind regards

Noel

Am 01.04.20 um 19:10 schrieb Mikael Nordstrom:
> OK,
> 
> Thanks anyway for the quick reply.
> 
> The Juniper has IKEv2 support and the RSA SecurID box has a built-in radius server
> so maybe that is the way to go with this.
> 
> Thanks again,
> 
> /Mikael
> 
> On 2020-04-01 18:30, Noel Kuntze wrote:
>> Hi,
>>
>> There's just no frontend to ask dynamically for such credentials yet. You'd need to implement that, then you can dynamically prompt for the passcode (after hooking up X_CODE the same way as X_USER is). Other than that, there are no provisions for X_CODE or anything else. The code base wouldn't be extended particularly for X_CODE because IKEv1 is deprecated.
>>
>> Kind regards
>>
>> Noel
>>
>> Am 01.04.20 um 18:22 schrieb MN Lists:
>>> Hi,
>>>
>>> This is my first message to the list so sorry in advance if the answer is obvious or well-known.
>>> Also, sorry if my terminology is messed up, hopefully you will understand my issue.
>>>
>>> I have a Juniper ScreenOS gateway that does IKEv1 VPNs with RSA and then XAuth authentication
>>> towards an RSA SecurID box. SecurID is an MFA implementation with hardware tokens that display
>>> a new 6-digit number every 60 seconds.
>>>
>>> Clients can connect to it from Mac OS X with a client called NCP Secure Entry and from Windows
>>> with the Shrewsoft client. In the past vpnc on Linux was working but as it has not been developed
>>> since a long time and doesn't support newer algorithms, I'm looking for an alternative and
>>> Strongswan looks promising.
>>>
>>> So far I have been able to get IKE phase1 up but it fails on XAuth. It looks as if the gateway
>>> is sending a request for X_USER and X_CODE but charon is responding with just X_USER. Here is
>>> a log excerpt:
>>>
>>> apr 01 17:48:08 phoenix charon-debug[21177]: 02[IKE] authentication of 'gw.example.com' with RSA_EMSA_PKCS1_NULL successful
>>> apr 01 17:48:08 phoenix charon-debug[21177]: 02[IKE] activating new tasks
>>> apr 01 17:48:08 phoenix charon-debug[21177]: 02[IKE] nothing to initiate
>>> apr 01 17:48:11 phoenix charon-debug[21177]: 07[NET] received packet: from 212.112.174.86[4500] to 172.20.33.34[4500] (92 bytes)
>>> apr 01 17:48:11 phoenix charon-debug[21177]: 07[IKE] next IV for MID 3123281050 => 16 bytes @ 0x7f0304001ed0
>>> apr 01 17:48:11 phoenix charon-debug[21177]: 07[IKE]    0: 51 2C 54 DC D7 31 2D 5F 5D 84 00 10 81 42 88 2B  Q,T..1-_]....B.+
>>> apr 01 17:48:11 phoenix charon-debug[21177]: 07[ENC] parsed TRANSACTION request 3123281050 [ HASH CPRQ(X_TYPE X_USER X_CODE) ]
>>> apr 01 17:48:11 phoenix charon-debug[21177]: 07[IKE] Hash => 32 bytes @ 0x7f03040026b0
>>> apr 01 17:48:11 phoenix charon-debug[21177]: 07[IKE]    0: 87 1C CA 53 F3 1A 81 40 E3 68 E8 78 EA 1C CF CE  ...S... at .h.x....
>>> apr 01 17:48:11 phoenix charon-debug[21177]: 07[IKE]   16: B3 53 17 C6 8C 1B E7 F3 CA DD 50 DC F7 60 97 DD  .S........P..`..
>>> apr 01 17:48:11 phoenix charon-debug[21177]: 07[IKE] next IV for MID 3123281050 => 16 bytes @ 0x7f02f8005600
>>> apr 01 17:48:11 phoenix charon-debug[21177]: 07[IKE]    0: 33 C2 3E 9C 64 14 4C 87 85 C2 1B 26 45 84 2D FF  3.>.d.L....&E.-.
>>> apr 01 17:48:11 phoenix charon-debug[21177]: 07[IKE] Hash => 32 bytes @ 0x7f0304001ed0
>>> apr 01 17:48:11 phoenix charon-debug[21177]: 07[IKE]    0: CB A7 62 8F 3F E0 98 7B 92 75 7F AE 70 B6 E4 0C  ..b.?..{.u..p...
>>> apr 01 17:48:11 phoenix charon-debug[21177]: 07[IKE]   16: 9E B8 66 14 91 79 63 45 5C 9E B1 EF FD B3 5F B9  ..f..ycE\....._.
>>> apr 01 17:48:11 phoenix charon-debug[21177]: 07[ENC] generating TRANSACTION response 3123281050 [ HASH CPRP(X_USER) ]
>>>
>>> Relevant swanctl authentication and secret sections are:
>>>
>>> connections {
>>>     conn1 {
>>>         local-2 {
>>>             auth = xauth-generic
>>>             xauth_id = xauthuser
>>>         }
>>>     }
>>> }
>>>
>>> secrets {
>>>         xauth-1 {
>>>                 id-1 = xauthuser
>>>                 secret = 1234556677
>>>         }
>>>
>>> Is this a well known deficiency in strongswan or is there some configuration that can make
>>> this work?
>>>
>>> I'm happy to supply any further information that could help resolve this.
>>>
>>> Many thanks,
>>> /Mikael
>>>
>>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.strongswan.org/pipermail/users/attachments/20200401/127a391a/attachment-0001.sig>