[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: I-D ACTION:draft-kaufman-ipsec-improveike-00.txt
> >> about the section 7,
> >> "the protocol already assures that.." sounds strange.
> >> because Bob can prove that Alice has the shared secret only after
> >> he has decrypted the 5th message, and has verified the HASH.
> >> of course, in the main mode, Bob would be damaged by Alice until
> >> decrypting 5th message even if the new approach wasn't adopted.
>
> Sorry, I don't understand your comment. Perhaps you're saying that
> Bob has to do expensive computation before knowing that it's Alice?
Yes, I am.
> But as you said, whatever issue you're discussing is also true in
> the old approach.
True. so I just say not "already", but "the protocol assures that"
> >> > allows use of arbitrary identifiers and makes this mode work for the
> >> > road warrior case.
> >> but in the case of the road warrior, the responder cannot decide
> >> the SA parameter to be used from the initiator's proposal. because
> >> the responder cannot compare with the one's policy database.
> If the responder knows the initiator by her name, and not her IP address,
> then the policy database would have an entry for her name. Or, even
> if the initiator is known by a name, there might be other policy in
> addition to policy according to her name, invoked
> according to the IP address from which she's initiating contact.
it must be correct in phase 2. but her name is in identify payload,
isn't it ? so Bob cannot decide the parameter of phase1 SA because
her identity hasn't been passed to Bob when he consults his database.
> >> in section 8,
> >> why is it preferable for you to hide Alice(i'm assuming the responder)'s
i was mistaken, i meant Alice was the initiator.
> >> identity ? i think there are too many case when the attacker is a
> >> initiator. or is my assamption incorrect ?
> We meant it's preferable to hide the INITIATOR's identity rather than
> the responder. The responder is more likely at a fixed address. One could
> imagine a web-site that was politically frowned upon by the initiator's
> government. The government could impersonate that web site and see who
> is attempting to connect. But it seems less likely that the responder's
> IP address would be well-known, and someone would attempt to connect
> for the sole purpose of discovering who is sitting at that address.
agreed.
to make sure, i though you meant msg6 into msg4 WITHOUT any encryption
because msg4 in RFC2409 is not encrypted. i must be wrong.
> I certainly don't feel as strongly about this as about getting
> rid of 3/4 of the variants by removing public key encryption variants
> and aggressive mode, and fixing shared key to allow arbitrary identities.
agreed.
thank you.
References: