At Fri, 02 Oct 2009 13:02:23 -0700,
Michael Chen wrote:
>
> [1 <text/plain; ISO-8859-1 (7bit)>]
> 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".
This is not correct.
To recap:
When a node receives a store to location Rx, that store is signed
with the private key corresponding to the public key in some
certificate C. The node then checks that whatever identity is in
C is allowed to store at location Rx. The precise checks depend on
the kind.
For the particular case of AORs (more properly SIP-REGISTRATION)
the Access Control Model is USER-NODE-MATCH. (S 7 of draft-ietf-p2psip-sip).
This means:
The USER-NODE-MATCH policy may only be used with dictionary types.
In the USER-NODE-MATCH policy, a given value MUST be written (or
overwritten) if and only if the request is signed with a key
associated with a certificate whose user name hashes (using the hash
function for the overlay) to the Resource-ID for the resource. In
addition, the dictionary key MUST be equal to the Node-ID in the
certificate.
[draft-ietf-p2psip-base; S 6.3.3]
Thus, X does not need to supply the AOR, because the check is to take the
user name in the certificate and see of it hashes to Rx. This check
precludes Y storing at Rx.
-Ekr
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
