Differences between revisions 3 and 4
Revision 3 as of 2013-04-26 23:59:19
Size: 3844
Editor: ?FabianG
Comment:
Revision 4 as of 2013-04-30 12:55:25
Size: 4455
Editor: ?FabianG
Comment:
Deletions are marked like this. Additions are marked like this.
Line 7: Line 7:
 * '''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.
 * '''CROTP support for oath-toolkit'''
 * '''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 the challenge-response-based CROTP mechanism, which is itself an extension of the Salted Challenge Response Authentication Mechanism described in RFC 5802. 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).
CROTP basically extends SCRAM by including a OTP value in its client-side signature calculation (as well as the server's verification thereof). This means that most of the work is related to integrating oath-toolkit and SCRAM/SASL, or alternatively extending one of the SASL packages to include some CROTP mechanism (at least CROTP-SHA1 would be mandatory).
 * '''Synopsis''': Introducing necessary tools and libraries to implement the CROTP authentication mechanism
 * '''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 the challenge-response-based CROTP mechanism, which is itself an extension of the Salted Challenge Response Authentication Mechanism described in RFC 5802.

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).
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 oath-toolkit (similar to the ones offered for HO
TP 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 CROPT mechanism instead of plain HOTP or TOTP.
 * '''Synopsis''': Introducing necessary tools and libraries to implement the CROTP authentication mechanism in oath-toolkit and dynalogin.
Line 13: Line 20:
 * '''Deliverables''': A useable implementation of CROTP, details tbd together with mentor(s). Two possible ways are mentioned above - as part of oath-toolkit or by extending one of the SASL libraries/toolkits.
 * '''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). After an initial planning / conceptual phase of about two-three weeks, I would like to start coding.
 * '''Exams and other commitments''': I will have two or three exams at the end of 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 week) 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 :)).
 * '''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.
 * '''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 :)).

Fabian Grünbichler's Application

  • 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 the challenge-response-based CROTP mechanism, which is itself an extension of the Salted Challenge Response Authentication Mechanism described in RFC 5802.

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). 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 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 CROPT mechanism instead of plain HOTP or TOTP.

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

  • 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, 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.

  • 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.