Repairing the Graph Partition
The graph connection between Node A and Node E is severed. The following process repairs the partition:
| • |
In the bottom partition of the graph—consisting of Node D, Node E, and Node F—the Signature record expires after a maximum time of 5 minutes because the refreshed Signature record sent by Node B is not propagated to nodes in the bottom partition. |
| • |
When the current Signature records expires, all the nodes in bottom partition of the graph calculate a random backoff delay that is proportional to their node IDs before flooding a new Signature record with their own node ID. Because Node D has lowest node ID, it floods a new Signature record with graph signature of 7 first. Node E and Node F receive the new Signature record and update their own Signature records. |
| • |
Node D updates its own Contact record with a graph signature of 7 and floods that new record to Node E and Node F. As the information is propagated to the graph nodes, each notes that the Contact record for Node A with a graph signature of 1 does not match the Contact record for Node D with graph signature of 7. To resolve the inconsistency, each node calculates a random backoff delay. After the delay, the node will attempt to connect with Node A to repair the partition. For this example, the delay for Node D is less than the delay for Node E or Node F. Node D connects with Node A. |
| • |
Node A and Node D exchange records. Node D notes that Node A sent it a new Signature record with graph signature of 1, which is lower than the current graph signature. Node D floods the new Signature record with graph signature of 1 to Node E and Node F. |
| • |
Node D updates its own Contact record for Node D with graph signature of 1 and floods the updated Contact record for Node D with graph signature of 1 to Node E and Node F. Then, Node D floods the new Contact record for Node A with graph signature of 1. |
The graph has converged. All the nodes in the graph have the same set of graph records: a Signature record with graph signature of 1, a Contact record for Node A with graph signature of 1, and a Contact record for Node D with graph signature of 1.
If Node D, Node E, or Node F were not able to establish a graph connection with Node A or any other node in the upper partition (consisting of Node A, Node B, and Node C) due to network reachability problems, then two graphs would exist. There is another process to perform long-term partition repair.
The detection of a graph partition is based on the expiration of the Signature record. The repair of the graph partition is based on the attempts to correct inconsistencies between the graph signature in the current Signature record and the graph signature in contact records. New connections are attempted to those contacts that have incorrect graph signatures in their Signature records. These new connections and the ensuing graph record synchronization repair the graph. Over time, using normal graph maintenance, the optional topology for flooding is obtained automatically.
Graph Security
Graphs are merely the association of a group of nodes with connections that define a topology for flooding. They are by themselves unsecured. Windows Peer-to-Peer Networking provides an architecture that allows pluggable modules for the security of the graph. A specific security module can define:
| • |
Who can connect and send data to the graph (connection authentication, confidentiality, and integrity) |
| • |
How the traffic sent over the graph is encrypted (message/record confidentiality) |
| • |
How the traffic sent over the graph is validated (message/record integrity) |
Windows Peer-to-Peer Networking provides a single graph security provider named the Microsoft Peer Grouping.
The Windows XP Peer-to-Peer SDK provides APIs to develop your own graph security provider. For more information, see the topic titled "Adding Security for a Peer Graph" on the Microsoft Developer Network.
Grouping
Grouping is the combination of PNRP, peer graphing, and the Microsoft Peer Grouping security provider. The Microsoft Peer Grouping security provider provides the following:
| • |
The management of the credentials of the members of a group |
| • |
The secure publication of records in a group |
A unique group ID identifies every group. This group ID is used by group members to differentiate between different groups for which the local machine is a member, and also for identification of groups between different peers. Groups use secured peer names, as defined for PNRP, as group IDs.
For secure groups, participation is restricted to a set of users known as group members. Every group member has an identity, a unique peer name, and credentials that prove the ownership of the group member's identity. Every group member also has credentials to prove they are a member of a group.
Information in the form of records is securely flooded throughout a group. A record contains the following:
| • |
The publishing member identity |
| • |
Data to prove record validity |
| • |
A validity time |
| • |
A payload that contains the record information |
The security provided by Windows Peer Grouping is a combination of the following:
| • |
Peer names |
| • |
Group membership certificates (the credentials associated with peer names) |
| • |
Roles (member and administrator) |
| • |
Secure publishing |
| • |
Security policies |
| • |
Secure connections |
Peer Names
As described in the "Peer Discovery and Name Resolution with PNRP" section of this article, secured peer names are only registered by their owner and are protected with public key cryptography. Unsecured peer names can be as small as 3 characters long. Secured peer names must be at least 40 characters long. No peer name can be greater than 191 characters long, plus a NULL character.
A secured peer name is considered owned by the peer entity having the corresponding private key. Ownership can be proved via the CPA, which is signed using the private key. A malicious user cannot forge ownership of a peer name without the corresponding private key.
Group security uses a peer name to identify each member of the group. Peer names are statistically unique. Group security also uses a peer name to identify a group. When a group is created, a new public/private key pair for the group is created, upon which the group peer name is based. The member that owns the private key corresponding to the peer name of the group is the group owner.
Group Membership Certificates (GMCs)
To participate in a group, every member must have credentials that are used to prove group membership when performing group functions such as connecting to a group or publishing records in a group. These credentials are X.509 certificates known as group membership certificates, or GMCs. The characteristics of the GMC are the following:
|
1. |
The Subject field of the GMC is a peer name identifying the member. To prove ownership of a GMC, the member presenting it must prove ownership of the peer name contained in the certificate. Ownership of the peer name is based on the knowledge of the private key corresponding to the peer name. Credential ownership can easily be verified using a simple challenge. |
|
2. |
For a trusted X.509 certificate, the certificate chain leads to a self-signed root certificate whose authority is trusted. For a GMC to be validated, it should be a leaf certificate descended from a trusted authority. A group is identified by the group’s peer name. A group peer name can thus be trusted, and hence, can act as a trusted authority that can issue X.509 certificates. When the group peer name is used as the root authority, it is easy to verify that the key used to sign the root certificate is the group’s private key. Hence, any certificate chain that leads to the self-signed root certificate of the group is trusted. Such a root certificate should contain: Subject: group peer name, Issuer: group peer name, and be signed using the group private key. Such a self-signed root certificate is known as a group root certificate, or GRC. |
|
3. |
In X.509 certificates, authority to issue certificates can be delegated to trusted sub-authorities. The load of issuing member GMCs can be distributed to additional group members known as administrators. Administrators can further delegate this responsibility, if authorized by the group’s security policy. |
|
4. |
Like any other X.509 certificate, GMCs have a validity period. A GMC is considered invalid any time outside that validity period. A group member maintains membership in the group by renewing its GMC before it expires. |
Note: Windows Peer-to-Peer Networking GMCs use certificate properties differently than X.509. The Subject Name property in a GMC is a meaningless friendly name and the Subject Alternative Name property is used to store the actual peer name of the certificate subject.
Secure Publishing
A group database contains information published by group members. Apart from the member-published information it also contains security information. Both regular and security-related information has to be secured. Group security provides data integrity and authorization for secure publishing:
|
1. |
Data integrity The records published in the group carry security data. This security data contains the cryptographic signature of the record contents (including the payload and parts of the header). This enables detection of record tampering. Only explicitly authorized group members can update records published by other group members without making those records invalid. |
|
2. |
Authorization Not all members are authorized to publish all kinds of records, and not all members are allowed to update records published by other group members. Therefore, it is required to check for authorization that the publisher had the right to publish records, and that the signer had the right to sign the record. This authorization is done against the privileges that the publisher and signer have. The signer information included in the security data is the peer name of the signer and the signer’s GMC serial number. Because roles present in the GMC give authority to publish records, a serial number is included along with other security data to ensure that verification of authorization is done against the right set of roles. A single group member can have multiple valid GMCs. The most common cause is when a GMC with different roles is issued to a member before their current GMC expires. |
Publishing GMCs
A GMC contains most of the information required for any verification that needs to be done for that group member (for example, public key for signatures, roles for authorization etc.) Verification of information published by a group member requires that group member’s GMC. The publication of the GMC is done automatically on the user's behalf at an appropriate time. This allows others to verify information that the member publishes using this GMC. If the user’s current GMC is already published, it doesn’t need to be published again when publishing additional records.