Differences between revisions 6 and 7
Revision 6 as of 2013-04-30 13:05:11
Size: 4759
Editor: ?FabianG
Comment:
Revision 7 as of 2013-05-17 19:37:47
Size: 5772
Editor: ?FabianG
Comment: Updated in accordance with prospective mentors/pkg-auth-maintainers
Deletions are marked like this. Additions are marked like this.
Line 3: Line 3:

 * '''Name:''' Fabian Grünbichler
 * '''E-Mail''': fabian.gruenbichler[a]tuwien.ac.at (GPG-encrypted preferred)
 * '''XMPP''': fabian[a]jabber.at (OTR)
 * '''Background''': I am a 24 years old software engineering master's student from Vienna, Austria. I have been using Debian in different setups for quite some time (around 6 years), but have never actively contributed before. I am most proficient in C and Java, but can also churn out code in Python, Ruby or PHP if need be. One of my main interests regarding IT and software is security, which was one of the reasons why I chose a security evaluation of a typical Typo3 installation as my bachelor thesis and project. I am an advocat of free and open source software as well as meaningful security solutions for everyone (such as accessable encrypted communication methods and secure information storage). My native tongue is German. More information about me can be found in my introduction email to the pkg-auth-maintainers list.
 * '''CROTP support for oath-toolkit and dynalogin'''
 * '''Project details''':
