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
_______________________________________________
Swan-dev mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan-dev
