[MS-GRVPROT]: Groove Protocols Overview
Intellectual Property Rights Notice for Protocol Documentation Copyrights. This protocol 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 may make copies of it in order to develop implementations of the protocols, and may distribute portions of it in your implementations of the protocols or your documentation as necessary to properly document the implementation. This permission also applies to any documents that are referenced in the protocol documentation. No Trade Secrets. Microsoft does not claim any trade secret rights in this documentation. Patents. Microsoft has patents that may cover your implementations of the protocols. Neither this notice nor Microsoft's delivery of the documentation grants any licenses under those or any other Microsoft patents. However, the protocols may be covered by Microsoft's Open Specification Promise (available here: http://www.microsoft.com/interop/osp). If you would prefer a written license, or if the protocols are not covered by the OSP, patent licenses are available by contacting protocol@microsoft.com. Trademarks. The names of companies and products contained in this documentation may be covered by trademarks or similar intellectual property rights. This notice does not grant any licenses under those rights.
Reservation of Rights. All other rights are reserved, and this notice does not grant any rights other than specifically described above, whether by implication, estoppel, or otherwise. Tools. This protocol documentation is intended for use in conjunction with publicly available standard specifications and network programming art, and assumes that the reader either is familiar with the aforementioned material or has immediate access to it. A protocol specification 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.
1 of 28
[MS -GRVPROT] - v1.0 Groove Protocols Overview Copyright © 2008 M icrosoft Corporation. Release: Friday, June 27, 2008
Abstract
The Groove Protocols Overview document contains a brief description of the Groove client, relay server, management server, and data bridge server, and the protocols used between the client and servers. It describes major functionality of the client and servers, including identity creation, account configuration, domain enrollment, client registration with a relay server, and data synchronization between the client and the data bridge server. The document also discusses the multiple layers of protocols and related security considerations.
Revision Summary
Author Microsoft Corporation Microsoft Corporation
Date April 4, 2008 June 27, 2008
Version 0.1 1.0
Comments Initial Availability Revised and edited the technical content
2 of 28
[MS -GRVPROT] - v1.0 Groove Protocols Overview Copyright © 2008 M icrosoft Corporation. Release: Friday, June 27, 2008
Table of Contents
1 2 3 Introduction ............................................................................................................................ 4 Definitions............................................................................................................................... 5 System Architecture ................................................................................................................ 6 3.1 Management Server.......................................................................................................... 6 3.2 Relay Server ..................................................................................................................... 7 3.3 Data Bridge Server........................................................................................................... 8 3.4 Groove Client ................................................................................................................... 9 3.5 Protocol Relationships ................................................................................................... 10 3.5.1 Simple Symmetrical Transmission Protocol (SSTP) .............................................. 10 3.5.2 Key Capabilities of SSTP ....................................................................................... 11 3.5.3 HTTP Encapsulation of SSTP ................................................................................ 11 3.5.4 WAN DPP............................................................................................................... 14 3.5.5 Groove SOAP Protocol ........................................................................................... 14 3.5.6 Groove Dynamics Protocol ..................................................................................... 15 3.5.7 Groove RDB Commands Protocol.......................................................................... 15 3.6 Protocol Security ............................................................................................................ 15 3.6.1 SSTP Security ......................................................................................................... 16 3.6.2 Groove Dynamics Protocol Security ...................................................................... 16 3.6.3 Groove SOAP Security ........................................................................................... 16 3.7 Stack View Diagrams ..................................................................................................... 17 3.8 Logical Dependencies View Diagrams .......................................................................... 19 3.9 Composite View Diagrams............................................................................................. 20 Examples and Scenarios....................................................................................................... 20 4.1 Identity Creation, Account Configuration, and Domain Enrollment ............................. 20 4.2 Registration with the Relay Server................................................................................. 22 4.3 Multiple Relay Server Assignments................................................................................ 25 4.4 Data Synchronization between Clients and the Data Bridge Server ............................. 25 4.5 Other Examples .............................................................................................................. 25 References ............................................................................................................................. 25 Appendix A: Product Behavior ............................................................................................ 27 Index ...................................................................................................................................... 28
4
5 6 7
3 of 28
[MS -GRVPROT] - v1.0 Groove Protocols Overview Copyright © 2008 M icrosoft Corporation. Release: Friday, June 27, 2008
1 Introduction
This document provides a high- level description of how the Groove protocols interact and a summary of the individual protocols. In this protocol system, three types of servers are used to manage clients and facilitate client communications: the management server, the relay server, and the data bridge server. Section 2 presents term definitions. Section 3 and section 4 present key concepts relevant to the application and provide an application-specific example of how these protocols can be used. The information in this overview covers the following interrelated protocols:
Protocol Name Simple Symmetric Transport Protocol (SSTP) Protocol Description and Usage This protocol is a TCP-based, message-oriented, application-layer binary protocol, that enables two higher-level applications to engage in bi-directional communication and to exchange data over multiple logical sessions on a single network connection. This protocol, a subset of the SSTP protocol [M S-GRVSSTP], provides a mechanism for a client and a relay server to securely exchange secret keys that are used to authenticate each other through a challenge/response message sequence. This collection of protocols and methodologies is used to route Simple Symmetric Transport Protocol (SSTP) through firewalls and proxies. Document Short Name [M SGRVSSTP]
Simple Symmetric Transport Protocol (SSTP) Security Protocol HTTP Encapsulation of Simple Symmetric Transport Protocol Client to M anagement Server Groove SOAP Protocol
[MSGRVSSTPS]
[M SGRVHENC]
This protocol is a request/response message exchange protocol, built on top of a custom implementation of an early version of SOAP, that provides support for managing clients through identity and device management and policy distribution. The protocol is a request and response-based client-server protocol, built on top of a custom and secure implementation of a SOAP protocol, that enables managed client utilization of relay services. This client-server protocol enables clients to discover and acquire the presence information of other cooperating client devices.
[M SGRVSPCM ]
M anagement Server to Relay Server Groove SOAP Protocol Wide Area Network Device Presence Protocol (WAN DPP) Groove Dynamics Protocol
[M SGRVSPM R]
[M SGRVWDPP]
This protocol is an application-layer distributed protocol for consistently ordering operations on an arbitrary number of peers.
[M SGRVDYNM ]
4 of 28
[MS -GRVPROT] - v1.0 Groove Protocols Overview Copyright © 2008 M icrosoft Corporation. Release: Friday, June 27, 2008
Protocol Name Groove RDB Commands Protocol
Protocol Description and Usage This protocol is an application-layer distributed protocol that enables clients and servers to use encoded XM L messages to synchronize data in a shared space.
Document Short Name [M S-GRVRDB]
2 Definitions
The following terms are defined in [MS-GLOS]: Active Directory Certification Authority (CA) Group Policy Object
The following terms are defined in [MS-OFSGLOS]:
Account Connection Contact Data bridge server Delta Dequeue Endpoint Engine Enqueue Fanout IANA Identity Identity URL Managed client Managed identity Management domain Management server Membe r NAT Notify WAN DPP Peer Client Public Key Infrastructure (PKI) Pre-authentication Token Presence Presence information
5 of 28
[MS -GRVPROT] - v1.0 Groove Protocols Overview Copyright © 2008 M icrosoft Corporation. Release: Friday, June 27, 2008
Presence server Publis h Record Database Relay server Relay URL Resource handler Resource URL Session Shared space Store and forward Subscribe Tool
3 System Architecture
3.1 Management Server
The Management Server provides client management services, such as creating an account and enrolling it in a domain, gathering user statistics, backup services, directory services, password management services and audit services as described in [MS-GRVSPCM], section 1.3. Clients communicate with the management server via the Client to Management Server Groove SOAP Protocol [MS-GRVSPCM], over client- initiated connections, in order to retrieve account settings and policy updates. The management server communicates with relay servers using the Management Server to Relay Server Groove SOAP Protocol [MS-GRVSPMR], in order to preauthenticate clients registering with the relay server. The management server always initiates connections to relay servers. Relay servers never initiate connections to the management server. Figure 3 illustrates the protocols used in the management server and the relationship between them. Important aspects of the management server include: Policy Administration—Dissemination of client and shared s pace usage policies over large environments can be performed through the management server. Policies can be set on entire management domains, domain groups, or individuals. Usage policies control account backup scheduling, password strength, identity publishing, communications with clients outside the management domain, and other identity and device activities. Account Backups—User accounts are periodically backed up and stored on the management server. Later, accounts can be restored from the management server to client devices as needed. After account restoration, users will have their account data, all their contacts, and a listing of all the shared spaces they belong to.
6 of 28
[MS -GRVPROT] - v1.0 Groove Protocols Overview Copyright © 2008 M icrosoft Corporation. Release: Friday, June 27, 2008
Usage Monitoring—Managed clients regularly report usage statistics to the management server which enables the monitoring user of activities, shared space characteristics, and tool usage. Auditing—Centralized auditing of selected client events can be performed through the management server audit functions. S uch events include user logon and logoff, instant messages, and file addition and deletion. These events are securely logged on the user's local device, then periodically and securely uploaded to the management server, and stored in a database for querying and reporting at a later time. Password Management Services—The management server includes password management services, such as automatic password reset, which enables a user to request a password reset and receive a temporary password via e- mail, and password strength enforcement. Directory Service—The management server maintains a contacts directory that can be searched by management domain members. Users' identities are published on the management server. Management domain members can search for others' contacts, and fetch contacts from the contacts directory. Assignment of relay servers—Administrators can assign managed identities to a sequence of relay servers, providing relay redundancy. See section 4.3, Multiple Relay Server Assignments.
3.2 Relay Server
The Relay Server provides a store-and-forward service to transmit data between clients when they cannot connect directly. Clients initiate communication with the relay servers via Simp le Symmetric Transport Protocol [MS-GRVSSTP] over a default TCP transport. If necessary, HTTP Encapsulation of Simple Symmetric Transport Protocol [MS-GRVHENC] is used as an alternative transport for SSTP, in order to traverse firewalls and proxy servers. The relay server also provides a presence service that enable clients to discover each other on a network and determine each other's presence information such as online state and public and private IP addresses. Clients publish their presence information to the relay server via the Wide Area Network Device Presence Protocol (WAN DPP) [MS-GRVWDPP]. Figure 4 illustrates these protocol relationships. The relay server has the following functions: Offline Support—When a user makes a change to a shared space, such as an edit to a file, the user's client encrypts and signs the data generated by the changes, and then attempts to send the data to all other members of the shared space in a direct peer-to-peer manner. In cases where a peer client is offline, the sending client will automatically send
7 of 28
[MS -GRVPROT] - v1.0 Groove Protocols Overview Copyright © 2008 M icrosoft Corporation. Release: Friday, June 27, 2008
the data to the recipient's relay server, where the data is deposited in a specific queue for the recipient. When the offline client next connects to its relay server, the encrypted data from the relay queue is dequeued by the client. The recipient does not explicitly request changes from the relay server; all shared space data is dequeued when the offline client comes online and connects to its relay server. Data stored on the relay server is encrypted by the Groove Dynamics Protocol [MS-GRVDYNM] and this encrypted data is never decrypted by the relay server. After the client dequeues the data from its relay server, the client will integrity-check and decrypt the data. Fire wall Transparency— By default, the clients always attempt to communicate with other clients directly using SSTP [MS-GRVSSTP] through TCP port 2492. This port is registered with the Internet Assigned Numbers Authority for use by the SSTP Protocol. However, if two clients are separated by firewalls or proxy servers or Network Address Translation (NAT) devices that do not permit inbound connections from another client, all communication that occurs between those clients is done through the relay server. If inbound connections to clients on port 2492 are not possible, the clients will attempt to communicate through the relay server using the SSTP protocol [MS-GRVSSTP] on port 2492. If client connections to the relay on port 2492 fail, the clients can attempt to use one of the HTTP encapsulation protocols as specified by [MS-GRVHENC] for connecting to the relay. The relay server listens for communications on ports 2492, 443 and 80. As a result, as long as the client is able to initiate a connection to the relay server, it is able to enqueue and dequeue encrypted data from the relay server. Bandwidth Optimization—Relay servers facilitate bandwidth optimization for a client sending data to other clients. As an example, a sending client can send one copy of a file to its relay server as part of a shared space update. The relay server will use fanout to route the file to other members of the shared space, as opposed to having the sending client transmit the file directly to each member or each member's relay server. This reduces the bandwidth required by the sending client. Device Presence—A relay server also acts as a presence server to enable clients to determine each others' device presence information. WAN DPP [MS-GRVWDPP] enables a publish/subscribe model for the client to acquire device presence information. The client uses this device presence information in an attempt to make direct connections to peers. If these direct connections fail, then the relay server is used to transmit messages to peers.
3.3 Data Bridge Server
The data bridge server facilitates data integration between clients and external databases or other applications, enabling developers to build custom solutions that connect Groove client
8 of 28
[MS -GRVPROT] - v1.0 Groove Protocols Overview Copyright © 2008 M icrosoft Corporation. Release: Friday, June 27, 2008
applications with enterprise data sources. Developers use the Groove Web Services Interface [MSDN-GWSDF] to build a custom web services client application that interfaces with the data bridge server and synchronizes changes between the data bridge server and enterprise data source. For enterprise data source integration, a shared space is typically created which includes a Record Database (RDB) engine supporting the commands of the Groove RDB Commands Protocol. Data managed by RDB is then updated either via clients or the data bridge server. Changes made by clients are propagated to the data bridge server via the Groove RDB Commands Protocol. Once the changes are applied locally to the shared space within the data bridge server, the updates are then propagated to enterprise data sources via the custom web services application. The custom web service application also detects changes made to enterprise data sources and propagates these changes to the data bridge server. The data bridge server in turn propagates these changes to clients using the Groove RDB Commands Protocol. Figure 1 illustrates how the data bridge server is used to synchronize changes from a client to an external data source.
Figure 1. Synchronizing Changes from the Client to an External Data Source Using the Data Bridge Server. Groove RDB Commands Protocol uses Groove Dynamics Protocol [MS-GRVDYNM] as its transport to ensure that the clients and the data bridge server are synchronized. The Groove Dynamics Protocol uses Simple Symmetric Transport Protocol (SSTP) [MS-GRVSSTP] as the transport between clients and the data bridge server. Figure 2 illustrates the relationship of these protocols.
3.4 Groove Client
The Groove client provides a secure environment for users to share data and work together. In order to do so, clients create shared spaces which contain a set of tools. These tools are
9 of 28
[MS -GRVPROT] - v1.0 Groove Protocols Overview Copyright © 2008 M icrosoft Corporation. Release: Friday, June 27, 2008
applications specific to a user's need in order to be able to collaborate with other clients. All data in a shared space is synchronized with other clients that have the same shared space. This is done by the Groove Dynamics Protocol [MS-GRVDYNM]. Each Groove client user is associated with an account. An account contains one or more identities. Each identity is a digital persona for the user and provides a unique set of cryptographic keys. Membership in shared spaces is based on identities. Only the user's identity is visible in a shared space, not the user's account. The client uses SSTP [MS-GRVSSTP] to communicate with each other and with the relay server. Alternatively, when communicating with the relay, the client can use SSTP over HTTP Encapsulation of SSTP [MS-GRVHENC]. The client uses WAN DPP [MS-GRVWDPP] to publish its presence information to a presence server. The client communicates with the management server via the Client to Management Server Groove SOAP Protocol [MSGRVSPCM]. Figure 2 illustrates the relationship of these protocols.
3.5 Protocol Relationships
Clients, relay servers and data bridge servers use [MS-GRVSSTP] as a transport for several different application- layer protocols such as the WAN DPP [MS-GRVWDPP] protocol and Groove Protocol [MS-GRVDYNM]. Groove RDB Commands Protocol uses Groove Dynamics Protocol as its underlying transport. The Client to Management Server Groove SOAP Protocol [MS-GRVSPCM] is used between the clients and the management server and Management Server to Relay Server Groove SOAP Protocol [MS-GRVSPMR] is used between the management server and the relay server. Both protocols are layered on top of HTTP version 1.1. Use of HTTPS [RFC2818] as a transport for Client to Management Server Groove SOAP Protocol [MS-GRVSPCM] is an administrator-configurable option of the management server. The auto account code configuration service, which enables a client to associate its identity with a member on the management server, uses HTTPS as the transport. For further details, see [MSGRVSPCM], section 1.3.1.5.
3.5.1 Simple Symmetrical Transmission Protocol (SSTP)
The Simple Symmetrical Transmission Protocol (SSTP) is an application-layer protocol designed to enable two programs to engage in bi-directional communication. It supports multiple client applications communicating over a single network connection and enables efficient utilization of communication resources. The SSTP protocol relies on its underlying transport to provide a full duplex, reliable, ordered byte stream for delivery of SSTP data. Clients use TCP or HTTP Encapsulation of SSTP [MSGRVHENC] to fulfill these transport requirements.
10 of 28
[MS -GRVPROT] - v1.0 Groove Protocols Overview Copyright © 2008 M icrosoft Corporation. Release: Friday, June 27, 2008
SSTP uses the official IANA-assigned port 2492 [IANAPORT] if using SSTP, port 443 if using Secure Tunnel Connections [MS-GRVHENC], section 1.3.2, or port 80 if using HTTP Encapsulation of SSTP [MS-GRVHENC], section 1.3.1. 3.5.2 Key Capabilities of SSTP
SSTP has the following capabilities: Supports multiplexed messaging to multiple application endpoints over a single connection. Supports the ability to route messages through relay servers. Provides application- level message acknowledgments over a stream transport. Supports efficient streaming of large messages. Supports application detection of network segmentation. Provides a transport for WAN DPP messages. Provides a transport for Groove Dynamics Protocol messages.
3.5.3 HTTP Encapsulation of SSTP
If a client cannot establish an SSTP connection to the relay server using port 2492 due to a proxy server, firewall, or Network Address Translator (NAT) device [RFC1631], it can attempt to establish SSTP connections using HTTP Encapsulation of SSTP [MS-GRVHENC]. HTTP Encapsulation of SSTP is adaptable to various types of network topologies without requiring a network configuration change. The client detects the existing network configuration and uses the appropriate sub-protocol: either Secure Tunneling of SSTP over Port 443, SOCKs connections, or one of three HTTP encapsulation techniques (HTTP LongLived, HTTP KeepAlive or HTTP Polling). Traversal of a proxy server, and some firewalls, incurs an extra connection hop. This is because proxy servers and firewalls can examine the headers of the HTTP encapsulated SSTP data. Also some proxy servers buffer the data before forwarding it to the relay server. This extra hop can increase latency and decrease data throughput. Traversal of firewalls and proxy servers also requires additional connections in some cases in order to provide a full duplex transport for SSTP. Using SSTP over TCP is the preferred protocol for client and relay server communications because it avoids the overhead associated with HTTP encapsulation of SSTP messages, the extra connection hop from client to relay server via a proxy server, and the connection management required for proxy servers and firewalls. The following sections introduce HTTP encapsulation sub-protocols: Secure Tunneling Proxy Protocol over Port 443, SOCKs connections, and the three types of HTTP encapsulation of
11 of 28
[MS -GRVPROT] - v1.0 Groove Protocols Overview Copyright © 2008 M icrosoft Corporation. Release: Friday, June 27, 2008
SSTP. Each sub-protocol has its own advantages and constraints and is optimized for different network configurations.
3.5.3.1 Secure Tunnel Proxy Protocol
Secure Tunnel Proxy Protocol is a tunneling mechanism for secure HTTP (HTTPS) protocols [TCPPROXY] to traverse an HTTP proxy or firewall. However, it can be used by other protocols if the proxy or firewall implementation does not inspect the data stream. If a firewall or other perimeter device blocks 2492/TCP outbound connections to the relay server, a client can establish an SSTP connection to relay servers over the Secure Socket Layer (SSL) port 443/TCP [TCPPROXY]. This Secure Tunnel connection uses the SSTP protocol over a TCP connection, but in this case a Secure Tunnel handshake precedes the SSTP message stream sent to the proxy. The proxy response is received before the SSTP protocol begins on the connection and the connection is accepted on port 443. Once established, a Secure Tunnel connection remains for the duration of the SSTP connection between a client and relay server. This protocol is more efficient than the three HTTP encapsulation protocols because there is no additional overhead beyond SSTP except for the initial connection handshake. In addition, because the Secure Tunnel connections are created for the duration of the SSTP connection, it does not require additional connections to achieve the full duplex requirement of SSTP, unlike the HTTP Encapsulated sub-protocols discussed later.
3.5.3.2 SOCKS Connection
SOCKS connections use SSTP over TCP through a SOCKS server [RFC1928]. The client connections on the relay server are accepted on port 443. SOCKS handshake occurs before SSTP protocol begins on the connection. After authentication, the SOCKS connection is maintained for the lifetime of the SSTP connection between a client and relay server. Similar to the Secure Tunneling Proxy Protocol, the SOCKS Connection protocol performs better than the three HTTP encapsulation protocols because it involves no protocol overhead except for the initial connection handshake, and does not require additional connections to achieve the full duplex requirement of SSTP, unlike the HTTP Encapsulated sub-protocols discussed later.
3.5.3.3 HTTP LongLived Connections
HTTP LongLived is an HTTP based sub-protocol that is used to traverse proxies and firewalls that do not buffer either incoming or outgoing traffic. Two half-duplex connections are used between the client and the relay server to satisfy the full-duplex requirement of SSTP. The two half-duplex connections provide a virtual long- lived connection, where one channel transmits
12 of 28
[MS -GRVPROT] - v1.0 Groove Protocols Overview Copyright © 2008 M icrosoft Corporation. Release: Friday, June 27, 2008
data from the client to the relay server (the POST channel) and a second channel is used by the client to receive data from the relay server (the GET channel). The client connects to the relay server over port 80. This encapsulation protocol performs better than HTTP KeepAlive or HTTP Polling protocols because it is designed to work with proxy servers that do not buffer inbound or outbound data. Exhaustion of internal buffers can degrade performance and result in rejection of client connection attempts. Moreover, HTTP LongLived is more efficient because it streams the SSTP commands with minimum HTTP header overhead.
3.5.3.4 HTTP KeepAlive Connections
HTTP KeepAlive is an HTTP based sub-protocol that that is used to traverse proxies and firewalls that buffer data in outbound (to a relay server) or inbound (from a relay server) directions. This protocol involves two connections or channels that are half-duplex and provides a virtual full-duplex connection that SSTP requires. The client connects to the relay server over port 80. The client creates two long- lived TCP connections--one for outbound messages from client to the relay server and one for inbound messages from the relay server to client. The TCP connection from client to the relay server encapsulates SSTP commands within HTTP POST requests. The TCP connection for messages from the relay server to the client encapsulates the SSTP commands as HTTP GET responses. The HTTP KeepAlive protocol sends many POST requests over one channel from client to re lay server and many short GET requests over the second channel from relay server to client. SSTP messages can be fragmented into several shorter HTTP encapsulated messages. Similar to the HTTP LongLived Protocol, the HTTP KeepAlive Protocol is an efficient network transport because the TCP connections are long- lived and do not need to be closed after each POST or GET request to the relay server. However, KeepAlive requires additional HTTP headers so that the HTTP responses fit within the buffer limitations of the proxies that are being traversed.
3.5.3.5 HTTP Polling Connections
HTTP Polling virtualizes a long-lived SSTP connection using many short- lived HTTP connections carrying HTTP Request/Response messages encapsulating SSTP data. For greatest compatibility with various proxy servers and firewalls, this protocol uses a minimum number of HTTP headers. A client sends a relay server data via a POST request and the relay server replies with a POST response. The client connects to the relay server o ver port 80.
13 of 28
[MS -GRVPROT] - v1.0 Groove Protocols Overview Copyright © 2008 M icrosoft Corporation. Release: Friday, June 27, 2008
HTTP Polling is the least efficient of the previously mentioned protocols because a TCP connection is created for every HTTP POST request. However, HTTP Polling can succeed when other encapsulation protocols fail due to proxy or firewall restrictions.
3.5.4 WAN DPP
Wide Area Network Device Presence Protocol (WAN DPP) [MS-GRVWDPP] is a messagebased protocol that uses SSTP as its transport. Clients use WAN DPP to publish their online status and device identification to a presence server, and to subscribe to the published information of other clients. Each WAN DPP message is carried in an SSTP message. The presence server distributes published presence information to subscribing clients. Presence servers also store published device information such as online state and public and private IP addresses, and notify subscribing clients of updates to specified device information
3.5.5 Groove SOAP Protocol
Groove SOAP Protocol is a request/response message exchange protocol built on top of a custom implementation of an early version of SOAP. Groove SOAP Protocol uses HTTP 1.1 or HTTPS as its underlying transport. The client and the relay server communicate with the management s erver using variants of the Groove SOAP protocol. Client to management server communication occurs over the Client to Management Server Groove SOAP Protocol [MS-GRVSPCM], and is used to configure client accounts, update security policies on the client device, and perform other management functions. Management server to relay server communication occurs over the Management Server to Relay Server Groove SOAP Protocol [MS-GRVSPMR], and is used to distribute pre-authentication information to relay servers for newly created managed identities. The Groove SOAP protocols predate the standard SOAP protocol and do not comply with either v1.1 or v2.0 versions of the standard SOAP protocol [SOAP1.1]. In communication between the client and management server, the client always initiates requests to the management server; the management server never initiates connections to a client. Likewise, in communication between the management and relay servers, the management server always initiates connection to the relay server; the relay server never initiates connections to the management server. Groove SOAP has an optional security layer to provide integrity and confidentiality of messages. Groove SOAP security is covered in the corresponding specifications for [MS-GRVSPCM], section 1.3.2, and [MS-GRVSPMR], section 1.3.3.
14 of 28
[MS -GRVPROT] - v1.0 Groove Protocols Overview Copyright © 2008 M icrosoft Corporation. Release: Friday, June 27, 2008
3.5.6 Groove Dynamics Protocol
The Groove Dynamics Protocol [MS-GRVDYNM] is used to synchronize data between peer clients, one of which can be a data bridge server. Once the clients are in a shared space together, Groove Dynamics Protocol is used to ensure that all spaces have the same data. The Groove Dynamics Protocol has the following key capabilities: Consistently orders operations between arbitrary numbers of peers. Consists of XML encoded messages that are contained in one or more SSTP messages. Provides a transport mechanism for the application level Groove RDB Commands Protocol [MS-GRVRDB]. Supports a unit of transactional consistency in a shared space known as a delta. A delta contains one or more commands defined in Groove RDB Commands Protocol [MSGRVRDB], section 2. Guarantees that all commands in a delta are executed sequentially. Encrypts and signs all messages.
3.5.7 Groove RDB Commands Protocol
The Groove RDB Commands Protocol [MS-GRVRDB] is used to distribute database commands between clients and the data bridge server when they are members of a common shared space containing an RDB engine. RDB is typically used for integration with enterprise data sources. The client and the data bridge server both contain standard tools that use the RDB engine. When updates are made to a shared space, the RDB commands are contained in a delta. A delta is the unit of synchronization in the Groove Dynamics Protocol. The Groove RDB Commands Protocol uses the Groove Dynamics Protocol [MS-GRVDYNM] as a transport mechanism. Examples of RDB commands are Add Records, which adds records to an application defined database, and Delete Records, which deletes records from the database.
3.6 Protocol Security
Multiple security protocol layers exist between cooperating client and server applications. The SSTP protocol supports user and device authentication when connecting to relay servers to dequeue messages. The Groove Dynamics Protocol secures data transmitted over SSTP, either peer-to-peer or through a relay server. The Groove SOAP protocol secures message traffic between the client and the management server, and between the management and relay server.
15 of 28
[MS -GRVPROT] - v1.0 Groove Protocols Overview Copyright © 2008 M icrosoft Corporation. Release: Friday, June 27, 2008
3.6.1 SSTP Security
When clients cannot communicate with each other directly (for example, because a client is offline or blocked by firewalls or NAT devices), they can send data to the relay server. SSTP Security [MS-GRVSSTPS] is a sub-protocol within the SSTP protocol that enables a relay server to authenticate connecting clients before permitting them to dequeue data. The protocol messages of SSTP Security are embedded in SSTP commands. Thus the SSTP Security protocol is dependent on SSTP and functions only within SSTP. SSTP Security uses cryptographic algorithms for registration and optional initial authentication of devices and users. SSTP security provides no protection against connection take-over, eavesdropping, or message modification, insertion, or deletion. The Groove Dynamics Protocol [MS-GRVDYNM] instead provides these functions for application layer messages transmitted between clients or between clients and the data bridge server.
3.6.2 Groove Dynamics Protocol Security
The client employs the Groove Dynamics Protocol [MS-GRVDYNM] to encrypt, sign, and decrypt and verify signatures of messages exchanged between clients and the data bridge server, as specified in [MS-GRVDYNM], section 3.1.4, and [MS-GRVDYNM], section 3.1.5.
3.6.3 Groove SOAP Security
Groove SOAP security is a part of the Groove SOAP protocols: Client to Management Server Groove SOAP [MS-GRVSPCM], section 1.3.2, and Management Server to Relay Server Groove SOAP [MS-GRVSPMR], section 1.3.3. All requests and many of the responses from Management Services, Backup Services, Directory Services, Auditing Services and Password Management Services, and part of the messages from Account Configuration Services, are encrypted and digitally signed. This ensures the confidentiality and integrity of the data, using a secret key shared between the client and the management server. Likewise, within Management Server to Relay Server Groove SOAP [MS-GRVSPMR], messages to add users and modify relay settings are encrypted and digitally signed using a secret key shared between the management server and the relay server.
16 of 28
[MS -GRVPROT] - v1.0 Groove Protocols Overview Copyright © 2008 M icrosoft Corporation. Release: Friday, June 27, 2008
3.7 Stack View Diagrams
Figure 2: Client and Data Bridge Server Protocol Stack
Figure 3: Management Se rver Protocol Stack
17 of 28
[MS -GRVPROT] - v1.0 Groove Protocols Overview Copyright © 2008 M icrosoft Corporation. Release: Friday, June 27, 2008
Figure 4: Relay Server Protocol Stack
18 of 28
[MS -GRVPROT] - v1.0 Groove Protocols Overview Copyright © 2008 M icrosoft Corporation. Release: Friday, June 27, 2008
3.8 Logical Dependencies View Diagrams
Figure 5: Flow Diagram of Groove Protocols
19 of 28
[MS -GRVPROT] - v1.0 Groove Protocols Overview Copyright © 2008 M icrosoft Corporation. Release: Friday, June 27, 2008
3.9 Composite View Diagrams
Figure 6: Composite View of Groove Protocols.
4 Examples and Scenarios
4.1 Identity Creation, Account Configuration, and Domain Enrollment
This section describes the protocol handshake between the client and supporting servers when a n identity is created, configured, and enrolled in a management domain so that it becomes a managed identity.
20 of 28
[MS -GRVPROT] - v1.0 Groove Protocols Overview Copyright © 2008 M icrosoft Corporation. Release: Friday, June 27, 2008
Administrators prepare their environment for management by adding user information, such as their names and e- mail addresses, to a domain defined in the management server. User information can be entered manually or imported via integration with an Active Directory server. In either case, the management server generates a unique account configuration code for each user. The management server uses the Lightweight Directory Access Protocol (LDAP) [RFC2251] to communicate with the Active Directory Server. When users are manually added to a management domain, the administrator sends the systemgenerated account configuration code and a management server URL to each user via e-mail from the management server. The management server uses the Simplified Mail Transfer Protocol (SMTP) [RFC2821] to send this e-mail. Users configure their managed accounts as instructed in the e-mail and then the client software contacts the management server. Clients communicate with the management server using the Client to Management Server Groove SOAP Protocol [MS-GRVSPCM]. When the management server receives an account configuration code from a client, it replies with a message containing identity metadata, security policies, and relay assignments. This message also contains a pre-authentication token–a secret unique identifier– that is used to ensure that only pre-authorized clients can register with its relay server. In automated environments, user information, such as user name and e-mail address, is imported from the Active Directory server and client accounts are automatically configured. In this environment, the client uses the operating system credentials and SPNEGO-based Kerberos and NTLM HTTP Authentication [RFC4559], instead of account configuration codes, to authenticate users to the management server. Prior to clients contacting the management server, an administrator disseminates the management server URL to target clients via a Windows® Group Policy Object (GPO) [TECHNET-GPO]. Using the management server URL, clients contact the management server with each user's Windows credentials, which are matched against user login names imported from the Active Directory® server. The management server responds with the appropriate identity meta-data, policies, relay assignments, and the pre-authentication token for relay registration. With this information, the client creates a managed identity which contains the cryptographic keys used to secure user data exchanges by the Groove Dynamics Protocol [MS-GRVDYNM]. Managed identities are enrolled in a management domain. Management servers also support PKI functions for additional authentication security. If the Groove Public Key Infrastructure (PKI) [MSFT-GPKI] feature is enabled, each managed identity is signed by the management server Certification Authority (CA). If a third-party Public Key Infrastructure (PKI) is enabled, identities are signed by third-party CAs that are trusted by the client.
21 of 28
[MS -GRVPROT] - v1.0 Groove Protocols Overview Copyright © 2008 M icrosoft Corporation. Release: Friday, June 27, 2008
Using the Management Server to Relay Server Groove SOAP protocol [MS-GRVSPMR], the management server passes the client's pre-authentication token (created during the identitycreation process) to the client's assigned relay server. If the relay server has not registered with the management server, it does not yet have the required shared secret key from the management server. Receipt of the Groove SOAP message containing the pre-authentication token causes the relay server to return a message that registration has failed. On receipt of this message, the management server initiates registration with the relay server, sends it the shared secret key, and resends the client pre-authentication token. The relay server registration with the management server happens every time the relay server restarts because it does not save the shared secret key in a persistent storage. The relay server uses the pre-authentication token sent by the management server to identify the client during the client registration with the relay server. (See section 4.2, Registration with the Relay Server.) The client presents the pre-authentication token as proof of identity during registration with the relay server. After successful pre-authentication with the relay server, the client registers its identity and device with the relay server and then can dequeue data from the relay server. Figure 7 illustrates the flow of the pre-authentication token from the client to the management server and from the management server to the relay server.
4.2 Registration with the Relay Server
Once an identity is created on a client and assigned relay servers, the client communicates with the relay server using SSTP [MS-GRVSSTP] or SSTP over HTTP Encapsulation of SSTP [MSGRVHENC]. Via SSTP Security [MS-GRVSSTPS], the client supplies to the relay server a unique pre-authentication token obtained from the management server as part of each client's account configuration. Each client uses the public key certificate of the assigned relay server to register with that relay server. The user's contact information includes one or more relay server URLs assigned by the management server during account configuration. Other clients use these relay server URLs to send data to the client either when it is offline or when it is unreachable because of firewalls or proxy servers. Clients discover each other's assigned relays through the exchange of contact information. Contact information can be exchanged either out of band (such as via e- mail) or as a result of joining a shared space. When the user account registers with a relay server, the account establishes a shared secret key with the relay server that provides a mutually authenticated link for all account-to-relay communication. The secret key, shared solely with that user account, prevents a false user or relay server from mounting a denial-of-service attack on the system (intercepting messages targeted for another account or relay).
22 of 28
[MS -GRVPROT] - v1.0 Groove Protocols Overview Copyright © 2008 M icrosoft Corporation. Release: Friday, June 27, 2008
The relay server can access only message header information needed to locate devices or a target device's relay server. The end-to-end data encryption provided by the Groove Dynamics Protocol [MS-GRVDYNM] prevents the relay server from reading the data inside messages.
23 of 28
[MS -GRVPROT] - v1.0 Groove Protocols Overview Copyright © 2008 M icrosoft Corporation. Release: Friday, June 27, 2008
Whenever a user's information is added to a management server domain, the following sequence of events occurs to enable the user's client device to communicate with its assigned relay server.
Figure 7: Sequence Diagram During Client Identity Registration and Domain Enrollment
24 of 28
[MS -GRVPROT] - v1.0 Groove Protocols Overview Copyright © 2008 M icrosoft Corporation. Release: Friday, June 27, 2008
4.3 Multiple Relay Server Assignments
To provide for relay server redundancy, the management server can assign multiple relay servers for a given client. The list of relay servers is an ordered sequence–the first relay server in the sequence is the client's primary relay server. The client registers with all assigned relay servers and connects to all assigned relays to dequeue and to publish presence information. When the primary relay server is unavailable, the next relay server in the sequence is used by enqueuing clients until the primary relay server comes back online. If both the primary and the secondary relay servers are offline, the third relay server takes over as the primary relay server and so on. If the end of the sequence is reached and no server is available, the client will continue trying the relays in order, starting with the first relay in the sequence again.
4.4 Data Synchronization between Clients and the Data Bridge Server
Clients can synchronize data with the data bridge server using the Groove Dynamics Protocol [MS-GRVDYNM]. The client and data bridge server use the Groove RDB Commands Protocol [MS-GRVRDB] to issue commands that update application data over the Groove Dynamics Protocol [MS-GRVDYNM]. The Groove Dynamics Protocol ensures that the client and the data bridge server have the same shared space data after a sequence of Groove RDB Commands Protocol commands are issued. The Groove Dynamics Protocol messages are exchanged between the client and the data bridge using SSTP [MS-GRVSSTP] as a transport. If the client and data bridge server cannot communicate directly they will attempt to communicate through their assigned relay servers.
4.5 Other Examples
Examples of other Groove protocol exchanges are provided in section 4 of the individual protocol specification documents: [MS-GRVSSTP], [MS-GRVSSTPS], [MS-GRVHENC], [MSGRVWDPP], [MS-GRVDYNM], [MS-GRVRDB], [MS-GRVSPCM], and [MS-GRVSPMR].
5 References
[IANAPORT] Internet Assigned Numbers Authority, "Port Numbers", November 2006, http://www.iana.org/assignments/port-numbers. [MSDN-GWSDF] Microsoft Corporation, "Microsoft Office Groove 2007 Web Services Developer Reference", http://msdn.microsoft.com/en-us/library/bb403118.aspx.
25 of 28
[MS -GRVPROT] - v1.0 Groove Protocols Overview Copyright © 2008 M icrosoft Corporation. Release: Friday, June 27, 2008
[MSFT-GPKI] Microsoft Corporation, "About Enterprise vs. Groove PKI", http://technet.microsoft.com/en-us/library/cc262345.aspx. [MS-GLOS] Microsoft Corporation, "Windows Protocols Master Glossary", June 2008. [MS-GRVDYNM] Microsoft Corporation, "Groove Dynamics Protocol Specification", June 2008. [MS-GRVHENC] Microsoft Corporation, "HTTP Encapsulation of Simple Symmetric Transport Protocol (SSTP) Protocol Specification", June 2008. [MS-GRVRDB] Microsoft Corporation, "Groove RDB Commands Protocol Specification", June 2008. [MS-GRVSPCM] Microsoft Corporation, "Client to Management Server Groove SOAP Protocol Specification", June 2008. [MS-GRVSPMR] Microsoft Corporation, "Management Server to Relay Server Groove SOAP Protocol Specification", June 2008. [MS-GRVSSTP] Microsoft Corporation, "Simple Symmetric Transport Protocol (SSTP) Specification", June 2008. [MS-GRVSSTPS] Microsoft Corporation, "Simple Symmetric Transport Protocol (SSTP) Security Protocol Specification", June 2008. [MS-GRVWDPP] Microsoft Corporation, "Wide Area Network Device Presence Protocol (WAN DPP) Specification", June 2008. [MS-OFSGLOS] Microsoft Corporation, "Microsoft Office Server Master Glossary", June 2008. [RFC1631] Egevang, K. and Francis, P., "The IP Network Address Translator (NAT)", RFC 1631, May 1994, http://www.ietf.org/rfc/rfc1631.txt. [RFC1928] Leech, M., "SOCKS Protocol Version 5", RFC1928, March 1996, http://tools.ietf.org/html/rfc1928. [RFC2251] Wahl, M., Howes, T., and Kille, S., "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997, http://www.ietf.org/rfc/rfc2251.txt. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000, http://www.ietf.org/rfc/rfc2818.txt. [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001, http://www.ietf.org/rfc/rfc2821.txt. [RFC4559] Jaganathan, K., Zhu, L., and Brezak, J., "SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows", RFC 4559, June 2006, http://www.ietf.org/rfc/rfc4559.txt.
26 of 28
[MS -GRVPROT] - v1.0 Groove Protocols Overview Copyright © 2008 M icrosoft Corporation. Release: Friday, June 27, 2008
[SOAP1.1] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., Mendelsohn, N., Nielsen, H. F., Thatte, S., and Winer, D., "Simple Object Access Protocol (SOAP) 1.1", May 2000, http://www.w3.org/TR/2000/NOTE-SOAP-20000508/. [TCPPROXY] Luotonen, A., "Tunneling TCP based protocols through Web proxy servers", February 1998, http://tools.ietf.org/html/draft-luotonen-web-proxy-tunneling-00. [TECHNET-GPO] Microsoft Corporation, "Windows Server 2003 Group Policy", http://technet2.microsoft.com/windowsserver/en/technologies/featured/gp/default.mspx.
6 Appendix A: P roduct Behavior
The information in this specification is applicable to the following Microsoft products and technologies: Microsoft® Office Groove® Server 2007 Service Pack 1 (SP1) Microsoft® Office Groove® 2007 Service Pack 1 (SP1)
Exceptions, if any, are noted below. Unless otherwise specified, any statement of optional behavior in this specification prescribed using the terms SHOULD or SHOULD NOT implies the aforementioned Microsoft products' behavior is in accordance with the SHOULD or SHOULD NOT prescription. Unless otherwise specified, the term MAY implies these Microsoft products do not follow the prescription.
Microsoft® Office Groove® Server 2007 is a set of three separately installed server software components: Microsoft Office Groove Server 2007 Data Bridge Microsoft Office Groove Server 2007 Manager Microsoft Office Groove Server 2007 Relay
The following table maps the generic names used in this document to the specific Office Groove Server and client components. Generic Name management server Product or Product Component Name Microsoft Office Groove Server 2007 Manager SP 1 Microsoft Office Groove Server 2007 Manager
27 of 28
[MS -GRVPROT] - v1.0 Groove Protocols Overview Copyright © 2008 M icrosoft Corporation. Release: Friday, June 27, 2008
Generic Name relay server data bridge server client
Product or Product Component Name Microsoft Office Groove Server 2007 Relay SP 1 Microsoft Office Groove Server 2007 Relay Microsoft Office Groove Server 2007 Data Bridge SP 1 Microsoft Office Groove Server 2007 Data Bridge Microsoft Office Groove 2007 SP 1 Microsoft Office Groove 2007
7 Index
C Client, Groove, 9 D Definitions, 5 Diagrams: composite view, 20; logical dependency view, 19; stack view, 17 E Examples, 20 I Introduction, 4 P Product behavior, 27 Protocol: relationships, 10; security, 15 R References, 25 Relationships, 10 S Scenarios, 20 Security, 15 Servers: data bridge, 8; management, 6; relay, 7 System architecture, 6
28 of 28
[MS -GRVPROT] - v1.0 Groove Protocols Overview Copyright © 2008 M icrosoft Corporation. Release: Friday, June 27, 2008