== Personal and Contact Information ==
'''Name:''' Fabian Grünbichler
'''E-Mail''': fabian.gruenbichler[a]tuwien.ac.at (GPG-encrypted preferred)
'''XMPP''': fabian[a]jabber.at (OTR)
=== Background ===
I am a 24 years old software engineering master's student from Vienna, Austria. I have been using Debian in different setups for quite some time (around 6 years), but have never actively contributed before. I am most proficient in C and Java, but can also churn out code in Python, Ruby or PHP if need be. One of my main interests regarding IT and software is security, which was one of the reasons why I chose a security evaluation of a typical Typo3 installation as my bachelor thesis and project. I am an advocat of free and open source software as well as meaningful security solutions for everyone (such as accessable encrypted communication methods and secure information storage). My native tongue is German. More information about me can be found in my introduction email to the pkg-auth-maintainers list.
== CROTP support for oath-toolkit and dynalogin ==
=== Project Details ===
Line 12: Line 13:
This project would introduce another possibility to perform authentication via the challenge-response-based CROTP mechanism, which is itself an extension of the Salted Challenge Response Authentication Mechanism described in RFC 5802. This project would introduce another possibility to perform authentication via one or both of the following new challenge-response-based mechanisms: OCRA (OATH Challenge Response Authentication, RFC 6287) and/or CROTP ([[http://tools.ietf.org/html/draft-josefsson-kitten-crotp-00 | IETF Draft]]), which is itself an extension of the Salted Challenge Response Authentication Mechanism described in RFC 5802.
Line 14: Line 15:
Since SCRAM is in widespread use as SASL and GSS-API authentication mechanism, CROTP could play an important role in furthering secure, connection oriented authentication for various applications (such as LDAP or mail servers). OCRA has a similar structure as HOTP/TOTP, but offers more flexibility regarding the information and hash algorithm which are used for computing and validating authentication data, as well as allowing for (additional) non-SSL/TSL based (i.e., challenge-response based) authentication of one or both parties involved in the authentication process. These benefits (and the fact that it is officially part of the mechanisms specified by the OATH foundation) make it well suited for integration into oath-toolkit and dynalogin.

SCRAM on the other hand is already in widespread use as SASL and GSS-API authentication mechanism, therefore CROTP could play an important role in furthering secure, connection oriented authentication for various applications (such as LDAP or mail servers).
Line 17: Line 20:
Because a Challenge-Response based authentication mechanism requires back and forth communication between a client and a server, I would like to first implement the necessary API functions in oath-toolkit (similar to the ones offered for HOTP and TOTP at the moment), i.e. for creating and validating CROTP authentication messages. These functions could then be used to integrate CROTP authentication into other software packages. As part of the project I would like to implement such functionality for the dynalogin packages, allowing a client using libdynaloginclient to authenticate with a dynalogind server using the CROTP mechanism instead of plain HOTP or TOTP.
 * '''Synopsis''': Introducing necessary tools and libraries to implement the CROTP authentication mechanism in oath-toolkit and dynalogin.
Because a Challenge-Response based authentication mechanism requires back and forth communication between a client and a server, I would like to first implement the necessary API functions in the relevant packages:
 *
oath-toolkit for OCRA, similar to the ones offered for HOTP and TOTP at the moment)
 * li
bgsasl or similar for CROTP, which provides SASL based authentication schemes for amongst others various LDAP packages
These functions could then be used to integrate challenge-response and OTP based
authentication into other software packages. As part of the project I would like to implement such functionality for the dynalogin packages, allowing a client using libdynaloginclient to authenticate with a dynalogind server using the CROTP and/or OCRA mechanism instead of plain HOTP or TOTP.

 * '''Synopsis''': Introducing necessary tools and libraries to implement the CROTP and/or OCRA authentication mechanism in oath-toolkit/libgsasl and dynalogin.
Line 23: Line 30:
 * '''Deliverables''': A useable implementation of CROTP, details tbd together with mentor(s). My suggestion can be found above.
 * '''Project schedule''': The schedule of this project is very much dependent on the scope, which can easily be extended (for example to include more hashing or OTP algorithms, CROTP-SHA1 is the only mandatory variant according to the standard). After an initial planning / conceptual phase of about two-three weeks, I would like to start coding.
 * '''Deliverables''': A useable implementation of CROTP and/or OCRA, details tbd together with mentor(s). My suggestions can be found above.
 * '''Project schedule''': The schedule of this project is very much dependent on the scope, which can easily be extended - for example by doing both OCRA and CROTP, including a lot of different subsets and variants (e.g., CROTP only requires implementations to support CROTP-SHA1, but specifies many more combinations). After an initial planning / conceptual / discussion phase of about two to three weeks, I would like to start coding.

Fabian Grünbichler's Application

Personal and Contact Information

Name: Fabian Grünbichler E-Mail: fabian.gruenbichler[a]tuwien.ac.at (GPG-encrypted preferred) XMPP: fabian[a]jabber.at (OTR)

Background

I am a 24 years old software engineering master's student from Vienna, Austria. I have been using Debian in different setups for quite some time (around 6 years), but have never actively contributed before. I am most proficient in C and Java, but can also churn out code in Python, Ruby or PHP if need be. One of my main interests regarding IT and software is security, which was one of the reasons why I chose a security evaluation of a typical Typo3 installation as my bachelor thesis and project. I am an advocat of free and open source software as well as meaningful security solutions for everyone (such as accessable encrypted communication methods and secure information storage). My native tongue is German. More information about me can be found in my introduction email to the pkg-auth-maintainers list.

CROTP support for oath-toolkit and dynalogin

Project Details

Currently oath-toolkit supports two of the main one time pad standards: the event-based HOTP algorithm (RFC 4226) and its time-based extension TOTP (RFC 6238).

This project would introduce another possibility to perform authentication via one or both of the following new challenge-response-based mechanisms: OCRA (OATH Challenge Response Authentication, RFC 6287) and/or CROTP (IETF Draft), which is itself an extension of the Salted Challenge Response Authentication Mechanism described in RFC 5802.

OCRA has a similar structure as HOTP/TOTP, but offers more flexibility regarding the information and hash algorithm which are used for computing and validating authentication data, as well as allowing for (additional) non-SSL/TSL based (i.e., challenge-response based) authentication of one or both parties involved in the authentication process. These benefits (and the fact that it is officially part of the mechanisms specified by the OATH foundation) make it well suited for integration into oath-toolkit and dynalogin.

SCRAM on the other hand is already in widespread use as SASL and GSS-API authentication mechanism, therefore CROTP could play an important role in furthering secure, connection oriented authentication for various applications (such as LDAP or mail servers). CROTP basically extends SCRAM by including an OTP value in its client-side signature calculation (as well as the server's verification thereof).

Because a Challenge-Response based authentication mechanism requires back and forth communication between a client and a server, I would like to first implement the necessary API functions in the relevant packages:

  • oath-toolkit for OCRA, similar to the ones offered for HOTP and TOTP at the moment)
  • libgsasl or similar for CROTP, which provides SASL based authentication schemes for amongst others various LDAP packages

These functions could then be used to integrate challenge-response and OTP based authentication into other software packages. As part of the project I would like to implement such functionality for the dynalogin packages, allowing a client using libdynaloginclient to authenticate with a dynalogind server using the CROTP and/or OCRA mechanism instead of plain HOTP or TOTP.

  • Synopsis: Introducing necessary tools and libraries to implement the CROTP and/or OCRA authentication mechanism in oath-toolkit/libgsasl and dynalogin.

  • Contributions to Open Source Projects:

A (not yet publicly disclosed) vulnerability report regarding a Typo 3 extension is currently in the works (this was a result of my BSc thesis project) A small bugfix for dynalogin can be found here.

  • Benefits to Debian: An implementation of a modern, secure additional authentication mechanism, based on widespread standards already included in Debian and used by many applications. Extension of currently available facilities to use one time pads as part of a two-factor authentication process, hopefully paving the road for further integration into different applications and eventually replacing authentication solely based on passwords.

  • Deliverables: A useable implementation of CROTP and/or OCRA, details tbd together with mentor(s). My suggestions can be found above.

  • Project schedule: The schedule of this project is very much dependent on the scope, which can easily be extended - for example by doing both OCRA and CROTP, including a lot of different subsets and variants (e.g., CROTP only requires implementations to support CROTP-SHA1, but specifies many more combinations). After an initial planning / conceptual / discussion phase of about two to three weeks, I would like to start coding.

  • Exams and other commitments: I will have two or three exams at the end of the summer term (June). I will work part-time (12h/week) until the middle of July.

  • Other summer plans: I will probably take a short trip (1-2 weeks) sometime in August. Details are not yet fleshed out ;) If possible I would also like to participate at Debcon (Switzerland is not that far from Vienna :)).

  • Why Debian?: I have been a long-time user of Debian (and before that, Debian-based projects). Since I also support the politics / philosophy behind the project, I want to give back in a better way than just promoting Debian among my peers. Furthermore, Debian has quite a good reputation as far as security is concerned, which I find appealing.

  • I am not applying for any other GSoC projects.