[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: RFC2409
As pointed out already by Hilarie and Tero there is no
attack here. When you exchange a key with a "cheater" C then you
can not guarantee that the key is not known to other people
as C can always tell his friends the value of the key...
In this case, both I and R which are good guys end their protocols
convinced that they talked to C (as it was the case). The only "problem"
is that they don't know that there is a third party (R and I, respectively)
that knows the key, but as said this is something C can always do (and
with less effort).
Hilarie mentioned the lack of "explicit confirmation" of the exchanged
key. This is not needed here since the KEi values are fully authenticated.
A party following the protocol will always know the key evn if it does not
explicitly proves that to the other party (the proof is implicit in the
security proof of the protocol).
Hugo
On Fri, 11 Jun 1999, Ivars Suba wrote:
> The essence of attack is following:
> Initiator(chess Grandmaster#1) and Responder(chess Grandmaster#2) trust
> Cheater(chess novice) and vice versa, however they don't trust each other.
> Grandmaster#1 and Grandmaster#2 are convicted that they play chess with
> novice and are surprised by novice's phenomenal chess proficiency, but have
> not understood that they actually play each other. In this type of attack
> novice play pipe role with some cryptographic transformations as decryption
> of IDi (IDr) and Ni (Nr), encryption IDc and Ni(Nr) with other's Grandmaster
> public key and forwarding with KEi (KEr).
>
> Ivars
>
> <
> < How can the cheater convince the Initiator to use his public key
> < instead of the responder? If the Initiator uses Responders public key
> < the C cannot know the value of Ni, thus it cannot calcute the Hash
> < payload, because the Ni is needed there. I don't think this "attack"
> < would work.
> < --
> < kivinen@iki.fi Work : +358-9-4354 3218
> < SSH Communications Security http://www.ssh.fi/
> < SSH IPSEC Toolkit http://www.ssh.fi/ipsec/
> <
>
> I don't understand what the attack is, I'm sorry. It appears
> that both the Initiator and Responder believe that they
> are talking to the cheater, so what is failure? If the
> Initiator and Cheater are collaborators, then can share
> signing keys as easily as decryption keys, so the "fix"
> doesn't make sense to me, either.
>
> It's possible that there is a flaw, given that the two
> sides don't ever prove that they can compute the shared key,
> but I don't exactly see what's wrong. Please explain.
>
>
> Hilarie
>
>
References: