[IPsec] Regarding ISAKMP SA lifetime negotiation.

[Tero Kivinen <[e-mail]>]

Anoop V A (anova) writes:
> 
> Hello experts,
> 
>    I have a generic doubt regarding the ISAKMP SA(phase 1) life time
>    negotiation. My  query is can we agree up on the  ISAKMP life
>    time in the first two messages of MM or AM. 
> 
> What I want to know is  - the life time is sent as an proposal
> attribute in the first two messages of Main mode and aggressive
> mode. We are not negotiating the parameter so if the responder is
> having a less life time value configured - then can we transfer this
> info in the MM2 or AM2 message from the responder along with the
> negotiated proposal attributes. Basically I am trying to change the
> life time attribute sent by the initiator - in this scenario. 

Anything extra (notifications etc) you send inside the main mode or
agressive mode packets are not authenticated, so sending responder
life time notifications is not good idea (and the other end will
simply ignore it).

> We have the responder life time notify mechanism as per the draft
> (draft-ietf-ipsec-ike-lifetime-00), but the separate notify messages
> are not reliable in IKEv1(Uni directional)

That is expired very old draft that did not get forward, there is no
point of implementing that... 

> In short my questions are:
> 
> 1.       Can we send the responder life time notification in MM6 or
>          AM2 message from the responder?

You can, but most likely all implementations will ignore them, and
if any implementation does not ignore them, that opens attack where
attacker can shorten the lifetime at will by just adding such
notification. 

> 2.       Or can we alter the life time attribute of the ISAKMP SA
>          proposal offer?( Is this considers as  a violation of the
>          RFC)

That is considered violation of the RFC, thus all complient
implemnetations will reject the proposal. RFC2408 section 4.2 Security
Association Establishment last paragraph:

								The
   initiator MUST verify that the Security Association payload received
   from the responder matches one of the proposals sent initially.

Easy answer to all of your questions is to NOT use the protocol that
was obsoleted more than 7 years ago (IKEv1 was obsoleted by IKEv2 in
2005), and instead start to use current version of the protocol i.e
IKEv2, which already solves those problem (the notifications are
authenticated, the lifetimes are removed and moved to local matter,
the informational exchanges are reliable etc).
-- 
[e-mail]