Microsoft Windows CE 3.0 Support of PPP and PPTP

  • Article

Microsoft Corporation

September 2000

Summary: This paper defines the Point-to-Point (PPP) and Point-to-Point Tunneling Protocol (PPTP) protocols, explains how they are supported in Microsoft Windows CE, and illustrates how to establish an Internet connection that uses PPP or PPTP. (8 printed pages)

Contents

Introduction What Is PPP? What Is PPTP? Differences in Windows CE and Windows 2000 PPP and PPTP Implementations For More Information

Introduction

The Point-to-Point Protocol (PPP) and the Point-to-Point Tunneling Protocol (PPTP), included in the TCP/IP protocol suite, are protocols used for communications over the Internet. PPP is widely used for the transmission of TCP/IP packets over dial-up telephone connections, such as between a computer and the Internet. PPTP supports virtual private networks (VPNs), which enhance the security of communication using the Internet. Microsoft® Windows® CE version 3.0 provides support for both protocols. This paper defines both protocols, explains how they are supported in Windows CE, and illustrates how to establish an Internet connection that uses PPP or PPTP.

What Is PPP?

PPP specifies an industry-standard suite of control protocols that were designed to facilitate communication between two computers through a serial, network, or infrared interface in a dynamically changing network. A Windows CE–based device running Remote Access Service (RAS) uses PPP to package data packets from multiple protocols and forward them to a server over point-to-point links. PPP is an improvement over the Serial Line Internet Protocol (SLIP) in its error detection capability and its ability to handle both synchronous and asynchronous communication. Windows CE supports IP connections that use PPP. The PPP encryption support in Windows CE is configurable between 40 bit and 128 bit.

PPP relies on configuration parameters and peer-to-peer negotiation to determine how a specific PPP connection will be managed. PPP allows two computers that are linked to each other to negotiate specific features of their connection, such as the maximum size of datagrams one peer is willing to accept. Peer-to-peer negotiations occur through packet exchanges between two computers until both computers have agreed on a set of parameters under which the connection will operate. PPP provides a default format for the encapsulation of datagrams, but two peers in a given link can also establish their own guidelines for PPP framing.

PPP in Windows CE

Windows CE 3.0 uses the Network Driver Interface Specification (NDIS) to implement PPP network connections. In the networking architecture, PPP is implemented as an NDIS protocol driver. PPP communicates with the underlying WAN miniport—for example, AsyncMAC—through the NDIS layer. When PPP receives a WAN packet from TCP/IP, it passes the packet on to the AsyncMAC miniport. After receiving a packet from PPP, the AsyncMAC miniport performs the asynchronous framing and then forwards the packet to the TAPI device by calling Win32 serial APIs. When receiving a packet through the network, the AsyncMAC miniport strips the asynchronous framing off the packet, checks the Cyclic Redundancy Check (CRC), and passes the packet up to PPP through the NDIS layer.

Creating a PPP Dial-up Session

To create a PPP dial-up session between a Windows CE–based device and a server device, both computers must complete three distinct phases of negotiation before data can be transferred between the two devices. The three phases of negotiation are:

  • Phase 1: PPP link establishment
  • Phase 2: PPP user authentication
  • Phase 3: Invoking network layer protocols

PPP uses the Link Control Protocol (LCP) to establish, maintain, and end the physical connection. Before information can be sent on a link, each of the two computers that make up the connection must test the link and agree on a set of parameters under which the link will operate.

During the initial phase of LCP, each computer in a given link must specify the desired parameters for a PPP connection in a Configure-Request and submit the request to its peer. If one of the two computers in a link fails to acknowledge the parameters received from its peer, the other computer must resubmit a packet that contains a set of alternate parameters. During the link authentication phase, the two peers also select which authentication protocol will be used during the user authentication phase. The two computers also decide whether they will negotiate the use of compression and/or encryption. The actual choice of compression/encryption algorithms and other details occurs during phase 3.

Phase 2: PPP User Authentication

In the second phase, the client computer presents the user's credentials to the remote access server. A more secure authentication scheme provides protection against replay attacks and remote client impersonation.

Note A replay attack occurs when a third party monitors a successful connection and uses captured packets to play back the remote client's response so that it can gain an authenticated connection. Remote client impersonation occurs when a third party takes over an authenticated connection. The intruder waits until the connection has been authenticated and then traps the conversation parameters, disconnects the authenticated user, and takes control of the authenticated connection.

