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

Re: ISAKMP commit and notify usage



  Hi Tom,

> I am trying to understand the usage of the ISAKMP commit bit flag and
> notify messages.
> 
> The ISAKMP header contains a flags field which contains a commit bit. When
> set by the sender this tells the peer ISAKMP not to use the (ISAKMP or
> IPSEC ?) SA until the sender transmits an informational exchange.
> Subsection 4.8 of the ISAKMP spec - Informational Exchange - states that
> once an ISAKMP SA has been established, the Informational Exchange MUST be
> transmitted under the protection provided by the ISAKMP SA.
> 
>  - Does this prevent use of the encryption key/SA by ISAKMP or only IPSEC?

  It prevents use of the IPsec SAs. It wouldn't make sense to use this for
phase 1 and, in fact, I would interpret receipt of this bit in phase 1 to
be intended for the forthcoming phase 2 exchange.

  The point of this bit is that a Quick Mode exchange (from the ISAKMP+Oakley
doc) is a 3 message exchange and upon receipt of the responder's only 
message, the initiator has all the information necessary to stuff the IPsec
SAs into its SA table. If this is done before the final message is composed
(a hash from initiator to responder) there is a possibility of that SA
being used by the kernel (or IPsec process or whatever depending on your OS 
flavor). If the timing is right (or wrong I guess) valid IPsec packets could 
arrive at the responder before hash which completed the exchange and allowed 
the responder to stuff the SAs in its own SA table. These packets would be
dropped.

  If the COMMIT bit was set by either party, the Quick Mode exchange would
become a 4 message exchange and the initiator would not stuff its SAs 
until receipt of the notify message. The responder would stuff its SAs first.
Yes, this would make it ready for use before the intiator was ready but
since the initiator started this its got some packets queued up and waiting
to be sent. It's unlikely that the responder also has packets queued up and
waiting, it could, but it's just unlikely. The timing would have to be real 
horrible (and the SA would have to be sharable-- no PFS) for the responder to 
use the SA before the initiator was ready.

  Anyway, I personally don't see this as a big problem and haven't had any 
trouble using ISAKMP and IPsec without the COMMIT bit.

> - What notify message type payload is used to commit/tell the peer ISAKMP
> that it is time to start using the encryption key/SA?

  Good question. I think it's the CONNECTED notify message from 3.14.1.

>  - Is there an integrity check on the Notification Payload? Does each piece
> of notification data define its own integrity mechanism? The OAKLEY error
> payload appends a Sig/prf Payload.

  That is to be added to the next rev of the ISAKMP/Oakley document. Once
the ISAKMP SA has been established SKEYID_a should be used to protect 
informational exchanges in the same fashion it is used to protect Quick Mode 
exchanges-- i.e. HDR*, HASH, NOTIFY. Where HASH = prf(SKEYID_a, M-ID, NOTIFY).

  regards,

    Dan.



References: