Re: Phase 1 Re-keying Implementation Identification

[Mike Carney <[e-mail]>]

> >>>>> "Mike" == Mike Carney <[e-mail]> writes:
> 
>  Mike> Scott, While the IKE SA is indeed a seperate entity from the
>  Mike> IPSec or protocol SA, the IKE SA is used to
>  Mike> authenticate/authorize the IPSec/Protocol SA.  If it is
>  Mike> important to "your" implementation to have precise boundries
>  Mike> when authentication/authorization is removed (given a peer who
>  Mike> may not cooperate), then dangling Phase 2's should be
>  Mike> restricted.
> 
> I may be overlooking something simple, but is there a real issue here?
> 
> If one side has reason to believe that communication is no longer
> authorized, it can (and should) unilaterally remove the phase 2 SAs
> that relate to that communication.  You learn about the authorization
> properties during phase 1 negotiation, but it doesn't follow you need
> to keep the IKE SA open.  You gain no additional knowledge from the
> fact that it remains open.

Well of course this is very implementation dependent, but in our 
situation, we store the identify information used for authorization
of phase 1's with the rest of the information regarding the phase 1.
We also keep track of the phase 2's negotiated under the phase 1 within
the structures pertaining to the phase 1.

If we discard all of this information when we discard a phase 1 (again
implementation dependent)  then we have no way of associating phase 2
SA's with a potential authorization change that may effect the phase 1.

> It is clearly desirable for that fact to be communicated to the other
> end.  With an active phase 1 SA that's easy.  If there isn't one but
> you can establish it, that's likewise not a problem.  

If the identity used to establish the phase 1 is no longer valid, you
cannot establish the phase 1 in order to inform the remote peer to
discard the phase 2's.

> If you can't
> establish it, what exactly is the problem?
> 

No problem, just discard the phase 2's associated with the phase 1
you had discarded early then later tried to renegotiate (If you can
figure out which phase 2's fall into that category)

> As Tero pointed out, all you get is a black hole.  The side that
> recognized the absence of authority is perfectly well entitled to
> remove the phase 2 SAs unilaterally; it doesn't need permission from
> the other end to do so.  If the other end isn't cooperating well
> enough to be told, that's its problem.

I think we are in violent agreement but permit me to continue.

I don't see the need to require the lack of dangling phase 2's.
However, I feel there may be some benefit to implementations that
prevent dangling phase 2's.

>  Mike> This is a similar issue to allowing phase 2 lifetimes to extend
>  Mike> beyond the validity period of the certificate that
>  Mike> authenticated the phase 1 used to negotiate the phase 2.
> 
> I don't see the similarity.  In what way does limiting the phase 2
> lifetime according to cert expiration times relate to the question of
> "dangling" SAs?  You don't need to keep the IKE SA open to know about
> cert expiration times, nor do you even need to remember the cert
> expiration time in the first place once you've used it to bound the
> phase 2 SA lifetime.
> 

It is similar only in the tradeoff being made for promptness of
revocation of permission.  I was not trying to say that you needed
to keep a phase 1 SA in order to properly set the lifetime of the 
phase 2 SA.

> If you believe that phase 2 lifetimes shouldn't be extended like that
> (which sounds reasonable to me), don't do it.  Again, you need no
> one's permission to do so; if you think it's time for an SA to be
> considered expired, that's all that's needed.  (In particular, the
> notion of "negotiating" SA lifetime doesn't make much sense.)
> 
> 
> 	paul

Regards,
Michael Carney