On Sat, 13 May 2017, Steve Scheck wrote:
Is there any situation in the Libreswan IKE implementation in which the third
packet of an Aggressive Exchange is allowed to *not* be
encrypted? RFC 2408 (https://tools.ietf.org/html/rfc2408#section-4.7) seems to
say no:
“In the third (3) message, the initiator transmits the results of the
agreed upon authentication function. This information is transmitted
under the protection of the common shared secret. Local security
policy dictates the action if an error occurs during these messages.
One possible action is the transmission of a Notify payload as part
of an Informational Exchange.”
I’m comparing IKE packet dumps from two similar IPsec peer configurations: a
proprietary embedded device and Libreswan, and the same device
with a Cisco IOS device. NAT traversal is in use in both situations (Libreswan
and the Cisco are behind NAT), and the embedded device is
always the session initiator. The third packet contains two NAT-D payloads and
a Hash payload. With the Cisco, the IKE SA and tunnel
establishes, even though the third Aggressive Exchange packet from the embedded
device to the Cisco is *not* encrypted. Libreswan terminates
the Aggressive Exchange with an Informational message with INVALID-FLAGS
notification and a log message indicating it expected an encrypted
response, which seems correct according to the RFC and because the Flags field
of the third packet is set to 0x00.
Can anybody on the development team confirm that the third packet in Aggressive
mode must always be encrypted?
Yes as is explained in: https://tools.ietf.org/html/rfc2409#section-3.2
Message encryption (when noted by a '*' after the ISAKMP header) MUST
begin immediately after the ISAKMP header. When communication is
protected, all payloads following the ISAKMP header MUST be
encrypted.
and your third message is:
(3) HDR*; AUTH =>
Responder Identity
Verified by Initiator
SA established
Libreswan enforced this with the state machine.
Paul
_______________________________________________
Swan mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan
