L2TP/IPsec VPN server: trying to force HMAC_SHA in phase 2, but isakmpd keeps offering HMAC_SHA2_256?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

L2TP/IPsec VPN server: trying to force HMAC_SHA in phase 2, but isakmpd keeps offering HMAC_SHA2_256?

Jurjen Oskam-3
Hi,

I'm trying to set up my OpenBSD 6.0 box as an L2TP/IPsec server for my
Android phone to connect to. It appears that recent Android versions have a
bug that can prevent it to successfully use HMAC_SHA2_256 for its built-in
L2TP/IPsec VPN client. (Whether the bug occurs seems to depend on the
specifics of the Linux kernel that happens to be used for the device. See
https://code.google.com/p/android/issues/detail?id=196939 for more
information).

I suspect I'm hit by this bug. The isakmpd negotiations seem to work fine,
but npppd doesn't see any traffic. When tcpdumping the external interface
of the OpenBSD box, I see incoming encrypted traffic, but on a
simultaneously running tcpdump on the enc0 interface, I see no traffic at
all. This behavior is consistent with the Android bug description: Android
is requesting a SHA2 HMAC, but it is using a DRAFT version that is
incompatible with the final RFC.

So, to validate that I'm indeed hitting this bug (and also as a workaround)
I tried to set up the OpenBSD side to not use SHA2. I haven't been able to
get this running yet: isakmpd always seems to offer HMAC_SHA2_256.

Here is /etc/ipsec.conf:

ike passive esp transport \
  proto udp from egress to any port 1701 \
  main auth "hmac-sha1" enc "aes" group modp1024 \
  quick auth "hmac-sha1" enc "aes" group modp1024 \
  psk "SHARED_SEEKRIT"

With this configuration, isakmpd still offers HMAC_SHA2_256. See a snippet
of the output of tcpdumping the pcap file created by isakmpd below. The "
ziggo.nl" address is OpenBSD, the "static.kpn.net" address is my Android
phone connected to the cellular network):

15:31:00.865423 static.kpn.net.ipsec-nat-t >
5356F312.cm-6-7d.dynamic.ziggo.nl.isakmp: [bad udp cksum e50! -> 74e4]
udpencap: isakmp v1.0 exchange QUICK_MODE
        cookie: 0f659aa030f4904d->64d8256cce1ec37b msgid: 8281d122 len: 460
        payload: HASH len: 24
        payload: SA len: 336 DOI: 1(IPSEC) situation: IDENTITY_ONLY
            payload: PROPOSAL len: 324 proposal: 1 proto: IPSEC_ESP spisz:
4 xforms: 12 SPI: 0x0a89e2b7
                payload: TRANSFORM len: 28
                    transform: 1 ID: AES
                        attribute LIFE_TYPE = SECONDS
                        attribute LIFE_DURATION = 28800
                        attribute ENCAPSULATION_MODE = UDP_ENCAP_TRANSPORT
                        attribute KEY_LENGTH = 256
                        attribute AUTHENTICATION_ALGORITHM = HMAC_SHA2_256
                payload: TRANSFORM len: 28
                    transform: 2 ID: AES
                        attribute LIFE_TYPE = SECONDS
                        attribute LIFE_DURATION = 28800
                        attribute ENCAPSULATION_MODE = UDP_ENCAP_TRANSPORT
                        attribute KEY_LENGTH = 256
                        attribute AUTHENTICATION_ALGORITHM = HMAC_SHA
                payload: TRANSFORM len: 28
                    transform: 3 ID: AES
                        attribute LIFE_TYPE = SECONDS
                        attribute LIFE_DURATION = 28800
                        attribute ENCAPSULATION_MODE = UDP_ENCAP_TRANSPORT
                        attribute KEY_LENGTH = 256
                        attribute AUTHENTICATION_ALGORITHM = HMAC_MD5
                payload: TRANSFORM len: 28
                    transform: 4 ID: AES
                        attribute LIFE_TYPE = SECONDS
                        attribute LIFE_DURATION = 28800
                        attribute ENCAPSULATION_MODE = UDP_ENCAP_TRANSPORT
                        attribute KEY_LENGTH = 128
                        attribute AUTHENTICATION_ALGORITHM = HMAC_SHA2_256
                payload: TRANSFORM len: 28
                    transform: 5 ID: AES
                        attribute LIFE_TYPE = SECONDS
                        attribute LIFE_DURATION = 28800
                        attribute ENCAPSULATION_MODE = UDP_ENCAP_TRANSPORT
                        attribute KEY_LENGTH = 128
                        attribute AUTHENTICATION_ALGORITHM = HMAC_SHA
                payload: TRANSFORM len: 28
                    transform: 6 ID: AES
                        attribute LIFE_TYPE = SECONDS
                        attribute LIFE_DURATION = 28800
                        attribute ENCAPSULATION_MODE = UDP_ENCAP_TRANSPORT
                        attribute KEY_LENGTH = 128
                        attribute AUTHENTICATION_ALGORITHM = HMAC_MD5
                payload: TRANSFORM len: 24
                    transform: 7 ID: 3DES
                        attribute LIFE_TYPE = SECONDS
                        attribute LIFE_DURATION = 28800
                        attribute ENCAPSULATION_MODE = UDP_ENCAP_TRANSPORT
                        attribute AUTHENTICATION_ALGORITHM = HMAC_SHA2_256
                payload: TRANSFORM len: 24
                    transform: 8 ID: 3DES
                        attribute LIFE_TYPE = SECONDS
                        attribute LIFE_DURATION = 28800
                        attribute ENCAPSULATION_MODE = UDP_ENCAP_TRANSPORT
                        attribute AUTHENTICATION_ALGORITHM = HMAC_SHA
                payload: TRANSFORM len: 24
                    transform: 9 ID: 3DES
                        attribute LIFE_TYPE = SECONDS
                        attribute LIFE_DURATION = 28800
                        attribute ENCAPSULATION_MODE = UDP_ENCAP_TRANSPORT
                        attribute AUTHENTICATION_ALGORITHM = HMAC_MD5
                payload: TRANSFORM len: 24
                    transform: 10 ID: DES
                        attribute LIFE_TYPE = SECONDS
                        attribute LIFE_DURATION = 28800
                        attribute ENCAPSULATION_MODE = UDP_ENCAP_TRANSPORT
                        attribute AUTHENTICATION_ALGORITHM = HMAC_SHA2_256
                payload: TRANSFORM len: 24
                    transform: 11 ID: DES
                        attribute LIFE_TYPE = SECONDS
                        attribute LIFE_DURATION = 28800
                        attribute ENCAPSULATION_MODE = UDP_ENCAP_TRANSPORT
                        attribute AUTHENTICATION_ALGORITHM = HMAC_SHA
                payload: TRANSFORM len: 24
                    transform: 12 ID: DES
                        attribute LIFE_TYPE = SECONDS
                        attribute LIFE_DURATION = 28800
                        attribute ENCAPSULATION_MODE = UDP_ENCAP_TRANSPORT
                        attribute AUTHENTICATION_ALGORITHM = HMAC_MD5
        payload: NONCE len: 20
        payload: ID len: 12 proto: 17 port: 0 type: IPV4_ADDR =
100.93.193.197
        payload: ID len: 12 proto: 17 port: 1701 type: IPV4_ADDR =
83.86.243.18 [ttl 0] (id 1, len 492)
15:31:00.865689 5356F312.cm-6-7d.dynamic.ziggo.nl.ipsec-nat-t >
static.kpn.net.ipsec-nat-t: [bad udp cksum 9d3a! -> 1d43] udpencap: isakmp
v1.0 exchange QUICK_MODE
        cookie: 0f659aa030f4904d->64d8256cce1ec37b msgid: 8281d122 len: 148
        payload: HASH len: 24
        payload: SA len: 52 DOI: 1(IPSEC) situation: IDENTITY_ONLY
            payload: PROPOSAL len: 40 proposal: 1 proto: IPSEC_ESP spisz: 4
xforms: 1 SPI: 0xacb10a8a
                payload: TRANSFORM len: 28
                    transform: 1 ID: AES
                        attribute LIFE_TYPE = SECONDS
                        attribute LIFE_DURATION = 28800
                        attribute ENCAPSULATION_MODE = UDP_ENCAP_TRANSPORT
                        attribute KEY_LENGTH = 256
                        attribute AUTHENTICATION_ALGORITHM = HMAC_SHA2_256
        payload: NONCE len: 20
        payload: ID len: 12 proto: 17 port: 0 type: IPV4_ADDR =
100.93.193.197
        payload: ID len: 12 proto: 17 port: 1701 type: IPV4_ADDR =
83.86.243.18 [ttl 0] (id 1, len 180)


ipsecctl shows that hmac-sha2-256 is indeed selected:

# ipsecctl -s all
FLOWS:
flow esp in proto udp from 31.161.203.40 to 83.86.243.18 port l2tp peer
31.161.203.40 srcid 83.86.243.18/32 dstid 100.93.193.197/32 type use
flow esp out proto udp from 83.86.243.18 port l2tp to 31.161.203.40 peer
31.161.203.40 srcid 83.86.243.18/32 dstid 100.93.193.197/32 type require

SAD:
esp transport from 83.86.243.18 to 31.161.203.40 spi 0x030ab16e auth
hmac-sha2-256 enc aes-256
esp transport from 31.161.203.40 to 83.86.243.18 spi 0xa31bf5b1 auth
hmac-sha2-256 enc aes-256


Using the FIFO based interface to isakmpd, I verified that HMAC_SHA is
configured:

# get "[Phase 2]:Connections"
# get "[Phase 2]:Passive-Connections"
from-re1=17-to-0.0.0.0/0=17:1701
# get "[from-re1=17-to-0.0.0.0/0=17:1701]:Configuration"
phase2-from-re1=17-to-0.0.0.0/0=17:1701
# get "[phase2-from-re1=17-to-0.0.0.0/0=17:1701]:Suites"
phase2-suite-from-re1=17-to-0.0.0.0/0=17:1701
# get "[phase2-suite-from-re1=17-to-0.0.0.0/0=17:1701]:Protocols"
phase2-protocol-from-re1=17-to-0.0.0.0/0=17:1701
# get "[phase2-protocol-from-re1=17-to-0.0.0.0/0=17:1701]:PROTOCOL_ID"
IPSEC_ESP
# get "[phase2-protocol-from-re1=17-to-0.0.0.0/0=17:1701]:Transforms"
phase2-transform-from-re1=17-to-0.0.0.0/0=17:1701-AES128-SHA-MODP_1024-TRANSPORT
# get
"[phase2-transform-from-re1=17-to-0.0.0.0/0=17:1701-AES128-SHA-MODP_1024-TRANSPORT]:AUTHENTICATION_ALGORITHM"
HMAC_SHA
#

I'm likely to miss something obvious here. Why is isakmpd negotiating
HMAC_SHA2_256 instead of HMAC_SHA, as it is configured to do? Any hints
would be much appreciated.

Thanks,

Jurjen Oskam

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: L2TP/IPsec VPN server: trying to force HMAC_SHA in phase 2, but isakmpd keeps offering HMAC_SHA2_256?

Philipp
Am 19.03.2017 15:36 schrieb Jurjen Oskam:

> So, to validate that I'm indeed hitting this bug (and also as a
> workaround)
> I tried to set up the OpenBSD side to not use SHA2. I haven't been able
> to
> get this running yet: isakmpd always seems to offer HMAC_SHA2_256.

It's not offering that - but accepting "better" Phase2 transforms. If
isakmpd
would start the negotiation, it'd propose HMAC_SHA.

To keep out unwanted proposals, you need an isakmpd.policy. (hint: no
-K)

In my eyes this is 'bad behaviour' and tends to lead to situations where
e.g.
a remote end "upgrades" (and locks down) the transforms and thus
rekeying
started by isakmpd start to fail.

HTH,
--
pb

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: L2TP/IPsec VPN server: trying to force HMAC_SHA in phase 2, but isakmpd keeps offering HMAC_SHA2_256?

Jurjen Oskam-3
Hi Philipp,

Thank you - this was exactly what I was missing. I have now gotten it to
work by excluding hmac-sha2-256 (and therefore falling back to hmac-sha1),
which strongly suggests my Nexus 6P (all patched) doesn't implement
hmac-sha2-256 correctly.

The irony is that the manpage of isakmpd.policy explains all this
excellently, but I didn't read it because I misunderstood what the manpage
of ipsec.conf says: "The keying daemon, isakmpd(8), can be enabled to run
at boot time via the isakmpd_flags variable in rc.conf.local(8).  Note that
it will probably need to be run with at least the -K option, to avoid
keynote(4) policy checking." I read this as meaning that keynote policy
checking is *always* unwanted when ipsecctl is used, and that you can avoid
policy checking either by not having a policy file at all (in which case
the -K option doesn't matter), or by using the -K option (in which case
it's certain that policy checking never happens).

But now I know better. :)

Thanks,

Jurjen

2017-03-20 9:33 GMT+01:00 Jurjen Oskam <[hidden email]>:

> Hi Philipp,
>
> Thank you - this was exactly what I was missing. I have now gotten it to
> work by excluding hmac-sha2-256 (and therefore falling back to hmac-sha1),
> which strongly suggests my Nexus 6P (all patched) doesn't implement
> hmac-sha2-256 correctly.
>
> The irony is that the manpage of isakmpd.policy explains all this
> excellently, but I didn't read it because I misunderstood what the manpage
> of ipsec.conf says: "The keying daemon, isakmpd(8), can be enabled to run
> at boot time via the isakmpd_flags variable in rc.conf.local(8).  Note that
> it will probably need to be run with at least the -K option, to avoid
> keynote(4) policy checking." I read this as meaning that keynote policy
> checking is *always* unwanted when ipsecctl is used, and that you can avoid
> policy checking either by not having a policy file at all (in which case
> the -K option doesn't matter), or by using the -K option (in which case
> it's certain that policy checking never happens).
>
> But now I know better. :)
>
> Thanks,
>
> Jurjen
>
>
> 2017-03-20 6:08 GMT+01:00 Philipp Buehler <e1c1bac6253dc54a1e89ddc046585
> [hidden email]>:
>
>> Am 19.03.2017 15:36 schrieb Jurjen Oskam:
>>
>> So, to validate that I'm indeed hitting this bug (and also as a
>>> workaround)
>>> I tried to set up the OpenBSD side to not use SHA2. I haven't been able
>>> to
>>> get this running yet: isakmpd always seems to offer HMAC_SHA2_256.
>>>
>>
>> It's not offering that - but accepting "better" Phase2 transforms. If
>> isakmpd
>> would start the negotiation, it'd propose HMAC_SHA.
>>
>> To keep out unwanted proposals, you need an isakmpd.policy. (hint: no -K)
>>
>> In my eyes this is 'bad behaviour' and tends to lead to situations where
>> e.g.
>> a remote end "upgrades" (and locks down) the transforms and thus rekeying
>> started by isakmpd start to fail.
>>
>> HTH,
>> --
>> pb

Loading...