Hello Thomas, > I would like to know if the Strongswan team is planning to add support > for the KINK protocol ?
No, we don't have any plans to implement KINK. But as always, we are open to contributions (see [1]) or do sponsored development. > As a side project I'd be very interested in working on a proof of > concept support for this feature. In order to get me started faster, > I'd be very glad if you could provide some pointers on where to start > to plug this new keying protocol inside strongswan. With our upcoming 5.0 release (in git master), we provide both IKEv1 & IKEv2 through our new keying daemon charon, mostly implemented under src/libcharon. This would be a preferable starting point, as KINK lends some protocol bits from IKEv1. Beside the message encoding (subfolder encoding) and negotiation of Quick Modes (sa/child_sa.[ch]) and its installation in the kernel, there is probably not much more in common to IKEv1/IKEv2. While KINK does not know the concept of a "management SA" (Main Mode, IKE_SA, sa/ike_sa.[ch]), we'd need some structure to maintain those Quick Modes in a centralized place (like in sa/ike_sa_manager.[ch]). Implementing KINK with an existing Kerberos library is probably not too hard. Doing it properly in our existing keying daemon is not trivial, though, even if you have good knowledge of the strongSwan codebase. Maybe it would be possible to handle KINK as a plugin, maybe it would make sense to handle it as first class citizen along with IKEv1 and IKEv2, or even have a dedicated daemon for KINK. All in all, a very ambitious project. Best Regards Martin [1]http://wiki.strongswan.org/projects/strongswan/wiki/Contributions _______________________________________________ Dev mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/dev
