[Openswan dev] MODECFG/IKECFG/MODE CONFIG openswan server and third party clients

[Michael Richardson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


> The draft-dukes-ike-mode-cfg-02 specifies that a mode config
> transaction takes place "once the ISAKMP security association has been
> established" and "the derivation of the initialization vector IV for
> the first message, used with SKEYID_e to encrypt the message" is
> described in Appendix B of RFC2049. However it's still not clear
> whether the IV vector should be generated as for Phase1 or Phase2, as
> the mode config exchange takes place between the two. Openswan decides
> to use Phase1 initialization vector IV, SoftRemote uses Phase2
> initialization vector IV, which is the cause of confusion and cause
> "malformed packet" messages in SoftRemote logs, when openswan attempts
> to send MODECFG SET packets. 

You can't use the phase 2 IV because there is no phase 2 yet.

You never use a phase 2 IV to initialize a new exchange (indicated by
a new messageid). That just doesn't make sense. It sounds like
SoftRemote has never been to a bakeoff.

I'll bet the client can't rekey properly.

SoftRemote has clearly confused themselves, because they have decided to
start the phase 2 negotiation even though the phase 1.5 (the modecfg)
is not yet finished. This is clear from your next part:

> When the initialization vector issue was fixed, SoftRemote started to
> parse modeconfig packets properly. But the latter conversation was
> still failing - because of silent abandoning the already initiated
> IPsec SA conversation by SoftRemote (after the virtual interface with
> the new IP address was up). SoftRemote attempted to start a new IPsec
> SA conversation, what wasn't properly handled on the server side. 

Nor should it be.
You can't propose a proper phase 2 until you know what IP address the
client should propose. You can't do that until the modecfg is over.

- -- 
]            Bear: "Me, I'm just the shape of a bear."          |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] mcr at xelerance.com      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBRXeFYICLcPvd0N1lAQJ45wf+IWbkr7IS7Gp07a5lU94+CM3AjLkqaJzj
sNg6iSo78miyQ/q77ZkFTLUglpfd9oszMftJIX+RdL7TWN8k1NhDeAr1iRNfZxBJ
aaPc5qMMi1628ayz3zHM7Pji3EQSVf6inV0sXi9hpE7BLS+3mOfEQljwhA6Wm8mP
BNz6eFRiIUiILiNtAkVqQPzoHJZ5Xx7/wA27+Zl19qOmpz2STkLX6syp21GJiWV1
b0RTKpdsmmeXdxFOIkJ2x0slifC340PjQu8kZASIX0MOFd9YInPMOWaLahYDOMUQ
lL8S2LPVtTRPVJR5pBWn/Vl92LwEXMyo4ma9dRx9aNas0SiE7F5zEQ==
=+S0v
-----END PGP SIGNATURE-----