[strongSwan-dev] [RFC] Be lenient about downstream encryption

[Paul Stewart]

On Mon, Apr 14, 2014 at 5:56 AM, Martin Willi <martin at strongswan.org> wrote:
> Hi Paul,
>
>> I discovered an interop issue with XAUTH authentication
>> with StrongSwan VPNs.  Does anyone have a deep enough
>> knowledge of this frame to understand what the remote
>> VPN is giving away?
>
> Thanks for your analysis, and the patch.
>
> It seems that Sonicwall sends the ID/Hash payloads unencrypted even in
> Main Mode, probably to select different PSK keys based on the peer
> Identity. Something like an "Aggressive Mode light"?
>
> If that helps for interoperability, I'm not against upstreaming a
> work-around, even if it is not strictly within the specs.
>
> How about the (untested) patch at [1]? It introduces a
> charon.sonicwall_quirk strongswan.conf option to enable that behavior.

My only reservations to it being optional:

 - There's a very high bar to discovering the need for this option,
for someone who may have only discovered that "it doesn't work for
me".
 - By not supporting this option by default, you could argue slightly
better security, but only because the user will give up after a while
(see the point above), and not because we prevent the un-encrypted
data from being sent, since by the time the connection fails, it
already has.

That said, as someone who knows about this issue, I'd be okay with [1]
(haven't tested it yet -- will do) since I'd probably enable it by
default.

>
> @Tobias: What do you think about such an option? Don't know if it is
> worth it, as remote sends these unencrypted payloads anyway. On the
> other side, it can make the implications clear to the
> administrator/user, given that an attacker can snoop these identities
> sent in clear-text.
>
> Best Regards
> Martin
>
> [1]http://git.strongswan.org/?p=strongswan.git;a=shortlog;h=refs/heads/sonicwall-quirk
>