[Swan] Libreswan client to Juniper XAUTH + ModeCfg (was:Libreswan and USER FQDN IKE IDs)

mnlists at frimail.net mnlists at frimail.net
Wed Mar 25 13:42:53 UTC 2020


Changed subject on this thread...

On 2020-03-21 19:38, MN Lists wrote:
> On 2020-03-21 02:32, Paul Wouters wrote:
>> On Fri, 20 Mar 2020, MN Lists wrote:
>>
>>>> try: ipsec whack --initiate --name <con>
>>>> You can also, if you put the leftusername= back, add the password to
>>>> /etc/ipsec.secrets using:
>>>>
>>>>     @yourxauthname : XAUTH "password"
>>>
>>> Both these actions gave the same result.
>>
>>>> Seems the other end did not send a password request. Something else
>>>> might be wrong. You have to ask the other endpoint what error they
>>>> see.
>>>
>>> After diving in to the logs, I found the following:
>>> Mar 20 11:07:49.073524: | Received Cisco XAUTH type: Generic
>>> Mar 20 11:07:49.073529: | ****parse ISAKMP ModeCfg attribute:
>>> Mar 20 11:07:49.073533: |    ModeCfg attr type: XAUTH-USER-NAME (0x4089)
>>> Mar 20 11:07:49.073538: |    length/value: 0 (0x0)
>>> Mar 20 11:07:49.073542: | Received Cisco XAUTH username
>>> Mar 20 11:07:49.073547: | ****parse ISAKMP ModeCfg attribute:
>>> Mar 20 11:07:49.073551: |    ModeCfg attr type: XAUTH-PASSCODE (0x408b)
>>> Mar 20 11:07:49.073556: |    length/value: 0 (0x0)
>>> Mar 20 11:07:49.073561: | Unsupported XAUTH (inI0) long attribute
>>> XAUTH-PASSCODE received.
>>>
>>> It looks like the gateway is sending a request for an XAUTH-PASSCODE
>>> attribute which ipsec does
>>> not support.
>>
>> Based on
>> https://tools.ietf.org/html/draft-beaulieu-ike-xauth-02#section-6.2
>> it looks like it is expecting some kind of OTP reply from a hardware or
>> software token, and not a static password? So in that case you cannot
>> store the password in the secrets file.
> 
> Correct, in our case the OTP is a concatenation of a 4-8 character
> PIN/alphanumeric password and a 6-digit number from an RSA SecurID
> hardware token, like this one:
> https://en.wikipedia.org/wiki/RSA_SecurID. The number changes every 60
> seconds so the passcode entry should preferably be done interactively.
>>
>> Is your password static? We could patch the code to handle
>> XAUTH-PASSCODE the same as XAUTH-USER-PASSWORD ? That would
>> allow you to put it in the secrets file if static, and allow
>> you to type it in uing ipsec whack --initiate --name <conn>
> 
> The passcode is not static. As described above, it consists of a static
> part and a dynamic part. If we had to enter it into the secrets file,
> it would have to be done within 60 seconds of it changing on the token.
> It could be done but it would be rather inconvenient.
> 
Update: I'm not a coder so this may have broken something but as an
experiment I replaced all occurrences of XAUTH-USER-PASSWORD with
XAUTH-PASSCODE in ikev1_xauth.c and re-compiled. This had the effect
that I could get through the XAUTH authentication. I even got a password
prompt when there was no password in the secrets file. On the
authentication server, the authentication was approved.

Now, I'm having ModeCfg issues. the client received this payload:

  Mar 25 14:09:09.890911: | HASH(1) PRF sha2_256 update M-ID-bytes at 0x7ffd12aa2ffc (length 4)
  Mar 25 14:09:09.890919: |   81 71 59 87
  Mar 25 14:09:09.890929: | HASH(1) PRF sha2_256 update payload-bytes at 0x55b304aa4108 (length 40)
  Mar 25 14:09:09.890938: |   00 00 00 28  03 00 5f 4b  00 01 00 04  0a 14 33 28
  Mar 25 14:09:09.890945: |   00 02 00 04  ff ff ff ff  00 03 00 04  0a 14 00 20
  Mar 25 14:09:09.890953: |   00 03 00 04  0a 14 00 24
  Mar 25 14:09:09.890973: | HASH(1) PRF sha2_256 final-bytes at 0x7ffd12aa3088 (length 32)
  Mar 25 14:09:09.890982: |   fb 19 ed 78  f8 b5 bc b6  42 9d f4 4c  74 f8 c3 c5
  Mar 25 14:09:09.890990: |   6f cb 5e 3a  86 88 fb 72  29 ae 6e 43  25 3e ae f4
  Mar 25 14:09:09.890998: | xauth_inI0 HASH(1):
  Mar 25 14:09:09.891006: |   fb 19 ed 78  f8 b5 bc b6  42 9d f4 4c  74 f8 c3 c5
  Mar 25 14:09:09.891014: |   6f cb 5e 3a  86 88 fb 72  29 ae 6e 43  25 3e ae f4
  Mar 25 14:09:09.891023: | received 'xauth_inI0' message HASH(1) data ok

I can see the offered IP address, netmask and DNS servers in the payload but when libreswan
processes it, it looks as if the values are ignored:

  Mar 25 14:09:09.891135: | arrived in xauth_inI0
  Mar 25 14:09:09.891144: | ****parse ISAKMP ModeCfg attribute:
  Mar 25 14:09:09.891152: |    ModeCfg attr type: INTERNAL_IP4_ADDRESS (0x1)
  Mar 25 14:09:09.891162: |    length/value: 4 (00 04)
  Mar 25 14:09:09.891170: | Received Cisco Internal IPv4 address
  Mar 25 14:09:09.891178: | ****parse ISAKMP ModeCfg attribute:
  Mar 25 14:09:09.891186: |    ModeCfg attr type: INTERNAL_IP4_NETMASK (0x2)
  Mar 25 14:09:09.891196: |    length/value: 4 (00 04)
  Mar 25 14:09:09.891203: | Received Cisco Internal IPv4 netmask
  Mar 25 14:09:09.891212: | ****parse ISAKMP ModeCfg attribute:
  Mar 25 14:09:09.891220: |    ModeCfg attr type: INTERNAL_IP4_DNS (0x3)
  Mar 25 14:09:09.891229: |    length/value: 4 (00 04)
  Mar 25 14:09:09.891237: | Received Cisco IPv4 DNS info
  Mar 25 14:09:09.891245: | ****parse ISAKMP ModeCfg attribute:
  Mar 25 14:09:09.891253: |    ModeCfg attr type: INTERNAL_IP4_DNS (0x3)
  Mar 25 14:09:09.891263: |    length/value: 4 (00 04)
  Mar 25 14:09:09.891270: | Received Cisco IPv4 DNS info
  Mar 25 14:09:09.891279: | complete v1 state transition with STF_FAIL

I have tried with modecfgpull=yes, modecfgpull=no and no modecfgpull setting, neither of which
result in a different outcome. I have also tried with remote-peer-type=cisco and without it.
Could this point to a problem with the structure of the incoming payload?

Thanks,
/Mikael


More information about the Swan mailing list