[strongSwan-dev] Chrome OS -- upgrade to strongSwan 5.x and 4.x Pluto patches

[Darin Petkov]

Thank you very much Martin, very useful (and prompt) feedback. We'll follow
up if necessary.

Darin



On Thu, Dec 6, 2012 at 2:38 PM, Martin Willi <martin at strongswan.org> wrote:

> Hi Darin,
>
> > However, we've made some local patches to Pluto that we'll need to
> > re-evaluate and drop obsolete ones, re-implement necessary ones in
> > Charon, or maybe come up with better solutions, hopefully upstream.
>
> >       * crosbug.com/16252: initialize supplementary groups
>
> I think porting this to charon shouldn't be a problem, as it uses the
> same user/group switching as pluto.
>
> >       * crosbug.com/24476: disable peer ID check
>
> If I understand correctly, this just accepts any identity the responder
> uses? If yes, this can be achieved by setting "rightid=%any".
>
> However, keep in mind that this has security implications; if you trust
> a CA certificate, any peer with a valid certificate can act as a
> responder, as we don't check the identity. This is why you usually want
> to enforce a strict identity.
>
> >       * crosbug.com/25675: disable XAUTH ID
>
> State handling is completely different in charon than in pluto, so I'm
> not sure if this still applies. We currently always send the XAuth
> vendor ID in the first ISAKMP message. But this shouldn't be hard to
> change if it is problematic. However, from the bug report it's not clear
> to me why the responder sends an XAuth request while we negotiated PSK
> authentication.
>
> >       * crosbug.com/32738: ISAKMP commit bit
>
> I don't have enough information to comment on this; it might or might
> not be an issue with charon.
>
> > Do you think some of these issues can be addressed properly upstream,
> > to ease the upgrade path?
>
> Yes, we'd be happy to help you fixing these issues and integrate it
> upstream. We don't have much third party equipment on the responder side
> to test against, though.
>
> Kind regards
> Martin
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/dev/attachments/20121210/adb5e71a/attachment.html>