[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CBC IV generation in ISAKMP/Oakley

  Shawn,

  In the -02 draft the IV was not constant. That might not have been
explained very clearly but that was the intent (and in fact, the most
recent bake-off was against -02 and everyone had a running IV).

> I guess that changing the IV for every message is a good thing from
> a cryptographic point of view (at least to this non-cryptographer),
> but I'm concerned that it might not be such a good thing from a
> protocol point of view.  Specifically, I have two concerns:

A changing IV is mandatory. There is no point in having an IV if it
is the same for all messages.

> 1. Handling retransmissions: ISAKMP entities MUST retransmit when
> a response is not received after some period of time (isakmp-07
> draft, section 5.1).  This, coupled with the fact that IVs change
> now, makes the following scenario possible:
>
> i. Once Phase 1 is complete, one of the ISAKMP peers sends out an
> initial Phase 2/Quick Mode message.
> 
> ii. No response is received, so the initiator retransmits.
> 
> iii. The intended responder finally receives the first message.
> The IV for the initial message is calculated, the message is
> decrypted and processed, the reply is sent out, and the responder
> is now prepared to decrypt the next message using the last CBC
> block of that message as the IV.
> 
> iv. The responder receives the retransmission of the first message.
> It cannot be decrypted cleanly, because the IV is now wrong.

I've seen this happen in testing.

> Since there is no sequence number or other "hint" in the ISAKMP
> header which allows one to detect retransmissions, about the only
> thing a Phase 2 responder can do is "guesstimate" the likely
> size of the initiator's second Phase 2 message, and throw out anything
> larger than that as being a likely retransmission of the first message.
> Or recalculate the initial IV and try to decrypt the message over
> again.  Both of these approaches are, at best, workarounds for
> something for which the protocol itself really ought to handle
> better (or at least document the proper workaround...).

No, the 2nd one is dropped because the decryption failed. The protocol
handles this just fine. 

> 2. Informational exchange messages (Notify and Delete): isakmp-07
> states that Informational exchange messages MUST be protected by
> the ISAKMP SA once it is established (section 4.8).  However,
> isakmp-oakley-03 does not state what one should use for an IV
> when sending an Informational exchange message.

This needs some wordsmithing and coordination with the ISAKMP authors.
The solution is to require Informational exchanges to have a message-ID
in the header. The IV for these exchanges would then be derived in an
identical manner as that for Quick Mode exchanges.

Your concerns about IVs getting out of sync if messages are dropped can
be alleviated by retaining the encrypted payload for retransmission
purposes. If your counter times out, resend the encrypted payload, don't
retain the cleartext payload and re-encrypt it. Like I said, I've seen
this happen and there is a brief hiccup and then they get back into
sync. 

> I'm certain all of these can be handled one way or another.  Maybe
> it would make sense to include the IV as part of the message, the
> way ESP transforms do.  Or perhaps it just requires some clarifying
> text in the draft(s).  Or maybe I'm missing something really obvious...

Clarification in the drafts is the way to go. I think it was Idi Amin who 
said, "Sometimes people mistake the things I say for the way I think."
For me it's: the way I write for what I think. 

  Dan.
References: