[Soc-coordination] Status Report Week 1, Extending oath-toolkit and dynalogin to provide CROTP/OCRA authentication

Fabian Grünbichler fabian.gruenbichler at tuwien.ac.at
Fri Jun 21 13:59:03 UTC 2013


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

my GSOC project for Debian is extending oath-toolkit and dynalogin to
enable authentication via challenge-response based One Time Pad
mechanisms. The two mechanisms I selected are OCRA (by the Open
Authentication Foundation, which also designed the HOTP and TOTP
specifications) and CROTP (which is an extension of SASL).

To familiarize myself with the codebases of oath-toolkit and dynalogin
I started this week by getting rid of some code duplication in the
library functions for validating TOTP tokens. Generating or validating
a time-based TOTP value is done by calculating a counter value based
on a timestamp, an offset and a time step size. This counter value is
then used to calculate a OTP value with the HOTP algorithm.

liboath already provided API functions for validating TOTP values, one
of which also returned the position within a specified window (i.e.,
not only the TOTP for the current timestamp, but also for +- x time
steps is accepted as valid).

An application which uses HOTP or TOTP for authentication is supposed
to keep track of the OTPs already used (to prevent replay attacks).
This is done by storing the last used counter value.

For HOTP, this is easy, as the counter is controlled by the
application (the server side is required to increment the counter iff
it accepts an OTP value, the client side is required to increment it
everytime it generates a OTP value).

Since TOTP is time-based, this is not as easy. The counter is
calculated by liboath during generation/validation, and is based on
the timestamp and the two paramaters time step and offset. Prior to my
changes, the only way to get the counter value inside an application
using liboath was to calculate it twice - once inside the application
(e.g., dynalogin) and once inside liboath.

I extended liboath's API to include another set of validation methods
for TOTP which include a new parameter for storing the counter value.
By also accepting NULL values (for not storing the counter value) I
could simply move the code from the old API methods (which are now
just wrappers) to the newly introduced methods and extend it.

I also extended the TOTP validation test cases to test the new API
methods and documented my changes. The changes to liboath/oath-toolkit
will be part of the next stable release (2.2.0) and have already been
shared with upstream (i.e., one of the pkg-auth-maintainers).

I removed the now unnecessary duplicated code from libdynalogin and
replaced it with calls to the new methods. This change has already
been sent upstream (to my mentor) via a pull request.

I started writing stubs for a future liboath API for generating and
validating OCRA values, but these changes have not been committed yet.
Next week, I would like to finish an initial version of this API
(including tests) to get feedback from my mentor(s) and be able to
start working on other parts of the code base using this API the week
after that (oathtool, liboath's PAM module and dynalogin).

Kind Regards,
Fabian

p.s.
I track my projects on github, you can find the branch with updated
liboath TOTP validation API here:
https://github.com/Fabian-Gruenbichler/oath-toolkit/tree/expand-totp-api
and my dynalogin fork here:
https://github.com/Fabian-Gruenbichler/dynalogin .
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBAgAGBQJRxFwnAAoJEK4xK/RwikTnrYYP/jeuYtQ/qBLywsEVyWWtgWfD
5ep3Zwd4TblXd89DPBuO0u51ZFZem7YhxoNxPY8y2ovwAXCInDVCfrHcM7Z1GhUL
H5C7FxG1UJkBX2kxSKFRNYaNdBXvBblzd8Wh3eFz6Y25vi0b/5Axj5XN1asyFBwu
sXeHGxg8t0LJNxrJUrISKUF5IUjtYIs3gzDQ88s6p33QYhlkqo1KXJkpI4TAKdnO
zsZ5lgKOMazKWjuymou/hcrjURPdFb1ZZAjco2HWLufGgH3fhOOwRR97/sNF0rwr
V9jB+ERQxe7dmW0wMhX0gMhnwnLR5eEdLBnhhHp4GSpYzsr9kgNFyrKVU+Yxdtf3
GK21lq703D9ByWZ5rWUJLK4a5Lt/LgZHOAye3ytK3KWjor9zUxCJwSU0T+5BGzEj
G3YTWmPq0X6lzvGSU+3B2tT/88oS3To/Nbdilc4Q7XKZV9s6E3Wp05W6BXhpecB0
QGrbSbSKRYAjEKA91fSkKOHy0lJKYDSE+v0/0MPIwL13h2T7GZYsQ5lPyZ9Q/AKj
dKop171xadx5yi5iFHyl2/w6iQhgGwEf/9WsaVPD5o6WxxGqq077JpvMNte3eldH
wNrzkkxzrKwGZlpmPuNRFjEBi7vjAc7aZwWzyVtFuZ66M2osmcqesCNSc+1/oUPZ
eaBrnAwl51eQU7Njd7CJ
=K/b2
-----END PGP SIGNATURE-----



More information about the Soc-coordination mailing list