[Swan-dev] CentOS libreswan vs Fedora libreswan

[Paul Wouters]

On Sun, 30 Jun 2019, D. Hugh Redelmeier wrote:

> I don't specify any cryptosuites -- I just let them default.
>
> Much to my surprise, the CentOS Responder refuses the Fedora Initiator's
> negotiation:
>
>  initiator guessed wrong keying material group (ECP_256); responding with INVALID_KE_PAYLOAD requesting MODP2048
>  responding to IKE_SA_INIT (34) message (Message ID 0) from 99.241.4.30:500 with unencrypted notification INVALID_KE_PAYLOAD

Looks like libreswan on RHEL/CentOS didnt add the ECP groups to the
defaults? On RHEL7/centos7 there is no crypto-policies package yet, so
it is using the libreswan defaults. Since you picked up a package from
download.libreswan.org, that should be the stock 3.29. I see the
defaults as:

000 "test":   IKE algorithms: AES_GCM_16_256-HMAC_SHA2_512+HMAC_SHA2_256-DH19+DH20+DH21+MODP2048+MODP3072+MODP4096+MODP8192, CHACHA20_POLY1305-HMAC_SHA2_512+HMAC_SHA2_256-DH19+DH20+DH21+MODP2048+MODP3072+MODP4096+MODP8192, AES_CBC_256-HMAC_SHA2_512+HMAC_SHA2_256-DH19+DH20+DH21+MODP2048+MODP3072+MODP4096+MODP8192, AES_GCM_16_128-HMAC_SHA2_512+HMAC_SHA2_256-DH19+DH20+DH21+MODP2048+MODP3072+MODP4096+MODP8192, AES_CBC_128-HMAC_SHA2_256-DH19+DH20+DH21+MODP2048+MODP3072+MODP4096+MODP8192

The ECP groups are DH 19-21 which are part of the default proposal set
there. So I'm not sure what happened on your setup.

> This response is fairly useless since the Initiator ought ignore
> unencrypted notifications.  This is surely a limitation of the protocol
> standard.

Nope.

https://tools.ietf.org/html/rfc7296#section-1.2

    Because the initiator sends its Diffie-Hellman value in the
    IKE_SA_INIT, it must guess the Diffie-Hellman group that the
    responder will select from its list of supported groups.  If the
    initiator guesses wrong, the responder will respond with a Notify
    payload of type INVALID_KE_PAYLOAD indicating the selected group.  In
    this case, the initiator MUST retry the IKE_SA_INIT with the
    corrected Diffie-Hellman group.  The initiator MUST again propose its
    full set of acceptable cryptographic suites because the rejection
    message was unauthenticated and otherwise an active attacker could
    trick the endpoints into negotiating a weaker suite than a stronger
    one that they both prefer.

> It's also seems pretty dumb to not have defaulted cryptosuites be
> compatable.  I'm sure that there are excuses.  What are they?

I dont know why yours is odd. If it is 3.29 it should have it on both
fedora and rhel/centos

> ipsec auto --up prints progress information, but does not report this
> notification, making debugging harder than it should be.

It should. Eg see
ikev2-invalid-ke-03-default-initiator/west.console.txt:

west #
  ipsec auto --up  westnet-eastnet-ipv4-psk-ikev2
002 "westnet-eastnet-ipv4-psk-ikev2" #1: initiating v2 parent SA
1v2 "westnet-eastnet-ipv4-psk-ikev2" #1: initiate
1v2 "westnet-eastnet-ipv4-psk-ikev2" #1: STATE_PARENT_I1: sent v2I1, expected v2R1
002 "westnet-eastnet-ipv4-psk-ikev2" #1: Received unauthenticated INVALID_KE_PAYLOAD response to DH MODP2048; resending with suggested DH MODP4096
1v2 "westnet-eastnet-ipv4-psk-ikev2" #1: STATE_PARENT_I1: sent v2I1, expected v2R1
1v2 "westnet-eastnet-ipv4-psk-ikev2" #2: STATE_PARENT_I2: sent v2I2, expected v2R2 {auth=IKEv2 cipher=AES_GCM_16_256 int eg=n/a prf=HMAC_SHA2_256 group=MODP4096}
002 "westnet-eastnet-ipv4-psk-ikev2" #2: IKEv2 mode peer ID is ID_FQDN: '@east'
003 "westnet-eastnet-ipv4-psk-ikev2" #2: Authenticated using authby=secret
002 "westnet-eastnet-ipv4-psk-ikev2" #2: negotiated connection [192.0.1.0-192.0.1.255:0-65535 0] -> [192.0.2.0-192.0.2.2 55:0-65535 0]
004 "westnet-eastnet-ipv4-psk-ikev2" #2: STATE_V2_IPSEC_I: IPsec SA established tunnel mode {ESP=>0xESPESP <0xESPESP xfr m=AES_GCM_16_256-NONE NATOA=none NATD=none DPD=passive}

> - why would 3.29 default to something 3.29 doesn't accept?

I don't know.

> - what is the minimal adition that I can make to the conn to allow
>  interop?  I don't wish to specify any part of the cryptosuites but I
>  certainly don't want to provide a complete and detailed specification.

Your logs showed the invalid_ke was not the problem. A resend happens
and then you have a bad RSA signature detected.

Paul