Most implementations of PPP provide limited authentication methods, typically the Password Authentication Protocol (PAP), Challenge Handshake Authentication Protocol (CHAP), and Microsoft Challenge Handshake Authentication Protocol (MS-CHAP).

  • Password Authentication Protocol. PAP is a simple, clear text authentication scheme. The Network Authentication Server (NAS) requests the user name and password, and PAP returns them in clear text (unencrypted). Obviously, this authentication scheme is not secure because a third party could capture the user name and password and use them to get subsequent access to the NAS and all of the resources provided by the NAS. PAP provides no protection against replay attacks or remote client impersonation once the user's password is compromised.

  • Challenge Handshake Authentication Protocol. CHAP is an encrypted authentication mechanism that avoids transmission of the actual password on the connection. The NAS sends a challenge, which consists of a session ID and an arbitrary challenge string, to the remote client. The remote client must use the MD5 one-way hashing algorithm to return the user name and an encryption of the challenge, session ID, and the client's password. The user name is sent unhashed.

    CHAP is an improvement over PAP in that the clear text password is not sent over the link. Instead, the password is used to create an encrypted hash from the original challenge. The server knows the client's clear text password and can therefore replicate the operation and compare the result to the password sent in the client's response. CHAP protects against replay attacks by using an arbitrary challenge string for each authentication attempt. CHAP protects against remote client impersonation by unpredictably sending repeated challenges to the remote client throughout the duration of the connection.

  • Microsoft Challenge Handshake Authentication Protocol. MS-CHAP is an encrypted authentication mechanism very similar to CHAP. As in CHAP, the NAS sends a challenge, which consists of a session ID and an arbitrary challenge string, to the remote client. The remote client must return the user name and an MD4 hash of the challenge string, the session ID, and the MD4-hashed password. This design, which manipulates a hash of the MD4 hash of the password, provides an additional level of security because it allows the server to store hashed passwords instead of clear text passwords. MS-CHAP also provides additional error codes, including a password expired code, and additional encrypted client-server messages that permit users to change their passwords. In Microsoft's implementation of MS-CHAP, both the client and NAS independently generate an initial key for subsequent data encryption by Microsoft Point-to-Point Encryption (MPPE). The last point is very important, as it explains why MS-CHAP authentication is required to enable MPPE-based data encryption.

  • Microsoft Challenge Handshake Authentication Protocol version 2.0 (MS-CHAPv2). Microsoft Windows CE 3.0 supports MS-CHAP version 2.0, which offers improved security features over MS-CHAP, such as a server authentication scheme and a single change password packet.

During phase 2 of the PPP link configuration, the NAS collects the authentication data and then validates the data against its own user database or against a central authentication database server, such as one maintained by a Windows NT Primary Domain Controller (PDC) or a Remote Authentication Dial-In User Service (RADIUS) server.

Phase 3: Invoking Network Layer Protocols

Once the previous phases have been completed, PPP invokes the various Network Control Protocols (NCPs) that were selected during the link establishment phase (phase 1) to configure protocols used by the remote client. For example, during this phase, the IP Control Protocol (IPCP) can assign a dynamic address to the dial-in user. In Microsoft's implementation of PPP, the Compression Control Protocol is used to negotiate both data compression (using Microsoft Point-to-Point Compression) and data encryption (using MPPE) for the simple reason that both are implemented in the same routine.

Data Transfer

Once the three phases of negotiation have been completed, PPP begins to forward data to and from the client and server. Data is sent by PPP when IP passes it a packet to transmit. Each transmitted data packet is wrapped in a PPP header, which is removed by the receiving computer. If data compression was selected in phase 1 and negotiated in phase 3, data will be compressed before transmission. If data encryption was similarly selected and negotiated, the data (optionally compressed) will be encrypted before transmission. PPP then passes the packet to the miniport driver—for example, AsyncMac—which performs appropriate framing and transmits it to the physical layer. Packet reception is done using these same steps in reverse order.

What Is PPTP?

PPTP is a network protocol that helps to transfer data securely from a remote client to a private enterprise server, thus creating a virtual private network (VPN ) by using TCP/IP-based data networks. PPTP supports multiple network protocols and can be used for virtual private networking over public and private networks. PPTP can be used to provide on-demand, virtual networks with enhanced security by using dial-up lines, local area networks (LANs), wide area networks (WANs), or the Internet and other public TCP/IP-based networks.

A VPN can be defined as an on-demand connection between two computers in different locations. It consists of the two computers (one computer at each end of the connection) and a route, or tunnel, over a public or private network. To enhance privacy and secure communication, data transmitted between the two computers is encrypted by PPP. To implement data encryption, one of the two authentication schemes—MS-CHAP or MS-CHAPv2—is required, both of which are supported by Windows CE 3.0.

The encrypted data is routed over a dial-up or LAN connection by a PPTP device. This device is referred to as a virtual private network or VPN. PPTP uses the VPN device to establish and help maintain private, secure communication between computers. It does this by using RAS and dial-up networking to communicate over dial-up lines and public or private networks.

PPTP in Windows CE

A Windows CE–based PPTP-client device can connect to a PPTP server in two ways:

  • The PPTP client can dial up to the network access server of an Internet service provider (ISP) that supports inbound PPP connections.
  • The PPTP client can connect to a PPTP server by using a physical TCP/IP-enabled LAN connection.

PPTP clients that use an ISP network access server must be configured with a modem and a VPN device to make the separate connections to the ISP and the PPTP server. The PPTP client first establishes a dial-up connection to an ISP over a modem using PPP. The client device then establishes a VPN connection using PPTP, over the modem and the ISP connection, to tunnel across the Internet to a VPN device on the PPTP server. The second connection requires the first connection because the tunnel between the VPN devices is established using the modem and PPP connection to the Internet.

The exception to this two-connection requirement is using PPTP to create a VPN between computers that are physically connected to the private enterprise network LAN. In this scenario, a PPTP client is already connected to the network and only uses dial-up networking with a VPN device to create the connection to a PPTP server on the LAN.

In the Windows CE networking architecture, the PPTP WAN miniport communicates directly with TCP/IP. After receiving a packet that is addressed to the private network from TCP/IP, PPP performs the framing and then forwards the packet to the PPTP WAN miniport. The PPTP WAN miniport encapsulates the information contained in the packet header and then reroutes the packet back to TCP/IP. IP then attaches another header that contains the address of the PPTP server to the packet and passes the packet on to PPP. PPP forwards the packet to either the AsyncMAC WAN miniport or a LAN adapter, such as an NE2000 adapter. After receiving the packet over the network, the PPTP server strips the IP header off the packet and routes the packet to the private network.

Establishing a PPTP Connection

To establish a PPTP connection

  1. Fill out the RASENTRY structure to create a PPTP connectoid.

    When filling out the RASENTRY structure, fill out the szDeviceType, szLocalPhoneNumber, and szDeviceName fields with these PPTP-specific values:

    Field Value Description
    szDeviceType RASDT_VPN Connection through a VPN
    szLocalPhoneNumber Example:"1.2.3.4" or "MyPPTPServerName" Host name or IP address of PPTP server
    szDeviceName RAS VPN Line 0 Name of the line device

    Fill out all the remaining fields in the RASENTRY structure as shown in the RASENTRY API Reference page.

  2. Call the RasSetEntryProperties function to set the properties for the connectoid.

  3. To establish a PPTP connection, call the RasDial function. When you call RasDial, the RASDIALPARAMS structure is passed in. One of the fields of RASDiALPARAMS is szentryname, which is the name of the PPTP connectoid.

Differences in Windows CE and Windows 2000 PPP and PPTP Implementations

  • The Windows CE implementation of PPP and PPTP provides a subset of features provided in the Windows 2000 implementation of PPP and PPTP.
  • Unlike Windows 2000, Windows CE does not support multilink PPP.
  • Windows CE does not support NetBEUI and IPX.
  • In Windows CE, PPP talks to the AsyncMAC miniport, and the AsyncMAC miniport performs MAC layer framing. In Windows 2000, MAC layer framing is performed by the NDISWAN extension library.
  • Windows CE now supports the MS-CHAPv2, but the user interface (UI) does not let the user change the password if it has expired.
  • Unlike Microsoft Windows 2000, which supports the client as well as the server side of PPTP, Windows CE only provides client support for PPTP.
  • By default, Windows CE only supports a single VPN connection. The OEM can set up the PPTP support of a Windows CE–based device, so that more than one connection is possible.
  • The Networking User Interface supported in Windows CE differs from the network UI implemented in Windows 2000. Windows CE provides a relatively simple UI that offers only a few options that can be set by the user. Underneath the UI, Windows CE supports a number of settings that developers can configure through the registry.

For More Information

For detailed information on developing distributed applications that incorporate PPP and PPTP functionality, see the Microsoft Platform SDK documentation. For information specific to developing applications on Windows CE–based platforms, see the SDK documentation for your target platform.

---------------------------------------------

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, AS TO THE INFORMATION IN THIS DOCUMENT.

Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

© 2000 Microsoft Corporation. All rights reserved.

Microsoft, Win32, Windows, and Windows NT are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

The names of actual companies and products mentioned herein may be the trademarks of their respective owners.