3.1.7.2 Record Received

When a record is received by P2P Graphing, it passes the record in PEER_RECORD format (see [MS-PPGRH] section 2.2.1.9) to P2P Grouping implementation to be validated. To validate the security of a record, P2P Grouping MUST validate the following:

  • The record creator MUST be a valid Secure Peer Name as defined in [MS-PNRP] section 1.3.1.1.

  • The record modifier (if present) MUST be a valid Secure Peer Name as defined in [MS-PNRP] section 1.3.1.1.

  • The GMC for the record creator MUST be retrieved from the Membership List. If the record creator's GMC is not present in the Membership List, the record MUST be added to the Unvalidated Record List, P2P Graphing MUST be notified that the record MUST be put on the Deferred Validation List, and processing of this record MUST then terminate.

  • If the record's record modifier field is non-empty, the GMC for the record modifier MUST be retrieved from the Membership List. If the GMC is not found in the Membership List, the record MUST be added to the Unvalidated Record List, P2P Graphing MUST be notified that the record is to be put on the Deferred Validation List, and processing of this record MUST then terminate.

  • The record's "last toucher" is defined as the record modifier if the record modifier field is non-empty, and the record creator otherwise.

  • The record lifetime MUST be within the range of the last toucher's GMC lifetime. Specifically, the record's Last Modified Time MUST be no earlier than the last toucher's GMC's NotBefore time, and the record's Expiration Time MUST be no later than the last toucher's GMC's NotAfter time.

  • If the record modifier field is non-empty, and is different from the record creator, the record modifier's GMC MUST contain the Administrator role.

  • The signature contained in the record's security payload MUST be validated by verifying that the serial numbers and signature are consistent with being constructed as specified in section 2.2.4.

If the record is one of the two P2P Grouping defined record types, it MUST pass further validation. For a Membership record, the following MUST be validated:

  • The record MUST NOT have the deleted flag set. The size of the record payload MUST be large enough to hold the data it claims to contain.

  • The version MUST match the Group Security version defined in the Security Properties record, section 2.2.3.1.

  • The GMC MUST be validated as specified in sections 2.2.5.2.

If the Membership record is valid, the P2P Grouping protocol implementation MUST:

  • The record MUST conform to the syntax specified in 2.2.3.2.

  • Add the GMC from the Membership record to the Membership List.

  • If the Membership record is valid, and records exist in the Unvalidated Record List that are waiting on this GMC, notify P2P Graphing to re-attempt validation of those records.

For a Security Properties record, the following MUST be validated:

  • The record MUST NOT have the deleted flag set.

  • The size of the record payload MUST be large enough to hold the data it claims to contain. The version MUST NOT be larger than the one supported by the local protocol instance.

  • The record MUST conform to the syntax specified in 2.2.3.1.

  • The Group Peer Name MUST be a valid Secure Peer Name as defined in [MS-PNRP] section 1.3.1.1, and MUST match the Group Peer Name previously stored for that Group.

  • The Creator Peer Name MUST be a valid Secure Peer Name as defined in [MS-PNRP] section 1.3.1.1.

  • The Group Classifier MUST match the classifier in the Group Peer Name previously stored for this group.

  • If the record version is 1.1, the following additional fields MUST be validated:

    • The Authentication Schemes flags MUST be 0x00000003.

    • The Number of Passwords field MUST be 0x00000001.

    • For each password:

      • The Password Hash Length field MUST be less than 128 characters.

      • The Password Role field MUST match one of the predefined roles.

  • The record's creator/modifier MUST match the Group Peer Name previously stored for this Group.

  • If the Security Properties record already exists in the graphing database, the record id MUST match the id of the existing Security Properties record. Also, the data contained in the new record MUST match the cached values for those fields that cannot be changed after group creation (see section 2.2.3.1).

If a record is found to be invalid in any way, this MUST be reported to the P2P Graphing implementation. Otherwise, P2P Graphing MUST be notified that the record is valid.