| |
|
|
| |
|
|
|
Google Summer of Code 2009 proposals
Xelerance is the company behind GPL software such as Openswan and
Xl2tpd. Its opensource development specialises on projects involving
IPsec, DNSSEC and cryptographic software in general. Xelerance wishes to
enhance implementations of some cryptographic programs and protocols and to make deployments of
crpytopgrahic software, a nightmight in general, practical. Most of
our ideas for the GSoC are intended to make it easier to deploy these
technologies on laptops, servers, and embedded devices such as phones
and DSL routers (Linksys wrt, etc).
- Openswan Google Summer of Code ideas
- DNSSEC Google Summer of Code ideas
- OTR Google Summer of Code ideas
Contact: gsoc@xelerance.com
|
|
|
|
|
|
Openswan Google Summer of Code ideas
Openswan is an implementation of the IPSec and IKE protocols for Linux (and recently FreeBSD). It is
the defacto IPsec client used with most Linux distributions and Linux based VPN appliances.
|
Synopsis
|
OSX Cocoa GUI
|
|
Description
|
Openswan has recently been ported to OSX. Openswan runs through a few configuration files,
which are parsed by a library (libipsecconf). Commands to add, delete, up or down IPsec tunnels are done through a CLI.
The OSX Cocoa application would use the parser library to add, modify and remove IPsec tunnel definitions, and would
provide a GUI on top of the existing CLI commands.
|
|---|
|
Requirements
|
C++, Objective C, Human Interface Design, An OSX desktop
|
|---|
|
Difficulty
|
Medium - if student has knowledge of requirements
|
|---|
|
Mentor
|
Leigh Honeywell and Stefan Arentz (backup Patrick Naubert)
|
|---|
|
Notes
|
|
|---|
|
Synopsis
|
Openswan / Xl2tpd plugin for Network Manager
|
|---|
|
Description
|
Create an Openswan and xl2tpd plugin for the Linux desktop that uses Network Manager.
The plugin should allow PSK, X.509 and raw RSA for IPsec and support specifying an L2TP username
and password. Note that NetworkManager has some restrictions. It wants to communicate only
using its own datastore and command line paramters, and not via temporary files or other software
package files. Design a compromise that uses openswan and xl2tpd config files, command line
arguments, while trying to let NetworkManager store tunnel information using its own native
methods.
|
|---|
|
Requirements
|
Python with python-gtk or C with GTK, Human Interface Design
|
|---|
|
Difficulty
|
Medium
|
|---|
|
Mentor
|
Paul Wouters (backup Leigh Honeywell)
|
|---|
|
Notes
|
-
|
|---|
|
Synopsis
|
Openswan/Xl2tpd application for Android / Openmoko
|
|---|
|
Description
|
Create an Openswan and xl2tpd application for the Linux embedded environment, such as the Android
or Openmoko phone.
Openswan runs through a few configuration files, which are parsed by a library (libipsecconf).
Commands to add, delete, up or down IPsec tunnels are done through a CLI. A GUI wrapper that
fits in with the Window/Application Manager used on the phone would greatly assist deployment of
IPsec and xl2tpd on these devices. The GUI application should be able to configure and manager
PSK, X.509 and raw RSA for IPsec and support specifying an L2TP username and password.
|
|---|
|
Requirements
|
Python, GTK, Human Interface Design, a Linux desktop, and/or Android/Openmoko phone
|
|---|
|
Difficulty
|
Medium
|
|---|
|
Mentor
|
Paul Wouters (backup Leigh Honeywell)
|
|---|
|
Notes
|
We have a Neo Freerunner, but not an Android for the student
|
|---|
|
Synopsis
|
IPv6 verification
|
|---|
|
Description
|
Using the NETKEY builtin Linux IPsec stack, Openswan supports IPv6 with most of its scripts. However,
the configuration files and the libipsecconf parser do not consistently support IPv6 yet. The student would create
test cases for our existing test harness. Once these test cases exist, the student would identify problems where IPv6 is
not correctly handled, and resolve these issues. The testing infrastructure used by Openswan is
based on User Mode Linux(UML).
You can find examples of testcases in the openswan source code in openswan-2.6.x/testing/pluto/.
|
|---|
|
Requirements
|
Some knowledge of IPv6, shell scripts and/or tcl.
|
|---|
|
Difficulty
|
Writing the testcases should be fairly easy, as IPv4 testcases already exist. Fixing problems
in the parser and or other components will be more difficult. Setting up your environment to run
UML testcases is somewhat difficult at first, but a Mentor will assist you with that task.
|
|---|
|
Mentor
|
Leigh Honeywell (backup Patrick Naubert)
|
|---|
|
Notes
| - |
|---|
|
Synopsis
|
IKEv2 NAT and EAP extensions
|
|---|
|
Description
|
Build a EAP
extension for the IKEv2
IPsec protocol implementation of Openswan. Create testcases and perform at least one interop test
with another implementation.
|
|---|
|
Requirements
|
C, In depth knowledge of cryptography and protocol design
|
|---|
|
Difficulty
|
Very Hard
|
|---|
|
Mentor
|
Paul Wouters (backup Patrick Naubert)
|
|---|
|
Notes
| |
|---|
|
Synopsis
|
Openswan live test client and server implementation
|
|---|
|
Description
|
Often new endusers of Openswan have to fight all their battles at once. They need
to understand IPsec, networking, the Openswan configuration syntax and often specific IPsec hardware or software at the
other end of the IPsec tunnel. It then becomes hard to diagnose where your problems lie. The idea behind ipsec livetest
is to add a command that will attempt to setup various types of predefined IPsec tunnels to the Xelerance IPsec test network.
Users do not need to worry about Openswan syntax or configuration of the other end of the IPsec tunnel, and can thus easilly
find any anomalies in their ISP's network such as IP filters, Path MTU issues, MTU size problems, routing issues, etc.
This functinality would be incorporated to the Openswan software. There is a very rough proof of concept code written for this,
but the student will have to write the openswan client scripts, as well as implement the Xelerance livetest network end on one
or more Xen servers running Linux.
|
|---|
|
Requirements
|
Basic networking, Python/Perl or shell scripting [tbd]
|
|---|
|
Difficulty
|
Easy
|
|---|
|
Mentor
|
Leigh Honeywell (backup Paul Wouters)
|
|---|
|
Notes
| - |
|---|
See Openswan
|
|
|
|
|
|
DNSSEC Google Summer of Code ideas
DNSSec is the next generation DNS system, which provides secure and authoritative DNS lookups. It was recently approved as an IETF standard -
RCF4033,
RCF4034,
RCF4035.
Since there can not be a flag day for switching DNS to DNSSEC, this raises a lot of deployment
questions. Deployment issues exist for the enduser and applications, the zone administrator, the
resolver administrators at ISP's, and the TLD administrators.
|
Synopsis
|
Build tools for creating and publishing DNSSEC test data
|
|---|
|
Description
|
To test DNSSEC software implementations, there is a need for a large set of DNSSEC data representation all of
the good and bad situations that can occur. Examples include bad DNSKEY records, expired signatures, broken
signatures, wrong DS record, modified zones after signing, etc etc. Since all of this data is time sensitive, the
test data has to be re-created periodically (say every week). Once this data set has been created, testcases can
be written for testing DNSSEC resolvers such as ISC Bind nameserver,
or the NLnetlabs unbound nameserver, the
ldns library
resolver library, or future secure resolver implementations. This data can also be used to test
RFC-5011 implementations,
such as the autotrust daemon.
|
|---|
|
Requirements
|
Some DNS knowledge, python or perl or ruby.
|
|---|
|
Difficulty
|
Easy
|
|---|
|
Mentor
|
Paul Wouters (backup Leigh Honeywell)
|
|---|
|
Notes
|
The data, like the software, will be published in Xelerance's DNSSEC server for testing by third parties.
|
|---|
|
Synopsis
|
Automatic discovery of DNSSEC deployment in TLDs and other high profile domains
|
|---|
|
Description
|
Have an automated tool represent, via Google MAPS API, the current testing and production deployments of DNSSEC at TLD's.
Include an open mailing list service to receive announcements if existing DNSKEY's in TLD's change, or new ones are
added. Include pointers on the google MAPS to the responsible NIC organisations' DNSSEC information page. In other words,
a more automated version of www.xelerance.com/dnssec
|
|---|
|
Difficulty
|
Easy
|
|---|
|
Mentor
|
Leigh Honeywell (backup Paul Wouters)
|
|---|
|
Notes
|
The data will be put in the public domain. In addition, Xelerance will host this data for use with by third parties. Software will
obviously also be opensource.
|
|---|
|
Synopsis
|
Automatic DNSSEC Lookaside Verification(DLV)
submission on behalve of DNS zone administrators to encourage further DNSSEC deployment.
|
|---|
|
Description
|
Create the XML tools to talk to the Internet Software Concortium's DLV
server to submit DNSSEC keys from
nameservers to their registration XML interface for transparent addition/updating of DLV records.
This will increase DNSSEC deployment in TLD's that are not going to be signed for a while, such as .com.
|
|---|
|
Requirements
|
Basic understanding of DNS, Communications skills
|
|---|
|
Difficulty
|
Easy
|
|---|
|
Mentor
|
Leigh Honeywell (backup Paul Wouters)
|
|---|
|
Notes
|
In collaboration with ISC contact
|
|---|
|
Synopsis
|
Create an easy to use system-config-dnssec for Fedora to allow easy GUI based DNSSEC administration.
|
|---|
|
Description
|
Xelerance wrote an extremely simple prototype for this that needs to be replaced by a version with
a few more real features. It only uses calls to dnssec-configure and dnskey-pull from the
dnssec-conf package. This is mostly a GUI implementation for on top of dnssec-conf. This uses python and glade.
|
|---|
|
Requirements
|
Fedora/RHEL/Centos knowledge, python, glade
|
|---|
|
Difficulty
|
Easy
|
|---|
|
Mentor
|
Paul Wouters (backup Leigh Honeywell)
|
|---|
|
Notes
|
See DNSSEC
|
|---|
|
Synopsis
|
Investigate and/or implement DNSSEC based anti-spam meassures
|
|---|
|
Description
|
With DNSSEC verification, we can detect DNS spoofing, and thus detect both spoofed email as well as bogus phising sites.
Write a sendmail milter and postfix plugin that drop known (by DNSSEC) forged HELO strings. Write spamassassin rules
to give points based on DNSSEC verification. Look into the current state of DNSSEC patches and plugins for Firefox, and
integrate them with the recent "anti phising" W3C API. Use either drill, the SPARTA dnssec tools or unbound-libs to
base the software on.
|
|---|
|
Requirements
|
C, SMTP knowledge, some experience with sendmail, postfix, spamassassin and firefox.
|
|---|
|
Difficulty
|
Some parts are Easy or Medium, some parts will be Hard.
|
|---|
|
Mentor
|
Leigh Honeywell (Paul Wouters)
|
|---|
|
Notes
|
See dnssec-tools.org
|
|---|
|
|
|
|
|
|
OTR Google Summer of Code ideas
Off the Record is a protocol for securing IM messages designed By Ian Goldberg and Nikita Borisov. In contrast to most encryption plugins
for IM clients, it supports deniability. Therefor, it does not use standard symmetric key encryption,
or digitally signed mesages. Instead it uses a Diffie-Hellman key exchange per IM message.
|
Synopsis
|
Add support for Finch, the text-only version of Pidgin, to the pidgin-otr plugin.
|
|---|
|
Description
|
There is no text-only OTR client for Linux. A lot of people run text-only clients, and would
benefit from having a text-only OTR client that can run in screen.
|
|---|
|
Requirements
|
C, cryptographic knowledge
|
|---|
|
Difficulty
|
Hard
|
|---|
|
Mentor
|
Leigh Honeywell (backup Patrick Naubert)
|
|---|
|
Notes
|
In collaboration with Ian Goldberg
|
|---|
|
Synopsis
|
Implement OTR protocol version 2 feature for generating temporary symmetric keys
|
|---|
|
Description
|
The OTR protocol is not well suited for using encrypted file transfers or VOIP and VIDEO streams, since it is impossible to
generate that many Diffie-Hellman key exchanges. The OTR protocol has been expanded to allow the
creation of temporary symmetric
keys and their secure transfer between two clients. Verify the version 2 protocol extensions into libotr for usability, and extend the
pidging-otr plugin to be able to use these for encrypted file downloads or as key for setting up an IPsec tunnel between the two hosts.
|
|---|
|
Requirements
|
C, cryptographic knowledge
|
|---|
|
Difficulty
|
Hard
|
|---|
|
Mentor
|
Leigh Honeywell (backup Patrick Naubert)
|
|---|
|
Notes
|
In collaboration with Ian Goldberg
|
|---|
|
Synopsis
|
Implemented location based security plugin for OTR.
|
|---|
|
Description
|
Ian Goldberg, Urs Hengartner and Ge Zhong have designed a location privacy protocol that can work with OTR which would allow a person (phone) to limit sending
out their location information to only those friends that are near by enough. This prevents someone
from needing to tell all their friends where they are, without compromising hooking up with nearby friends.
Two friends will not know each others whereabouts, unless they are both within the minimum range
specified by each other. For more information see
Uwaterloo NearbyFriend
|
|---|
|
Requirements
|
C, GTK
|
|---|
|
Difficulty
|
Medium to Hard
|
|---|
|
Mentor
|
Leigh Honeywell (backup Patrick Naubert)
|
|---|
|
Notes
|
In collaboration with Ian Goldberg
|
|---|
See OTR
|
|
|
|
|
| |
|
|
|
