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

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


>>>>> "Anna" == Anna Wiejak
<aniaspopoludnica.pl> writes:
    Anna> Recently I was working on the problem of
modeconfig
    Anna> compatibility between openswan server and
softremote
    Anna> third-party client.  I found the reason why
this doesn't work
    Anna> properly and implemented a workaround on
openswan server. The
    Anna> problem and solution is explained in detail
here:

  Please don't make me fish on your blog for the
explanation.
  Post it here as text.

    Anna> Openswan implements the modeconfig in a
different way then all
    Anna> other solutions I've seen. I can't find out
which behaviour is
    Anna> correct - it looks like the details of deriving
initialization

  Well, openswan interoperates with multiple cisco
implementations that
were done by the authors of the ikecfg draft.

  There is only one way to calculate the initial IV. 

- -- 
]            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

iQEVAwUBRXYV2YCLcPvd0N1lAQIW9gf/ftey9uK2SelAt8DfH6NKCKUxPVT4
3XKu
V5AR01jN3Ms0Pch8+bDsQNy4mKZxp2LATusjt0fOW8aRuyCRrVuIVr6BDgk3
dxoH
769u1pwXA1WsQUdYiNU1PtV0fr822XfFyeNi8HAO2TWEJrQSJNA255+gGQ7u
6c34
zJx/U5iypuugIvwYTz9HJ+CgdR+o8gZQgKhC606eorBaVGP7YLHyg6blumU6
GVd9
pyEiBK1moYAzQa+/0sNsTnjPvfqIvluiP/DuXPhkVLssbxw5ZuTXQLH5R1Np
0MeI
fwlqdN2XC5TZIr1X6iMKASZlSH9r5efmhPfKLhmVJdWrToVpj8AWLg==
=NpaO
-----END PGP SIGNATURE-----
_______________________________________________
Dev mailing list
Devopenswan.org
http:/
/lists.openswan.org/mailman/listinfo/dev

On Tue, 5 Dec 2006, Michael Richardson wrote:

> >>>>> "Anna" == Anna Wiejak
<aniaspopoludnica.pl> writes:
>     Anna> Recently I was working on the problem of
modeconfig
>     Anna> compatibility between openswan server and
softremote
>     Anna> third-party client.  I found the reason
why this doesn't work
>     Anna> properly and implemented a workaround on
openswan server. The
>     Anna> problem and solution is explained in
detail here:
>
>   Please don't make me fish on your blog for the
explanation.
>   Post it here as text.

All the text was added by ,e in the bug report:

http://bugs
.xelerance.com/view.php?id=709

>     Anna> Openswan implements the modeconfig in a
different way then all
>     Anna> other solutions I've seen. I can't find
out which behaviour is
>     Anna> correct - it looks like the details of
deriving initialization
>
>   Well, openswan interoperates with multiple cisco
implementations that
> were done by the authors of the ikecfg draft.
>
>   There is only one way to calculate the initial IV.

So I guess this bug should be reported to softremote then?

Paul
_______________________________________________
Dev mailing list
Devopenswan.org
http:/
/lists.openswan.org/mailman/listinfo/dev

>   Well, openswan interoperates with multiple cisco
implementations that
> were done by the authors of the ikecfg draft.
Is it the set/acknowledge way of mode config conversation
that works
in cisco(modecfg client)-openswan(modecfg server)
configuration?
Unfortunately I've got no way to verify this.
The problem is the same argument was provided by softremote
developers
team (I've contacted them about the problem weeks ago) -
according to
what they wrote is - it works with number of cisco
implementations
their customers are using.

Just curious - can someone instead point me to the proper
part of
rfc/draft where it's explained? I can't see anywhere
(draft/rfc 2409)
a _clear statement_ whether Phase1 or Phase2 IV should be
used.

Regards!

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