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

Re: IPSec SA DELETE in "dangling" implementation

Hi Paul,

Paul Hoffman wrote:

<trimmed here and there...>

> Well, I'm not a fan of beating a dead horse, but I don't think this
> discussion has come to resolution on a not-necessarily-rare prospect.

After giving this some more thought, I think you're right. My apologies
to Slava.

> If an
> implementation lets an IKE SA die without tearing down all IPsec SAs that
> were started under its protection, there's going to be the problems that
> have been long discussed.

I don't agree with this. If I rekey the IKE SA (i.e. let the old one die
and negotiate a new one to the same intermediary, and with the same
authentication characteristics as the old one), I think these are
equivalent. If I defer this negotiation for some period after the old
one dies, and then instantiate the equivalent IKE SA at some future
time  (e.g. when something forces activity, such as a phase 2
rekey/delete), what is the difference?

> An implementation can (and IMO SHOULD) choose not create IPsec SAs that
> have lifetimes longer than the IKE SA under which they are protected. So
> far, so good.

I also disagree with this (with that statement that it SHOULD), but I
can see why one might believe this. I think the basic premise is that
once the phase 1 SA is gone, if the authentication credential is
revoked, there is no way to tie this to the phase 2 SA, or at least I
think that's an argument that's been posed. However, this is only true
if you do not bind the authentication credential to the phase 2 SA to
begin with, via your policy. If the credential is bound to the phase 2
SA, then the recognition of revocation permits (at least) the unilateral
deletion of the phase 2 SA. That is, if the other end's cert is revoked
and you know a phase 2 SA relies upon it, you can delete the phase 2 SA,
even if you cannot notify the other side. And in this case, why should
you care (much) if you are unable to notify the other side?

Granted, this requires a level of sophistication which surpasses that of
many fielded implementations. The problem is (I think), that many
implementations use only one credential for the sgw, and with this
authenticate all resulting phase 2 SAs. Even in this case, though,
recognition of revocation should be sufficient to permit unilateral
deletion of all relevant phase 2 SAs.

> However, there are some cases where an IKE SA can get taken down
> unexpectedly. A good example is when the IKE SA discovers that the cert it
> used to authenticate the other party has been compromised. In this case,
> all the IPsec SAs are suspect and should be deleted.

Yes, this is the case just referred to above, and I agree.

> I may have missed it, but is there a good reason why an IKE implementation
> that is deleting an IKE SA for security reasons ever want *not* to tear
> down the IPsec SAs that it created?

Probably not. 

Scott