Eric Rescorla wrote:
If a message is forwarded, say X->Y->Z, Y can doing man in the middle
attack. For Z to truly ensure that the message is from X, Z must FETCH X's
certificate from the overlay to verify the signature. For that reason,
sending the certificate has no real security meaning.
No, this is not correct. Certificates are independently verifiable by chaining
back to the overlay's root key. That's pretty much the point of certificates:
you can verify them no matter how you received them.
In the attack by Y described above, Y would sign and put its own
certificate chain in the security block, so the whole message is
verifiably correct. The only way Z can know this is an attack is by
enforcing other constrain of this draft. For example, if the STORE
resource ID is between Y and Z, then this is an attack.
Huh?
How is it in attack for Y to take a message originated by X and
claim it was originated by itself? Y can always generate any message
it wants and sign it. That's how signature-based message authentication
works. Moreover, why would this be an attack on X or Z, since Y
is *legitimately* allowed to generate messages and Z would
(correctly) conclude that the message came from Y, not X. The
fact that Y is copying X's message is irrelevant.
Aha! What if the resource ID in X's request is between X and Y or before
X in the ring? Then Z will never notice the attack. Y can map calls to
x...@domain to Y's destination list. Am I right?
I have no idea what you are talking about.
Let me try again. Say X just joint the overlay, and its logical position
in the ring is X->Y->Z. The overlay has no record of how to contact X. X
hash his AoR "x...@domain" to its resource ID Rx. Just so happen that the
logical position of Rx is Y->Rx->Z. X sends a STORE message via Y to Z
that maps Rx to Dx, where Dx is X's destination list.
When Y receives this STORE message from X, it replaces Dx with Dy, where
Dy is Y's destination list. Then Y sign the message with Y's own cert
before forwarding it to Z. The message seems legitimate to Z, so it
stores the mapping of Rx to Dy. When A wants to call "x...@domain" and
FETCH Rx from Z, A gets Dy. A's call to X goes to Y.
X can find out about Y's attack when X FETCH Rx from Z. Y does not have
an effective attack on the FETCH message, because Y's node-ID is in
front of Rx (Y->Rx->Z) and cannot be the owner of Rx.
Thanks
--Michael
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
