On 4/23/2009 7:19 PM, Tero Kivinen wrote:
Lakshminath Dondeti writes:
MOBIKE assumes that the other side has state, correct?
Yes.
Session resumption has to do with providing that state. How are they
the same?
In this example given (handover from cellular to wlan, without
breaking existing phone call), I do not really see any point why the
IKE SA state needs to be removed from the server side, and as such I
think the much better solution is to use MOBIKE and keep IKE SA up all
the time.
As I do not have any idea where people want to use the resumption, I
have VERY HARD time to justify the different protocol options. But
anyways one of the things required is that it "shall not have negative
impact on IKEv2 security features", and I think 1 RT protocol will
have negative impact to security features.
I fail to understand the "security" issue though in that the attack has
already been identified as mere annoyance and does not result in any
compromise.
Under attack, the protocol stretches to 3 RTs.
3 RT + Diffie-Hellman + public key operation + user interaction to
type in password or securid token etc.
Depends. Some VPN clients do better than others and some require little
to no user interaction.
So, you are saying that there is no noticeable difference between 1
and 2 RTs, but there is between 2 and 3? Is your point that the DH
computation will be noticed?
With group 18: yes... With typing in the passphase to do
reauthentication with RSA token card : yes. With digging out your
securid card and typing in pin, and typing in the next token to the
prompt: yes.
Same as above. But the real point here is that under the attack
scenario, the user has bad experience. As long as the attack is
categorized as low risk, we don't have to worry about this, do we?
My point is that we'd beyond the real-time budgets after 1 RT
anyway.
You should not really do break-before-make style of transitions on
real-time environments, and if you keep the old connection while
making the new one, then this whole issue is non-issue.
Good advice, but that consensus process is from elsewhere. Not every
device has multiple interfaces, not every architecture implements the
idea of multiple simultaneous associations with base stations, and so on.
If our goal is to design for multiple different scenarios and if the
attack is really not serious, I really don't see why we would rule out 1
RT exchange.
regards,
Lakshminath
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
