[MS-PPSEC]:
Peer-to-Peer Grouping Security Protocol
Intellectual Property Rights Notice for Open Specifications Documentation
Technical Documentation. Microsoft publishes Open Specifications documentation (“this documentation”) for protocols, file formats, data portability, computer languages, and standards support. Additionally, overview documents cover inter-protocol relationships and interactions.
Copyrights. This documentation is covered by Microsoft copyrights. Regardless of any other terms that are contained in the terms of use for the Microsoft website that hosts this documentation, you can make copies of it in order to develop implementations of the technologies that are described in this documentation and can distribute portions of it in your implementations that use these technologies or in your documentation as necessary to properly document the implementation. You can also distribute in your implementation, with or without modification, any schemas, IDLs, or code samples that are included in the documentation. This permission also applies to any documents that are referenced in the Open Specifications documentation.
No Trade Secrets. Microsoft does not claim any trade secret rights in this documentation.
Patents. Microsoft has patents that might cover your implementations of the technologies described in the Open Specifications documentation. Neither this notice nor Microsoft's delivery of this documentation grants any licenses under those patents or any other Microsoft patents. However, a given Open Specifications document might be covered by the Microsoft Open Specifications Promise or the Microsoft Community Promise. If you would prefer a written license, or if the technologies described in this documentation are not covered by the Open Specifications Promise or Community Promise, as applicable, patent licenses are available by contacting .
License Programs. To see all of the protocols in scope under a specific license program and the associated patents, visit the Patent Map.
Trademarks. The names of companies and products contained in this documentation might be covered by trademarks or similar intellectual property rights. This notice does not grant any licenses under those rights. For a list of Microsoft trademarks, visit
Fictitious Names. The example companies, organizations, products, domain names, email addresses, logos, people, places, and events that are depicted in this documentation are fictitious. No association with any real company, organization, product, domain name, email address, logo, person, place, or event is intended or should be inferred.
Reservation of Rights. All other rights are reserved, and this notice does not grant any rights other than as specifically described above, whether by implication, estoppel, or otherwise.
Tools. The Open Specifications documentation does not require the use of Microsoft programming tools or programming environments in order for you to develop an implementation. If you have access to Microsoft programming tools and environments, you are free to take advantage of them. Certain Open Specifications documents are intended for use in conjunction with publicly available standards specifications and network programming art and, as such, assume that the reader either is familiar with the aforementioned material or has immediate access to it.
Support. For questions and support, please contact .
Revision Summary
Date / Revision History / Revision Class / Comments1/29/2010 / 0.1 / Major / First Release.
3/12/2010 / 1.0 / Major / Updated and revised the technical content.
4/23/2010 / 1.0.1 / Editorial / Changed language and formatting in the technical content.
6/4/2010 / 1.0.2 / Editorial / Changed language and formatting in the technical content.
7/16/2010 / 1.1 / Minor / Clarified the meaning of the technical content.
8/27/2010 / 1.2 / Minor / Clarified the meaning of the technical content.
10/8/2010 / 1.2 / None / No changes to the meaning, language, or formatting of the technical content.
11/19/2010 / 2.0 / Major / Updated and revised the technical content.
1/7/2011 / 2.0 / None / No changes to the meaning, language, or formatting of the technical content.
2/11/2011 / 3.0 / Major / Updated and revised the technical content.
3/25/2011 / 3.0 / None / No changes to the meaning, language, or formatting of the technical content.
5/6/2011 / 3.0 / None / No changes to the meaning, language, or formatting of the technical content.
6/17/2011 / 3.1 / Minor / Clarified the meaning of the technical content.
9/23/2011 / 4.0 / Major / Updated and revised the technical content.
12/16/2011 / 5.0 / Major / Updated and revised the technical content.
3/30/2012 / 5.0 / None / No changes to the meaning, language, or formatting of the technical content.
7/12/2012 / 5.0 / None / No changes to the meaning, language, or formatting of the technical content.
10/25/2012 / 5.0 / None / No changes to the meaning, language, or formatting of the technical content.
1/31/2013 / 5.0 / None / No changes to the meaning, language, or formatting of the technical content.
8/8/2013 / 6.0 / Major / Updated and revised the technical content.
11/14/2013 / 6.0 / None / No changes to the meaning, language, or formatting of the technical content.
2/13/2014 / 6.0 / None / No changes to the meaning, language, or formatting of the technical content.
5/15/2014 / 6.0 / None / No changes to the meaning, language, or formatting of the technical content.
6/30/2015 / 7.0 / Major / Significantly changed the technical content.
10/16/2015 / 8.0 / Major / Significantly changed the technical content.
7/14/2016 / 9.0 / Major / Significantly changed the technical content.
6/1/2017 / 10.0 / Major / Significantly changed the technical content.
Table of Contents
1Introduction
1.1Glossary
1.2References
1.2.1Normative References
1.2.2Informative References
1.3Overview
1.3.1P2P Graphing Constraints
1.3.2Group Security
1.3.2.1Peer Names
1.3.2.2Certificates
1.3.2.3Roles
1.3.2.4PNRP Publication
1.3.2.5Joining a Group
1.3.3Group Connect Subprotocol
1.3.4Record Subprotocol
1.3.4.1Receiving a Record
1.3.4.2Publishing a Record
1.3.4.3Security Records
1.3.5OOB XML
1.4Relationship to Other Protocols
1.5Prerequisites/Preconditions
1.6Applicability Statement
1.7Versioning and Capability Negotiation
1.8Vendor-Extensible Fields
1.9Standards Assignments
2Messages
2.1Transport
2.2Message Syntax
2.2.1Common Syntax
2.2.1.1PNRP Cloud Name
2.2.1.1.1Global Cloud
2.2.1.1.2Non-global Public Cloud
2.2.1.1.3Private Cloud
2.2.1.2Password Hash String
2.2.2Group Connect
2.2.2.1Hello
2.2.2.2MyGMC
2.2.2.3YourGMC
2.2.2.4Password
2.2.3Records
2.2.3.1Security Properties
2.2.3.1.1Password
2.2.3.2Membership
2.2.4Record Security Data
2.2.4.1Signature Hash
2.2.5X.509 Usage
2.2.5.1Enhanced Key Usage
2.2.5.2Certificate and Certificate Chain Validation
2.2.5.2.1Certificate Signature and Signature validation.
2.2.5.2.2Certificate Validity
2.2.5.2.3Certificate Chain Validity
2.2.5.3Roles
2.2.6Out-of-band XML
2.2.6.1Invitation
2.2.6.2Identity
3Protocol Details
3.1Peer Details
3.1.1Abstract Data Model
3.1.2Timers
3.1.3Initialization
3.1.4Higher-Layer Triggered Events
3.1.4.1Group Creation
3.1.4.2Opening the PNRP Cloud
3.1.4.3Connecting to a Group
3.1.4.4Begin Listening
3.1.4.5Publish New Credentials
3.1.4.6Modify Security Properties
3.1.4.7Record Publication
3.1.5Processing Events and Sequencing Rules
3.1.6Timer Events
3.1.7Other Local Events
3.1.7.1Record Publication
3.1.7.2Record Received
3.1.7.3Database Synchronized
3.1.7.4Long Term Partition Repair
3.1.7.5GMC Chain Creation
3.2Group Connect Requestor Details
3.2.1Abstract Data Model
3.2.2Timers
3.2.3Initialization
3.2.4Higher-Layer Triggered Events
3.2.4.1Connecting to a Group
3.2.5Message Processing Events and Sequencing Rules
3.2.5.1Receiving a Message During TLS Negotiation
3.2.5.2Messages Received After TLS Negotiation Completion
3.2.5.2.1Receiving Data
3.2.5.2.2Receiving a Hello Message
3.2.5.2.3Receiving a Hello + MyGMC Message
3.2.5.2.4Receiving YourGMC Message
3.2.6Timer Events
3.2.7Other Local Events
3.2.7.1TLS Negotiation Complete
3.2.7.2Encrypting a Message
3.2.7.3Decrypting a Message
3.3Group Connect Authenticator Details
3.3.1Abstract Data Model
3.3.2Timers
3.3.3Initialization
3.3.4Higher-Layer Triggered Events
3.3.4.1Group Listening for Incoming Connect
3.3.5Message Processing Events and Sequencing Rules
3.3.5.1Receiving a Message During TLS Negotiation
3.3.5.2Receiving a Message After TLS Negotiation Has Completed
3.3.5.2.1Receiving Data
3.3.5.2.2Receiving a Hello Message
3.3.5.2.3Receive Hello + MyGMC Message
3.3.5.2.4Receive Hello + Password Message
3.3.5.2.5Receive Password Message
3.3.6Timer Events
3.3.7Other Local Events
3.3.7.1Completing TLS Negotiation
3.3.7.2Encrypting a Message
3.3.7.3Decrypting a Message
4Protocol Examples
4.1Establishing a Connection Using GMC Authentication
4.2Establishing a Connection Using Password Authentication
5Security
5.1Security Considerations for Implementers
5.2Index of Security Parameters
6Appendix A: Product Behavior
7Change Tracking
8Index
1Introduction
This document specifies the Peer-to-Peer Grouping protocol (P2P Grouping), which layers on top of the Peer-to-Peer Graphing Protocol [MS-PPGRH] and adds security and discovery services. Security is provided by way of record signing, group authentication, authorization, and connection encryption. Discovery is provided by the Peer Name Resolution Protocol [MS-PNRP].
Sections 1.5, 1.8, 1.9, 2, and 3 of this specification are normative. All other sections and examples in this specification are informative.
1.1Glossary
This document uses the following terms:
authority: The first portion of a peer name. For secure peer names, this is a hash of a public key represented as 40 hexadecimal characters in printable form. For unsecured peer names, this is "0".
big-endian: Multiple-byte values that are byte-ordered with the most significant byte stored in the memory location with the lowest address.
classifier: A Unicode string used in conjunction with an authority to form a Peer Name.
cloud: A group of Peer Name Resolution Protocol (PNRP) nodes that communicate with each other to resolve names into addresses.
Coordinated Universal Time (UTC): A high-precision atomic time standard that approximately tracks Universal Time (UT). It is the basis for legal, civil time all over the Earth. Time zones around the world are expressed as positive and negative offsets from UTC. In this role, it is also referred to as Zulu time (Z) and Greenwich Mean Time (GMT). In these specifications, all references to UTC refer to the time at UTC-0 (or GMT).
encryption key: One of the input parameters to an encryption algorithm. Generally speaking, an encryption algorithm takes as input a clear-text message and a key, and results in a cipher-text message. The corresponding decryption algorithm takes a cipher-text message, and the key, and results in the original clear-text message.
enhanced key usage (EKU): An extension that is a collection of object identifiers (OIDs) that indicate the applications that use the key.
globally unique identifier (GUID): A term used interchangeably with universally unique identifier (UUID) in Microsoft protocol technical documents (TDs). Interchanging the usage of these terms does not imply or require a specific algorithm or mechanism to generate the value. Specifically, the use of this term does not imply or require that the algorithms described in [RFC4122] or [C706]must be used for generating the GUID. See also universally unique identifier (UUID).
Group Membership Certificate (GMC): A certificate for a given identity within the group.
Group Membership Certificate (GMC) Chain: A chain of GMCs leading to the Group's GRC.
Group Root Certificate (GRC): A self-signed certificate created by the group creator, which is the root of all GMC chains.
Identity Certificate (IDC): A self-signed certificate containing the public key for a given peer identity. An identity certificate is used for identity exchange, and does not appear in a GMC chain.
initialization vector: A data block that some modes of the AES cipher block operation require as an additional initial data input. For more information, see [SP800-38A].
little-endian: Multiple-byte values that are byte-ordered with the least significant byte stored in the memory location with the lowest address.
P2P Graphing: An implementation of the Peer to Peer Graphing Protocol.
P2P Grouping: An implementation of the Peer to Peer Grouping Security Protocol.
peer identity: A public/private key pair used by the Peer Name Resolution Protocol (PNRP).
peer name: A string composed of an authority and a classifier. This is the string used by applications to resolve to a list of endpoints and/or an extended payload. A peer name is not required to be unique. For example, several nodes that provide the same service can register the same Peer Name.
Peer Name Resolution Protocol (PNRP): The protocol that is specified in [MS-PNRP] and is used for registering and resolving a name to a set of information, such as IP addresses.
PNRP Cloud Name: A string that represents a PNRP cloud.
secure peer name: A peer name that has a nonzero authority and is tied to a Peer Identity.
Unicode: A character encoding standard developed by the Unicode Consortium that represents almost all of the written languages of the world. The Unicode standard [UNICODE5.0.0/2007] provides three forms (UTF-8, UTF-16, and UTF-32) and seven schemes (UTF-8, UTF-16, UTF-16 BE, UTF-16 LE, UTF-32, UTF-32 LE, and UTF-32 BE).
universally unique identifier (UUID): A 128-bit value. UUIDs can be used for multiple purposes, from tagging objects with an extremely short lifetime, to reliably identifying very persistent objects in cross-process communication such as client and server interfaces, manager entry-point vectors, and RPC objects. UUIDs are highly likely to be unique. UUIDs are also known as globally unique identifiers (GUIDs) and these terms are used interchangeably in the Microsoft protocol technical documents (TDs). Interchanging the usage of these terms does not imply or require a specific algorithm or mechanism to generate the UUID. Specifically, the use of this term does not imply or require that the algorithms described in [RFC4122] or [C706] must be used for generating the UUID.
MAY, SHOULD, MUST, SHOULD NOT, MUST NOT: These terms (in all caps) are used as defined in [RFC2119]. All statements of optional behavior use either MAY, SHOULD, or SHOULD NOT.
1.2References
Links to a document in the Microsoft Open Specifications library point to the correct section in the most recently published version of the referenced document. However, because individual documents in the library are not updated at the same time, the section numbers in the documents may not match. You can confirm the correct section numbering by checking the Errata.
1.2.1Normative References
We conduct frequent surveys of the normative references to assure their continued availability. If you have any issue with finding a normative reference, please contact . We will assist you in finding the relevant information.
[FIPS197] FIPS PUBS, "Advanced Encryption Standard (AES)", FIPS PUB 197, November 2001,
[IANAPORT] IANA, "Service Name and Transport Protocol Port Number Registry",
[MS-PNRP] Microsoft Corporation, "Peer Name Resolution Protocol (PNRP) Version 4.0".
[MS-PPGRH] Microsoft Corporation, "Peer-to-Peer Graphing Protocol".
[MS-RPCE] Microsoft Corporation, "Remote Procedure Call Protocol Extensions".
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992,
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997,
[RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax Version 1.5", RFC 2315, March 1998,
[RFC2459] Housley, R., Ford, W., Polk, W., and Solo, D., "Internet X.509 Public Key Infrastructure Certificate and CRL Profile", RFC 2459, January 1999,
[RFC3174] Eastlake III, D., and Jones, P., "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, September 2001,
[RFC3447] Jonsson, J. and Kaliski, B., "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003,
[RFC3513] Hinden, R. and Deering, S., "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003,
[RFC4007] Deering, S., Haberman, B., Jinmei, T., et al., "IPv6 Scoped Address Architecture", RFC 4007, March 2005,
[RFC4346] Dierks, T., and Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006,
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006,
[SP800-38A] National Institute of Standards and Technology., "Special Publication 800-38A, Recommendation for Block Cipher Modes of Operation: Methods and Techniques", December 2001,
1.2.2Informative References
None.
1.3Overview
P2P Grouping implements Group Security, which is a Graph Security Provider [MS-PPGRH]. Group Security provides two classes of security features: connection security and record security.
Connection security is implemented by the Group Connect subprotocol (see section 1.3.3), which provides authentication and message encryption within a connection secured by TLS [RFC4346].
Record security provides authorization and record integrity, by implementing record validation and record signing.
P2P Grouping adds publication and discovery of nodes by way of Peer Name Resolution Protocol (PNRP, as specified in [MS-PNRP]). When attempting to connect to a group, P2P Grouping uses Peer Name Resolution Protocol (PNRP) to find an existing group member. When a node begins listening for connections from other group members, it publishes itself using PNRP. PNRP is also queried periodically when P2P Graphing notifies P2P Grouping that a new connection is to be formed to repair undetected long-term partitions.
1.3.1P2P Graphing Constraints
To support the security model, P2P Grouping adds the following constraints to P2P Graphing data.
Identifiers used in P2P Grouping are required to be Peer Names. In P2P Graphing, they are merely length-constrained Unicode strings.
Certain record types are reserved for use by the P2P Grouping infrastructure, and cannot be used by applications building on top of P2P Grouping.
1.3.2Group Security
Group security is based on public/private keys, certificates, and certificate chains.
1.3.2.1Peer Names
The identifier of a group, as well as the identifier of individual members of a group, is based on a public/private key pair. Each group and group member is identified using a string called a Peer Name, which is derived from the public key of that group or group member. Because the Peer Name is derived from a public key, ownership of the Peer Name can be proven by cryptographic challenge. If a challenge is encrypted with the public key from which the Peer Name was derived, only the holder of the private key can give a valid response.
1.3.2.2Certificates
Group authentication is implemented using P2P Certificates (as specified in [MS-PNRP] section 2.2.3.5.1) and certificate chains. Each group has a public/private key pair, which is used to create the Group Root Certificate (GRC). A GRC is a self-signed certificate, and serves as the root authority for membership into the group.
Each Identity has a public/private key pair, which is used to create the Identity Certificate (IDC). The IDC is a self-signed certificate that identifies a given Identity. The IDC is used in the invitation process to generate a Group Membership Certificate (GMC) chain.
Membership in a group is proven with a GMC chain. A GMC chain is rooted at the GRC with the Identity's IDC public key in the leaf GMC.
1.3.2.3Roles
Each member of a group has one or more roles. P2P Grouping defines three roles: Member, Inviting Member, and Administrator.
A Member can publish records, and modify/delete records that the Member published.
An Inviting Member can do everything a Member can do, and can also issue GMCs to new members.
An Administrator can do everything an Inviting Member can do, and can also modify/delete records that were published by any member.
1.3.2.4PNRP Publication
Publication and discovery of nodes uses PNRP. Specifically, a Grouping node publishes itself in PNRP when it starts listening for connections. Each node publishes the same Secure Peer Name, which is the Group Peer Name with the "participant" classifier. Because each node in a given group publishes the same Peer Name, any node within the group is discoverable using the Group Peer Name.
1.3.2.5Joining a Group
Joining is a multistep process that requires one or two out-of-band exchanges, depending on the type of authentication used. These out-of-band exchanges use an XML format specified in section 2.2.6.
GMC-based authentication requires two out-of-band exchanges. First, the invitee sends its IDC to the inviter. The inviter then creates a GMC chain for the invitee and sends it as an invitation to the invitee. Finally, the invitee connects using P2P Grouping to any group member and authenticates.