[Swan] Aggressive mode question

Paul Wouters paul at nohats.ca
Sun May 14 18:33:20 UTC 2017


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


More information about the Swan mailing list