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 <[email protected]> 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 > > >
_______________________________________________ Dev mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/dev
