irmd: Complete bidirectional flow re-keying

Extend re-key delivery beyond the locally-initiated watermark path:

Handle peer-initiated re-key requests, allowing one request and one
response per flow at a time. The client side wins if both ends try to
re-key at the same time. Caches the peer certificate to support
cert-less authenticated/signed re-keys.

After a rekey, the initiator promotes first (timer) and starts sending
under the new key. The responder observes the new key (peer_synced)
and then the responder promotes. The responder will self-decide to use
the new keys if it exhausted the older set in the case where it never
sees the peer (unidirectional flow).

Signed-off-by: Dimitri Staessens <dimitri@ouroboros.rocks>
Signed-off-by: Sander Vrijders <sander@ouroboros.rocks>

1 files changed, 6 insertions, 1 deletions

diff --git a/src/irmd/reg/flow.c b/src/irmd/reg/flow.c
index ccb2562d..8be2dfc7 100644
--- a/src/irmd/reg/flow.c
+++ b/src/irmd/reg/flow.c
@@ -70,10 +70,12 @@ static void destroy_rbuffs(struct reg_flow * flow)
 {
         if (flow->n_rb != NULL)
                 ssm_rbuff_destroy(flow->n_rb);
+
         flow->n_rb = NULL;
 
         if (flow->n_1_rb != NULL)
                 ssm_rbuff_destroy(flow->n_1_rb);
+
         flow->n_1_rb = NULL;
 }
 
@@ -81,7 +83,10 @@ void reg_flow_destroy(struct reg_flow * flow)
 {
         assert(flow != NULL);
 
-        crypt_secure_clear(flow->rk.pending_seed, SYMMKEYSZ);
+        if (flow->rk.pending_seed != NULL)
+                crypt_secure_free(flow->rk.pending_seed, SYMMKEYSZ);
+
+        freebuf(flow->rk.peer_crt);
 
         switch(flow->info.state) {
         case FLOW_ACCEPT_PENDING: