GSoC: Difference between revisions
Paul Wouters (talk | contribs) |
Paul Wouters (talk | contribs) No edit summary |
||
| Line 54: | Line 54: | ||
= | = Extend RFC-7427 Signature Authentication support to IKEv2 with ECC / EDDSA support = | ||
'''Required Skills:''' C programming, RFC interpretation, PKIX/X.509/ASN knowledge. | '''Required Skills:''' C programming, RFC interpretation, PKIX/X.509/ASN knowledge. | ||
'''Libreswan Mentors:''' Tuomo Soini, Kim BCG | '''Libreswan Mentors:''' Tuomo Soini, Kim BCG | ||
This project builds on top of last year's GSoC project to add support for RFC-7427. | |||
IKEv2 performs authentication by using separate mechanism to specify the authentication method as specified in the IANA IKEv2 Authentication Method: | IKEv2 performs authentication by using separate mechanism to specify the authentication method as specified in the IANA IKEv2 Authentication Method: | ||
| Line 64: | Line 66: | ||
http://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-12 | http://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-12 | ||
The IPsec Working Group at IETF | The IPsec Working Group at IETF realized using a separate number whenever a new algorithm is added is not very friendly for implements. It basically duplicates the OIDs and SubjectPublicKeyInfo data structures. RFC-7427 generalizes IKEv2 signature support to allow any signature method supported by PKIX and also adds signature hash algorithm negotiation. | ||
Libreswan itself currently only supports RSA as digital signature authentication method, so it needs to be extended internally as well to be able to use other methods, such as ECDSA or EDDSA. Libreswan uses the NSS library for both PKCS#11 and for algorithm implementations. | |||
= Add EAP Authentication support to IKEv2 = | = Add EAP Authentication support to IKEv2 = | ||
| Line 104: | Line 88: | ||
= Implement | = Implement TLS Encapsulation of IKE and IPsec Packets = | ||
This project | This project builds on last year's GSoC's project that added TCP support to IKE (and soon the Linux kernel will be able to support TCP for ESP) as per RFC 8229. | ||
The next step is to add support for IKEinTLS and IKEinESP support. This will enhance the protocol to be used in networks that only reliably allow HTTP and HTTPS traffic. | |||
The student would have to take a look at the kernel TLS support, and look at what the best way is for this support to be implemented - Via kernel TLS with a minimal | |||
userspace component for the handshake, or by pulling in all ESPinTLS packets from the kernel into the userland. | |||
While we can assist a bit with the kernel work, we are not kernel developers. However, if someone is interested in this project, we will look and see if we can find a willing kernel developer to co-mentor. | While we can assist a bit with the kernel work, we are not kernel developers. However, if someone is interested in this project, we will look and see if we can find a willing kernel developer to co-mentor. | ||
| Line 114: | Line 101: | ||
'''Libreswan Mentors''': Hugh Redelmeier, Paul Wouters | '''Libreswan Mentors''': Hugh Redelmeier, Paul Wouters | ||
The libreswan IKE daemon basically consists of a libevent based loop that waits for events. Currently these events can be incoming UDP or TCP traffic, commands over a unix domain socket, timed events and crypto or DNS helper events. Listening to TLS streams in such a way as to not open up the daemon for DDoS attacks is required for this implementation. This requires some architecture work for which we have the original daemon author (Hugh) available as mentor. | |||
The libreswan IKE daemon basically consists of a libevent based loop that waits for events. Currently these events can be incoming UDP traffic, commands over a unix domain socket, timed events and crypto or DNS helper events. Listening to | |||
* [https://tools.ietf.org/html/rfc8229 TCP Encapsulation of IKE and IPsec Packets] | |||
= Create a web based Certificate and Profile User Interface = | = Create a web based Certificate and Profile User Interface = | ||
Revision as of 22:13, 14 January 2018
Google Summer of Code Ideas Page
While IKE and IPsec have been around for almost 20 years, like SSL/TLS, the protocols are still evolving and getting new features to deal with an ever changing world. The Libreswan Project's core developers have come up with a list of projects that they believe would be interesting for students to work on. The mentors have a personal interest in these projects as well. If any of these projects look interesting to you, feel free to contact the developers either on the developer mailinglist or the #swan channel on the FreeNode IRC network. You can also email Paul Wouters <paul@nohats.ca> who is the main contact for the GSoC Project with any questions you have or if you would like to introduce yourself.
A quick overview and history of The Libreswan Project was presented by Paul Wouters as part of the Opportunistic IPsec presentation at the 2016 [Linux Security Summit]. There is also a Video Recording of the presentation.
Re-implement the KVM/python based testing infrastructure
Required Skills: General DevOps and Virtualization skills, python and shell scripting
Libreswan Mentors: Andrew Cagney, Antony Antony, Paul Wouters
The goal is to investigate using another container technology that is better suited for our use. This could be raw namespaces, "unshare", kubernetes, docker (without systemd), openshift, openstack or something else. Note that since it needs to support containerized IPsec kernel stacks, LXC or vserver will not work.
The following new properties are desired for the new test harness:
- Allow most tests to run with containers running libreswan, instead of VMs running libreswan
- It should be able to run many tests in parallel on 1 machine
- It should be able to spread jobs on multiple machines
- Distinguish minor issues (diff in output) from major issues (different number of IKE or IPsec SA's)
- Be as independent from the host OS as possible
- Keep similar web based reporting output
The following properties of the current test harness should not be lost:
- Existing test case reference output should be re-used as much as possible (https://github.com/libreswan/libreswan/tree/master/testing/pluto)
- Capture all network traffic on all interfaces
- Capture all console / log output
- Run with the least amount of privileges / root access
- Run with the existing sanitizers (https://github.com/libreswan/libreswan/tree/master/testing/sanitizers [testing/sanitizers/])
- Extend the current init -> run -> final scripting to allow multi order scripts (run1 on vm1, run2 on vm3, run3 on vm1, run4 on vm2, etc)
- IPv4, IPv6, and NAT/non-NAT networks required for testing (current setup using the "nic" VM for all of this)
- Use existing X.509 certificate generation (https://github.com/libreswan/libreswan/tree/master/testing/x509 [testing/x509/])
- Allow the use of faketime to run individual containers in the past or future.
- Bonus: Support FIPS mode and SElinux/MLS for Labeled IPsec
- Bonus: Test different versions / architectures against each other
The libreswan testing infrastructure has its roots in the ancient UserModeLinux (UML). It ran for a number of years until UML stopped working reliably on newer kernels. In 2012 this system was migrated to the current system which us based on KVM, QEMU and libvirt tied together with python code. This system is used daily for automated testing as well as by most libreswan developers when working on specific code. Anyone can run these tests on their server or laptop as documented at Test_Suite
Daily test results are available at Daily Test Results and an example run can be found at http://testing.libreswan.org/results/testing/3.19-79-g99db3b6-master/
There are currently around 600 test cases that involve booting 2 to 4 VMs to install various IPsec tunnels. The console output is captured, sanitized and compared against known good output. It takes about 8 hours to run and most of the time is lost waiting on VMs to startup and shutdown. Test cases consist of "init", "run" and "final" shell scripts that perform the actual test. You can browse our test cases at testing/pluto
Waiting 8 hours to see if a code change breaks anything is not pleasant. An attempt was made to speed things up dramatically using docker instead as documented at [Test_Suite_-_Docker]
Unfortunately, our experiment with docker turned out to be very slow as well, mostly due to the additional overhead of systemd and the plumbing to support multiple interfaces which we need for our tests.
Extend RFC-7427 Signature Authentication support to IKEv2 with ECC / EDDSA support
Required Skills: C programming, RFC interpretation, PKIX/X.509/ASN knowledge.
Libreswan Mentors: Tuomo Soini, Kim BCG
This project builds on top of last year's GSoC project to add support for RFC-7427.
IKEv2 performs authentication by using separate mechanism to specify the authentication method as specified in the IANA IKEv2 Authentication Method:
http://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-12
The IPsec Working Group at IETF realized using a separate number whenever a new algorithm is added is not very friendly for implements. It basically duplicates the OIDs and SubjectPublicKeyInfo data structures. RFC-7427 generalizes IKEv2 signature support to allow any signature method supported by PKIX and also adds signature hash algorithm negotiation.
Libreswan itself currently only supports RSA as digital signature authentication method, so it needs to be extended internally as well to be able to use other methods, such as ECDSA or EDDSA. Libreswan uses the NSS library for both PKCS#11 and for algorithm implementations.
Add EAP Authentication support to IKEv2
Required Skills: C programming, NSS crypto library, RFC interpretation
Libreswan Mentors: Tuomo Soini, Paul Wouters
Most EAP implementations are based on wpa_supplicant and openssl. Unfortunately, libreswan uses the NSS library. The student will investigate what EAP support and/or modules are available for NSS to implement one or two EAP methods.
Desired EAP implementations - most desired ones listed first:
- EAP in IKEv2
- EAP-TTLSv0 (for EAP-MSCHAPv2)
- RFC 5216: EAP-TLS Authentication Support for IKEv2
- RFC 5998: An Extension for EAP-only Authentication in IKEv2
- RFC 5216: EAP-TLS Authentication Support for IKEv2
- RFC 5106: EAP-IKEv2 Method
Implement TLS Encapsulation of IKE and IPsec Packets
This project builds on last year's GSoC's project that added TCP support to IKE (and soon the Linux kernel will be able to support TCP for ESP) as per RFC 8229. The next step is to add support for IKEinTLS and IKEinESP support. This will enhance the protocol to be used in networks that only reliably allow HTTP and HTTPS traffic. The student would have to take a look at the kernel TLS support, and look at what the best way is for this support to be implemented - Via kernel TLS with a minimal userspace component for the handshake, or by pulling in all ESPinTLS packets from the kernel into the userland.
While we can assist a bit with the kernel work, we are not kernel developers. However, if someone is interested in this project, we will look and see if we can find a willing kernel developer to co-mentor.
Required Skills: C programming, Advanced Network Programming, RFC interpretation
Libreswan Mentors: Hugh Redelmeier, Paul Wouters
The libreswan IKE daemon basically consists of a libevent based loop that waits for events. Currently these events can be incoming UDP or TCP traffic, commands over a unix domain socket, timed events and crypto or DNS helper events. Listening to TLS streams in such a way as to not open up the daemon for DDoS attacks is required for this implementation. This requires some architecture work for which we have the original daemon author (Hugh) available as mentor.
Create a web based Certificate and Profile User Interface
Required Skills: Web backend coding (ruby, python, php) and the use of certificate/openssl related crypto modules for that language
Libreswan Mentors: Tuomo Soini, Paul Wouters
Currently, there are shell scripts for creating X.509 certificates, revoking certificates and signing CRLs and scripts for the creation of Profile files for certain devices such as Apple OSX and iOS. These require careful specification of various certificate attributes so that these certificates work on a variety of devices: Android, Windows, iOS/OSX, Linux, etc. The goal of this project is to gather all that knowledge into a simple to use interface that supports:
- Generating the proper ipsec.conf configuration based on web admin interface
- Allow Administrator to input only an email address to send an invite to a new user
- A new user can arrive at the portal, pick up their certificate/profile (over TLS)
- The web portal will not allow the profile/cert to be downloaded more then once
- Admin page allows listing/revocation of certificates
- Generate PKCS#12 certificates for endusers
- Generate iOS/OSX .mobileconfig profiles for automatic installation on OSX / iOS
Extend the Linux NetworkManager plugin for IKEv2 based connections
Required Skills: C programming, Advanced Network Programming, RFC interpretation
Libreswan Mentors: Hugh Redelmeier, Paul Wouters
Over at the GNOME Projects lives the NetworkManager-libreswan plugin for libreswan. This Linux Desktop application currently only supports XAUTH (aka Cisco IPsec) using IKEv1 and PreShared Keys. The goal of this project is to extend this to support IKEv2 based VPNs as well as certificate based authentication. This project will be using a new dbus interface to better integrate with both NetworkManager and libreswan. Libreswan;s dbus API is currently being developed.
Opportunistic IPsec development using LetsEncrypt
Required Skills: DevOps, scripting (python, shell), PKIX/X.509
Libreswan Mentors: Paul Wouters, Tuomo Soini
Opportunistc IPsec is an attempt to encrypt the internet at large. The idea is to build VPN tunnels directly to all internet hosts irrespective of the communication used. This concept has its origins with The FreeS/WAN Project started by John Gilmore in late 90's. An initial proof of concept was created that leverages LetsEncrypt certificates for use with IKE and IPsec. The goal of this project is to turn this proof of concept into production quality code that makes it trivial to enroll and deploy on any server and any client.
- Automate the enrollment and updating of LetsEncrypt certificates for use with libreswan
- Implement a DNS / DNSSEC based method for advertising Opportunistic IPsec support using LetsEncrypt for servers
- Design a non-DNS based method for publishing support of LetsEncrypt based Opportunistic IPsec for servers
- Enhance libreswan to allow a secure fallback to the existing NULL Authentication nethod