Paul Wouters <p...@nohats.ca> wrote:
>> Paul Wouters <p...@nohats.ca> wrote:
>> > Or update the RFC with a clarification that delete's are allowed, but
>> > that the server who deleted a state, upon getting a ticket MUST check:
>>
>> > - It's configuration is unchanged from when the ticket was issued (we
do that)
>> > - The ticket's issue time plus the configuration's lifetime is not in
>> > the past
>> > - The IKE SA should not have been rekeyed [tricky without keeping
>> > state]
>>
>> If the ticket was issued at time A (which is in the ticket), and the IKE
SA
>> rekey time is intervals of time B, then had the SA been active alive at
time
>> A+B, it would have been rekeyed, right?
>> So, if the current time is > A+B, then the IKE SA should have been
rekeyed?
> Yes, so that part is not the problem.
>> But, you alude to it requiring state, so there must be something I don't
understand.
> We added a suspend commend, but since that deleted states on the
> initiator, it ended up sending delete's to the server. The server
> deleted the IKE SAs. Now the client can resume a connection that
> technically was ended by Delete.
It seems that either the client shouldn't send deletes, or:
> If the client comes back with a valid ticket within the valid expiry
> time, the server does not know if A) the IKE SA was already deleted
> and the ticket theoretically should no longer be valid or B) the server
> deleted the IKE SA due to liveness timeouts and the client comes back
> with tickets to resume this.
the server should behave the same way regardless of who deleted the SA.
>> >> The case of a cluster of gateways is not handled by the RFC. This is
>> >> alluded to at the end of the Introduction.
>>
>> > that was an unfortunate easy way to not address the problem of syncing
>> > state between servers :)
>>
>> Can you explain what the problem is if the ticket is used more than once
>> (with different gateways) within the time B?
> So this indeed is the important question for all of these cases. What is
> the harm? Because why does the RFC state that deleted IKE SAs should not
> be resumed?
I think that maybe the intention was that IKE SAs deleted by the server due to
operator action should never be resumed. Because the user changed their
password, or their 2FA was compromised, or ...
Maybe the state-lite way is that the identity that involved in the deleted
state is marked as needing re-authentication.
> We are re-using an SK_d, but does that influence the amount of crypto
> done under an IKE SA (FIPS issue)? The livetimes would already be
> covered by the above - just don't let the ticket be valid for longer
> than the creation time plus rekey time.
> It would be really nice if we can keep the server side to need to
> require zero state. If we ignore those two issues mentioned, we can
> do that.
I agree.
--
Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
