Design for TLS implementation in Kea
This design aims to fulfill the requirements related to TLS.
1. Native TLS Implementation
The implementation takes use of Boost.SSL library, providing nice ASIO layer abstraction above OpenSSL. The following tasks will be needed to complete this goal:
- #1619 (closed) - experimental PoC implementation.
- #1644 (closed) - preliminary cleanup of existing ASIO code to be able to support upcoming TLS socket
- #1661 (closed) - TLS socket implementation, including asiolink and libhttp updates
- #1662 (closed) - CA code extension (including parsers update, ability to open TLS sockets, load certs, etc.)
- #1663 (closed) - extension of kea-shell to be able to establish both http and TLS sockets.
- #1665 (closed) - attempt to extend the code to work with Botan.
- #1664 (closed) - documentation (both ARM and developer's guide). The dev guide is particularly important, so other devs that are not experts in security could understand how to use the code and possibly extend it in the future.
Once those tickets are completed, Kea will be able to accept TLS connection using CA, while still offering legacy http connection for those who don't want to deploy TLS. The libhttp changes are particularly well suited adaptation in other areas, such as implementing http(s) capability in DHCP daemons (see experiments in #1315 (closed) and their follow ups).
2. RBAC Hook Design
Once the native TLS implementation is complete, we will be able to implement an RBAC hook that will have access to basic HTTP headers and TLS certs data. The hooks will take advantage of those different channels. Details are TBD.
initial wrapper discussion - this was the initial discussion page back when we still considered writing a wrapper around Kea. It's obsolete, because #1619 (closed) proved that native TLS implementation using Boost.SSL library is viable.