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

Re: ISAKMP/Oakley resolution draft question



  Shawn,

  Good point. I guess I never ran into that because my implementation
sends the last Aggressive Mode message encrypted (i.e. under the protection
of the ISAKMP SA) which, I guess, is technically in violation of the spec.

  I'll clean this up. The reason the messages are shown as being in the clear 
is because the parties can delay generation of the shared secret until the
exchange is finished if they choose to do so. I surely didn't mean to
imply that they must do so.

  What Greg suggests is correct. The phase 2 IV is computed-- in part--
from the phase 1 IV. If the phase 1 IV has never been used (if in Aggressive
Mode the last message is sent unencrypted) then that's just what's used.
If the phase 1 IV has been used then it will end up just being the last CBC 
block processed. In either case it's still the "phase 1 IV".

  It seems to me that the responder should be able to handle either. If it
chooses to postpone exponentiation but the initiator didn't and sent the
message encrypted then it must exponentiate to process the final message. If 
it chooses to exponentiate but the initiator did not and sent the last 
message in the clear the responder shouldn't treat this as an error-- as it
should if a Quick Mode message was sent unencrypted.

  If there are no objections to such a clarification I'll make it. An
alternative would be to just mandate that the last message be encrypted but
that would negate the "feature" of being able to delay exponentiation if
you so choose.

  sorry for the delay in answering you,

    Dan.

> >In the latest (-04) version of the ISAKMP/Oakley resolution draft,
> >the last message of Aggressive Mode (regardless of the authentication
> >method) is always unencrypted.  This seems to counter the base
> >ISAKMP (-08) draft, where the last message of Aggressive Mode is
> >encrypted.  But there is some text in section 5 of the resolution
> >draft (at the top of page 7) which seems to justify the lack of
> >encryption.
> >
> >Is this correct?  If so, then how does one calculate the IV required
> >for the first Quick Mode message after using Aggressive Mode, given
> >that there will be no CBC output block from phase 1 (see appendix B)?
> 
> I can't comment on whether it is correct or not, but here is what I do:
> 
> I initialize the buffer which is supposed to be the last CBC block with
> N bytes, where N is the Block size, of the phase one calculated IV
> (using the method described in appendix B, 5th or 6th paragraph).  Then
> my Quick Mode IV generation treats it as though it were the last CBC
> block.  Since both sides know the value everything works out.  



References: