[Swan-dev] +002 "westnet-eastnet-ikev2" #2: IKE SA authentication request rejected by peer: AUTHENTICATION_FAILED

[Paul Wouters]

On Sat, 7 Sep 2019, Andrew Cagney wrote:

> Channelling hugh ...
> 
> The test results took a recent dive ~130->320 https://testing.libreswan.org/ and a git bisect turned up these
> changes:
> 
> pluto: in decode_peer_id_counted() isanyid check should also apply to initiator
> pluto: decode_peer_id_counted() if we didn't switch connections, confirm ID wildcard or not

I'm looking into this. Note that a bad debug line caused some of it at
first, but now looking at the next run without that and still seeing a
lot.

The old issue of bad packet counters still plague us with very many
false positives, but these are not the new ones causing the drop.


This one is worrying, who touched the CERT / CRL code?

https://testing.libreswan.org/v3.28-761-gbc0ebde9e-master/nss-cert-crl-03-strict/OUTPUT/east.console.diff

It shows new leaks with CRL and issuer's that seem questionable as those
are all end certificates and not CA certificates.

Maybe related:
https://testing.libreswan.org/v3.28-761-gbc0ebde9e-master/nss-cert-crl-03-strict/OUTPUT/west.console.diff

I never know whether to trust the CRL/OCSP tests as these tests require
certificates be regenerated before the test run starts.


It seems part of what my above listed commits did was cause this:

https://testing.libreswan.org/v3.28-761-gbc0ebde9e-master/newoe-25-cat-5/OUTPUT/road.console.diff

-000 "block":   our idtype: ID_IPV4_ADDR; our id=192.1.3.209; their idtype: %none; their id=(none)
+000 "block":   our idtype: ID_IPV4_ADDR; our id=192.1.3.209(with %any); their idtype: %none; their id=(none)(with %any)

It is a bit misleading here. Anything in the "block" group has
authby=never, so the ID is irrelevant. It is likely better to not
display the entire line for authby=never connections. But if we go
that way, there is a lot more we should never print, like the dpd=
line and others. So for now I suppressed printing the new %any
stuff for NEVER_NEGOTIATE() connections.


Others I see are:

https://testing.libreswan.org/v3.28-761-gbc0ebde9e-master/xauth-pluto-20-pam-timeout/OUTPUT/road.console.diff

-002 "xauth-road-eastnet" #2: deleting state (STATE_MAIN_I3) and NOT sending notification
+002 "xauth-road-eastnet" #2: deleting state (STATE_MAIN_I2) and NOT sending notification

Another group I see is:

https://testing.libreswan.org/v3.28-761-gbc0ebde9e-master/seccomp-03-updown/OUTPUT/road.console.diff

-004 "westnet-eastnet-ipv4-psk-ikev2"[1] 192.1.2.23 #2: STATE_V2_IPSEC_I: IPsec SA established tunnel mode {ESP/NAT=>0xESPESP <0xESPESP xfrm=AES_GCM_16_256-NONE NATOA=none NATD=192.1.2.23:4500 DPD=passive}
+002 "westnet-eastnet-ipv4-psk-ikev2"[1] 192.1.2.23 #2: IKE SA authentication request rejected by peer: AUTHENTICATION_FAILED
+000 "westnet-eastnet-ipv4-psk-ikev2"[1] 192.1.2.23 #2: scheduling retry attempt 1 of an unlimited number, but releasing whack

The connection is PSK and I surely caused this with the above commits.
As it shows:

"roadnet-eastnet-ipv4-psk-ikev2"[1] 192.1.2.254 #1: Peer ID '@road' not suitable for connection 'roadnet-eastnet-ipv4-psk-ikev2'

It should not have done any certificate SAN checking on this since we
did not do CERT payloads at all. I will look at fixing this today.

Paul