Eric,
In my list post, Z can discover Y's attack if the AoR itself "x...@domain"
is included in the STORE such that hash("x...@domain") = Rx. Since the
message is resigned by Y, so Z can conclude that it's illegal for Y to
STORE an AoR of "x...@domain". Y can only STORE an AoR of "y...@domain"
(unless of course a replica).
If I am not mistaken, the current STORE does not send the AoR, only the
resource ID Rx. Then Z cannot verify how Rx was calculated and cannot
discover that Y is storing "x...@domain".
--Michael
Eric Rescorla wrote:
At Fri, 02 Oct 2009 07:20:50 -0700,
Michael Chen 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.
Now, it's true that there is no SECURITY value in sending the certificate
along with the message. Data origin authentication authentication is supplied
by a digital signature computed using the private key that corresponds to
the public key in the certificate. The certificate is attached to the message
to avoid the complexity of a system where you have to hold the message
while you try to retrieve the certificate.
-Ek
A security warning should be included in this draft about the potential
danger of trusting the certificate in the SecurityBlock. It's the proper
thing to do.
I don't understand what you're talking about here either.
The cryptographic elements of an authenticated message in RELOAD
are:
- The contents
- A signature, generated using the sender's private key
- The sender's identity
- A certificate binding the sender's public key to the sender's
identity.
In order to validate this, the verifier needs to:
- Verify the signature on the certificate (using the CA's public
key, which is known a priori)
- Verify that the sender's identity matches the identity in the
certificate
- Verify that the signature on the contents is correct
(using the sender's public key, which is found in the
certificate).
This can be (needs to be) done regardless of the provenance of the
certificate because the certificate is directly verifiable. The
system does not depend on the certificate being provided by
a trusted source.
The only time when you do not need to verify the certificate is
if you have previously verified it and cached the result. You
never trust that the certificate is correct otherwise.
One more thing about SecurityBlock.certificates, in an overlay that
requires an enrollment server, what is the use case in which the peer's
certificate is not issued/signed by the enrollment server? In another
word, what is the use case where SecurityBlock.certificates contains
more than one (the peer's) certificate?
When there are elements which need to be verified with different
certificates. For instance, if node A stores a value with node
B, which then does a replica store to node C, then the B->C
store will have two signatures:
- The signature over the value, using A's key
- The signature over the message, using B's key
The SecurityBlock will then contain both A and B's certificates.
-Ekr
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
