[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: IPSec SA DELETE in "dangling" implementation
Sure, the other side can ignore the delete, but will they? How many
implementations out there ignore deletes? How many implementations out there
ignore or do not send lifetime notifies?
IPSec relies on a restricted kind of trust. If I communicate with you
encrypted then I trust you not to be malicious (e.g. not to reveal my
confidential data to outsiders); otherwise, my policy with you would be
BLOCK. However, I don't trust you enough to choose the security parameters
for the session. You would presumably refuse to communicate with me if I
chose "ESP Rot13 AH Checksum". That's why the security parameters are
negotiated.
However, the SA lifetime is not negotiated in the same way, even though it
is a legitimate aspect of that policy. If I set my SA lifetime to 5
minutes/100 kb and you set yours to forever (or some other large value) then
you are violating my security policy, even if you are not doing it
maliciously. As I said, I trust you not to be malicious, which is why I
don't think you would ignore the delete if you were able to understand it.
My comment on session hijacking was, as I said, an afterthought. I merely
pointed out that if someone wanted to attempt to hijack your session then
after you've hung up is the perfect time to do it, as you're no longer
around to detect the spoofed packets and the possible error notifies. If you
restrict your SA lifetime to 5 minutes/100 kb, it is presumably because you
believe that there is some finite risk of an intruder cracking the SA if it
lasts longer or carries more data than that. If the peer continues to
obliviously transfer data on that SA longer than that then you run the risk
of an attack.
I'm just saying that you're supposed to trust the peer not to be malicious,
but you're not supposed to trust them to make sensible policy decisions.
Andrew
_______________________________________________
Beauty without truth is insubstantial.
Truth without beauty is unbearable.
> -----Original Message-----
> From: Tero Kivinen [mailto:kivinen@ssh.fi]
> Sent: Thursday, December 02, 1999 11:18 AM
> To: Andrew Krywaniuk
> Cc: Bronislav Kavsan; Paul Hoffman; ipsec@lists.tislabs.com
> Subject: RE: IPSec SA DELETE in "dangling" implementation
>
>
> Andrew Krywaniuk writes:
> > > If there is no traffic going on the SA then there is no
> need to rekey
> > > it. This also means that the IPsec SA can only expire
> because of the
> > > seconds limit. This means that the other end has the same lifetime
> > > information, thus it is going to expire it at the same time. No
> > > problem there.
> >
> > I don't think it's fair to assume the other end has the
> same lifetime
> > information. Sending lifetime notifies isn't required and
> parsing them (and
> > obeying them) is not a MUST.
>
> If I am a initiator and said, that I am going to use this lifetime,
> and the other end does not trust me, it is his problem. If I am a
> responder and I send responder lifetime notification, and he doesn't
> trust that either, that is again his problem.
>
> It is not a MUST to trust delete payloads either. The ISAKMP RFC says
> that you are allowed to ignore the delete payloads, they are only sent
> to inform you that the other end deleted his SA. You don't need to act
> based on that information if you dont like.
>
> If the other ends implementation is broken, I really don't care if he
> keeps few extra SAs up and running for too long.
>
> > If YOU continue to send traffic on an SA that I have
> expired, that would
> > still be a violation of MY security policy. In order to
> force the other side
> > to cooperate, we have to send the deletes (unless parsing
> and obeying
> > lifetime notifies is required).
>
> Even if you send delete payloads, that does NOT mean that the other
> end still cannot send you packets. It is allowed in the RFC to keep
> sending packets using the old SPI. Sending delete means that you are
> saying to the other end that IF they still continue sending packets to
> you using that SPI, you will drop them.
>
> There is NO way to force the other end not to cooperate.
>
> > The point here is that if I want to be sure that my
> security policy is
> > enforced then I must send the delete. If I hang up without
> sending the
> > delete then it's my own fault (I am defeating my own
> security policy).
>
> If the other end ignores all the delete payloads (as it is allowed to
> do), how that is going to enforce your policy?
>
> > And just as an afterthought: if anyone did want to attempt
> to hijack your
> > session undetected, after you've hung up would be the best time.
>
> If somebody is able to hijack my session, he would also be able to
> read everything I sent using that session. I do not plan to use that
> weak security parameters to allow that. We are supposed to make the
> even the reading of the material almost impossible and doing real time
> breaking of the IPsec should be much harder.
>
> Anyways sending deletes does not help here at all, because the
> attacker can simply delete those packets (or respond to them if he
> broke the Diffie-Hellman).
>
> Anyways I don't think that is very valid point. You MUST set your
> lifetime low enough, so it will remove this kind of possiblity.
> Whether or not you send delete payloads changes that thing.
> --
> kivinen@iki.fi Work : +358-9-4354 3218
> SSH Communications Security http://www.ssh.fi/
> SSH IPSEC Toolkit http://www.ssh.fi/ipsec/
>
Follow-Ups: