All, A candidate road map for the next few major releases of fwknop has been committed to the hmac_support branch (org mode format):
http://www.cipherdyne.org/cgi-bin/gitweb.cgi?p=fwknop.git;a=blob;f=roadmap.org;h=8a02d93e867edbfad0f29c169efded7fd78d13f2;hb=381487569c4ba0ad5c90e58c9a532977a15acced These were converted into milestones on github: https://github.com/mrash/fwknop/issues/milestones This road map is a draft of major functionality that is to be implemented - all feedback is welcome. If there is anything you would like to see added, changed, or removed, please let me know. The code in the hmac_support branch will become the next major release (fwknop-2.5), and it will change things quite a bit. It will still be possible to use fwknop-2.5 with older releases through support for the current way of doing things, but the recommended work flow will become: - Use fwknop in '--key-gen' mode to generate a Rijndael key as well as an HMAC key. These keys are base64 encoded random data collected from the local entropy source, and here is an example: $ fwknop --key-gen KEY_BASE64: 11MTyBqJDI1zXHGuJd7pYstkeqzbFwKqzCPdNYupCRI= HMAC_KEY_BASE64: W9YKG3XhZ6wJX2yJ3U0zK8SZZbyZEfIrX+umkaIZJOuG6/X025E7GPlfFdxu/BYHenJtnOchIjsDZkrq8saL9w== - Place these keys within the ~/.fwknoprc file in the client filesystem. An example from the test suite can be found here: http://www.cipherdyne.org/cgi-bin/gitweb.cgi?p=fwknop.git;a=blob;f=test/conf/fwknoprc_default_hmac_base64_key;h=173dbed29c7113a1a5c99a4abd8bdf09c9e9d6dd;hb=refs/heads/hmac_support#l49 - Place the keys within the /etc/fwknop/access.conf file on the server. Example: http://www.cipherdyne.org/cgi-bin/gitweb.cgi?p=fwknop.git;a=blob;f=test/conf/hmac_access.conf;h=68c148a40fa8fb6b22cb36b9bcd9843aa3818959;hb=refs/heads/hmac_support - Now, from the client, use the '--named-config' argument to reference the keys and SPA server destination from the ~/.fwknoprc file. This will generate an SPA packet that the server will authenticate via HMAC-SHA256 before running any decryption code. There are several strong security benefits that this will provide to SPA communications beyond what is currently possible. Instead of using --key-gen, you will be able to just manually type in encryption and HMAC keys as well if you prefer that. And, if you prefer to keep things as they are right now and not use HMAC at all, that will continue to be supported. Beyond the addition of HMAC-SHA256 authentication, for SPA packets encrypted with Rijndael, libfko will also ensure that the encrypted data is precisely compatible with how OpenSSL creates Rijndael data in CBC mode. This is to ensure that fwknop can benefit from research that the security community does against the OpenSSL library without having to link against it directly. Even though this compatibility will be checked, fwknop will _not_ use OpenSSL's authenticate-then-encrypt model, which has been a source of serious problems represented by padding oracle attacks. fwknop will strictly use the encrypt-then-authenticate model for HMAC operations similar to IPSEC. Current development efforts are focused on ensuring a good design for the HMAC code along with both static and dynamic analysis (clang-analyzer, splint, and valgrind being primary tools). The test suite is receiving a lot of work too. Thanks, --Mike ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb _______________________________________________ Fwknop-discuss mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fwknop-discuss
