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

[Fabian Grünbichler]

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

Hello everyone,

this week I again spent some time polishing and refactoring old code
as well as extending OCRA support within oath-toolkit.

*Work done this week*

.) Add man pages (this were just some simple additions to a Makefile
and some gdoc comments for methods)
.) Add method for pseudo randomly generating challenge strings based
on type and length (e.g., NUM 8 -> 12345678, HEX 6 -> A5B6C7, ...)
.) Refactor and extend usersfile storage to support OCRA as algorithm
.) Add method to usersfile for just retrieving the mode; this is
needed for knowing the challenge parameters
.) Refactor and extend PAM module to support OCRA one way authentication

The PAM module now retrieves the mode for the user who tries to
authenticate (according to the usersfile). If the mode is not OCRA,
everything works like before. If it is OCRA, the module parses the
OCRA suite parameters and generates a challenge string according to
the specification. This challenge string is converted to a byte-array
(for passing to the validation method).

If the OCRA suite specifies that a counter should be included as input
to the hashing function, the counter value stored in the usersfile is
used (and, after successful validation, incremented by one). If
neither timestamp nor counter is specified, the OCRA values would be
potentially susceptible to a replay attack (because the OCRA value
would solely be dependent on the static secret key and the challenge
value, which might be repeated given enough authentication attempts).
It is therefore recommended to either include timestamp or counter or
to choose a big challenge length.

As soon as the missing hashing methods are established, I would like
to include password hashing as part of the PAM module. If a password
is stored in the usersfile and password hashing is specified as part
of OCRA suite, the usersfile_authenticate2 method should calculate a
hash of the password using the specified hashing method and include it
as part of the datainput.

I am not quite sure whether the PAM module should support two-way
authentication (i.e., the user gives a challenge, the pam module
generates and displays an OCRA value and a new challenge, the user
validates the displayed OCRA value and calculates its own value based
on both challenges, the PAM module validates this OCRA value). There
are basically two approaches: having a global OCRA suite parameter and
key for all users (i.e., as PAM module parameter) or having a
different suite and key for each user. The latter would be a little
bit more flexible and secure. I would need to read up a bit more on
PAM api methods (for my current changes, I left the user interaction
part basically untouched, in this case, I would need to add more code
of my own).

I am not yet sure whether and how to include session information as
part of the PAM process - my current opinion is that this is
unnecessary (as it would make the module less easy to use with
tokens). I think session information will be more relevant next week
when I implement OCRA for dynalogin - since we have a TLS / TCP
session :) and control both server and client.

*TODO*

.) Support for SHA256 and 512 (in general, pending feedback/input by
mentors)
.) Support for password hashing as part of the PAM module (depends on ^)
.) More extensive testing of the PAM module
.) Maybe add two-way authentication support

*Plans for next week*

.) Finish hashing methods (if possible)
.) Start working on dynalogin

If possible, I would like to finish the dynalogin part until next
Friday. This consists of three parts: Extending the existing data
sources to support OCRA; designing and implementing an OCRA protocol
for dynalogin; extending the PAM module to support OCRA (this is a
different PAM module than above ;)).

I will be ony holiday from July 22nd until August 2nd - I will
probably not work much during this period (depending on spare time and
net access).

As always, my code is on github[1].

Kind regards,
Fabian

1: https://github.com/Fabian-Gruenbichler/oath-toolkit/commits/ocra
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBAgAGBQJR4DLVAAoJEK4xK/RwikTnjPwQALXxOXTWGrxW+mrK3ZpN4XtX
JYWGzi1YTiuRD0Rm/Si+BfEw9LVbVzHWE/aHBMit23GYBmu8SXBoolIHZh6gP0Ay
YQuhgZyk12hYoM1p36yxk5cAx5m02+e4FyldVPqRJdfvxOe7P2dz1QAMQ7/DpxOF
iy9yCE5gAK6GjlhUk1mWZOzLE5bUsKHEPX9ZmrlnfaIir6zcjOzyo+fZii8eqdtr
WpMupd4GCIlnBTypkrr5gqgT/FvKT7cmgZxqDVNvWG+thj/iSo9POfYTUDxuQqkd
DnMae69sf5NKRN0BRZIgMyVmY+KMnZfR2Ib50Qq3Avl8uCUsXlZErVab5cn8rhXK
RSum/8I7Km/EexM3qrzdJn0KgjKnP1RBU5VDnp9QK8dNhiKqSUlNAEZ/Hs3roUyO
0B0tPOSmjZ4sPNLVG5o3Xlpo3sxqHvKALqsc+HoTp/AjJghyYXYhA1tIF4pSjp2u
NIx4fgzJYbeOX3cfUlmsUR6BcMT5YDJqLDLCeWaDHMnd5/JJ6zEVNGfQhCaC5Mrf
GdXfRoxCwgok7TlhkXjRjPvMMWxesH1kdwqVwbJoUD+80Ezr620S8PDFniay5Qta
pmSJ/Oh/jrGaoB7GNxtR3s0Me0NtvVHFKIE4yUC89V4C6Nw5IY/h7OxZcalnT0An
6K7mXphmrbSoBWTsVqN1
=q3a2
-----END PGP SIGNATURE-----