Hi Yoav/Kivinen
Thanks a lot for your quick response. As Yoav said - this is for the
some legacy solution support - there in some strange situation we are ending up
with different lifetime in the boxes, and creating some issues.
So now as to add to the same question -
If we are sending the extra IKE responder life time notification in MM6 or AM2
- since the peer AUTHENTICATION data is also available in these messages - can
we overcome this situation. We can avoid attack by changing the life time only
if the authentication is successful.
I understand may be other implementation will avoid this extra notify - but is
there any violation in sending this extra notify in these messages?
Thanks
Anoop
-----Original Message-----
From: Yoav Nir [mailto:[email protected]]
Sent: Monday, March 04, 2013 9:30 PM
To: Tero Kivinen
Cc: Anoop V A (anova); [email protected]
Subject: Re: [IPsec] Regarding ISAKMP SA lifetime negotiation.
On Mar 4, 2013, at 4:31 PM, Tero Kivinen <[email protected]> wrote:
> 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).
This is true for MM2, but not for MM6. MM6 is encrypted and authenticated, so
the peer can and should (if they implemented the draft) use 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...
It makes sense for working with implementations where you can't configure such
parameters, like VPN clients. Sadly, none of the generic IKEv1-using clients
(like the L2TP clients) seem to support this draft.
>> 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.
MM6 and AM2 are protected.
>
>> 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).
Now that I agree with. This draft addresses one deficiency in IKEv1. The reason
to support IKEv1 today is to support legacy implementations. I don't think
anyone is adding this feature now to legacy implementations. So yes, <hat
type="vendor"> Check Point code supports it, but </hat> it's better to use
IKEv2 where interoperability with different configured lifetimes has been shown
to work.
Yoav
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
