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

[Fabian Grünbichler]

Hello,

sorry for the late report..

This week I implemented an initial version of OCRA support in dynalogin.
I also refactored and extended my oath-toolkit additions a little bit.

*Stuff done this week*
.) Added a new API method to liboath to convert a challenge string to a
byte-array - numerical challenges are converted to a base16 string and
then to a byte-array, hexadecimal challenges are simply converted to a
byte-array and alpha-numeric challenges are simply copied. The
base16-strings need to be padded with a zero at the end in case their
length is odd.
.) Extended datasources to store information needed for OCRA
.) Extended libdynalogin to provide a wrapper method for generating and
converting challenges
.) Extended libdynalogin to provide an authenticate wrapper for OCRA
.) Extended dynalogind's protocol to allow challenge generation and OCRA
authentication
.) Extended libdynaloginclient to provide a new API method to request a
challenge from a dynalogind instance

The challenge protocol is modelled after the authentication protocol:
if a client sends a "CHALL <user>" string to dynalogind, it will lookup
the ocra suite to get the challenge specification and generate a
challenge accordingly. The challenge string is sent back to the client,
and the last user and challenge byte-array is stored until the next
authentication attempt. Authentication via OCRA follows the same
protocol as HOTP/TOTP: sending "UDATA OCRA <user> <code>" to dynalogind
will trigger a validation call by dynalogind, iff the user exists and
matches the user who generated the last challenge (on this
connection/thread). The authentication result is then sent back to the
client and the stored used and challenge are erased (to prevent replay
attacks).

I spent quite some time figuring out way I can't get dynalogin to work
(like I already did during the application period) until I finally
realized that dynalogin depends on libgnutls28(-dev), while parts of
oath-toolkit depend on libgnutls26(/libgnutls-dev). I had the latter
installed from working on oath-toolkit, which was enough to compile
dynalogin, but dynalogind didn't accept any TLS connections. I worked
around it by disabling the libpksc part of oath-toolkit (which I don't
use), so now I switched to libgnutls28-dev and can compile both packages.

*TODO for dynalogin*
.) Extend PAM module to support OCRA
.) Extend testing program to support OCRA
.) Think of a way to implement two-way authentication
.) More extensive datasource tests (most tests were carried out using
the example datasource)
.) Include session information and password hash in OCRA calculation (if
specified).

The last point could work by replacing the password data stored for
every user with a password hash (for users that use OCRA).
Alternatively, the stored password could be hashed by libdynalogin
before calling liboath, but this might introduce new dependencies.

Since dynalogin does not calculate the code on the client side (but
delegates this to a token/some other software), session information will
be kind of hard to use (e.g., one cannot use TLS session information,
because that is not available on the token). I will ask my mentors for
input on this topic.

*TODO for oath-toolkit*
.) Hashing functions
.) Two-way authentication?

*Plans for next week*
None, except occasional bug-fixing here and there - I will be on
vacation until August 2nd.

Kind regards,
Fabian