MODECFG/IKECFG/MODE CONFIG openswan server and third party clients

-----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[
] mcrxelerance.com      http://www.san
delman.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+CM3AjLkq
aJzj
sNg6iSo78miyQ/q77ZkFTLUglpfd9oszMftJIX+RdL7TWN8k1NhDeAr1iRNf
ZxBJ
aaPc5qMMi1628ayz3zHM7Pji3EQSVf6inV0sXi9hpE7BLS+3mOfEQljwhA6W
m8mP
BNz6eFRiIUiILiNtAkVqQPzoHJZ5Xx7/wA27+Zl19qOmpz2STkLX6syp21GJ
iWV1
b0RTKpdsmmeXdxFOIkJ2x0slifC340PjQu8kZASIX0MOFd9YInPMOWaLahYD
OMUQ
lL8S2LPVtTRPVJR5pBWn/Vl92LwEXMyo4ma9dRx9aNas0SiE7F5zEQ==
=+S0v
-----END PGP SIGNATURE-----
_______________________________________________
Dev mailing list
Devopenswan.org
http:/
/lists.openswan.org/mailman/listinfo/dev

Hi,

> You can't use the phase 2 IV because there is no phase
2 yet.
AND
> 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:

That is what it does! Softremote starts the Phase2, but then
it
receives the modeconfig SET packet from Openswan. It doesn't
expect it
to come, but:

* modeconfig conversation is accepted,
* existing Phase2 is abandoned silently,
* virtual adaptor is created
* new Phase2 is started.

So - you're right it is Softremote error - Softremote is
using IV of
just started Phase2 and this is simply wrong at the stage
when Phase2
is initiated too early (before mode config).

Till (if) Softremote fixes their problem (I will point them
at the
conversation) I will use my workaround anyway, but now
things are at
least clear 

Thanks again,

--
A. Wiejak
_______________________________________________
Dev mailing list
Devopenswan.org
http:/
/lists.openswan.org/mailman/listinfo/dev