ikev1: Don't cache last block of INFORMATIONAL messages as IV

We don't expect a response with the same MID, but apparently some
devices (e.g. FRITZ!Box) do that for DPDs, while still treating the
response as a new exchange.  By storing the last message block as IV
we can't decrypt the first block of such a response.

Fixes #661.

diff --git a/src/libcharon/encoding/message.c b/src/libcharon/encoding/message.c
index 0f5f40ada1caaafd6a891b094925d3c408fe2b69..f6f13ae2f56fafe33ea641fb88abc622997eceb2 100644 (file)
--- a/src/libcharon/encoding/message.c
+++ b/src/libcharon/encoding/message.c
@@ -1632,7 +1632,7 @@ METHOD(message_t, generate, status_t,
        chunk = generator->get_chunk(generator, &lenpos);
        htoun32(lenpos, chunk.len);
        this->packet->set_data(this->packet, chunk_clone(chunk));
-       if (this->is_encrypted)
+       if (this->is_encrypted && this->exchange_type != INFORMATIONAL_V1)
        {
                /* update the IV for the next IKEv1 message */
                chunk_t last_block;
@@ -2142,7 +2142,7 @@ METHOD(message_t, parse_body, status_t,
                        }
                        chunk_free(&hash);
                }
-               if (this->is_encrypted)
+               if (this->is_encrypted && this->exchange_type != INFORMATIONAL_V1)
                {       /* message verified, confirm IV */
                        if (!keymat_v1->confirm_iv(keymat_v1, this->message_id))
                        {