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

CBC IV generation in ISAKMP/Oakley

In the latest (-03) version of the ISAKMP/Oakley resolution draft,
there's a change in how the IV for ISAKMP message encryption is
performed.  Previously, in the -02 draft, a hash of the D-H public
values was used as the IV for all messages.  Now, that hash is
only used for the first encrypted message in Phase 1; all other
Phase 1 messages use the last CBC encryption block from the previous
message.  The first message of a Phase 2/Quick Mode exchange uses
a hash of the last Phase 1 CBC output block output block with the
Phase 2 message ID as its IV, with later messages in that particular
exchange using the last CBC encryption block from the previous message
in the exchange.  (One can read Appendix B of the -03 draft for the
rest of the details.)

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:

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.

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...).

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.

One could assume that a Notify payload sent in reply to some Phase 2
message should use the CBC output block from the previous message as
the IV.  (One should not have to assume this; it should be stated
clearly somewhere.)  If, however, there are several Phase 2 exchanges
going on at the same time, how does one tell which IV to use?  Is
it legal to use the Message ID in an Informational exchange?

What if a message is not decrypted cleanly (due perhaps to an IV
problem with a retransmission as described above?).  Should one
send a Notify payload back?  Encrypted or not?  If encrypted, what
IV does one use?

Better still, what about Delete payloads?  Those may not arrive
until much later.  They should obviously be protected by an ISAKMP
SA, but what should one use for an IV?

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...

-Shawn Mamros
E-mail to: smamros@newoak.com
Follow-Ups: