Dial-up remote access uses PPP, a data link layer protocol that uses network layer protocols, including TCP/IP and AppleTalk, to transmit data across a WAN infrastructure.
This section describes PPP and the following protocols and methods that are part of the process when using PPP.
PPP encapsulation uses a variant of the International Organization for Standardization (ISO) High-Level Data Link Control (HDLC) protocol to encapsulate multiprotocol datagrams as the payload of PPP frames. The PPP header and trailer are shown in the following figure.
PPP Encapsulation
The fields are described as follows:
- Flag - Set to 0x7E (bit sequence 011111110) to signify the beginning and end of a PPP frame. In successive PPP frames, only a single Flag character is used.
Note
-
The Flag character must not occur in the middle of the PPP frame. Character stuffing and bit stuffing are used to ensure that the Flag character occurs at the beginning and the end of the frame. For more information, see “Dial-up Remote Access Processes and Interactions” later in this section.
- Address - In HDLC environments, the Address field is used to address the frame to the destination node. On a point-to-point link, the destination node does not need to be addressed. Therefore, for PPP, the Address field is set to 0xFF, the broadcast address. If both PPP peers agree to perform address and control field compression during LCP negotiation, the Address field is not included.
- Control - In HDLC environments, the Control field is used for data-link layer sequencing and acknowledgments. PPP does not provide link-to-link reliable data transfer. Therefore, for all PPP frames, the Control field is set to 0x03 to indicate an unnumbered information frame. If both PPP peers agree to perform address and control field compression during LCP negotiation, the Control field is not included.
- Protocol ID - The 2-byte Protocol ID field identifies the protocol of the PPP payload. If both PPP peers agree to perform protocol field compression during LCP negotiation, the Protocol ID field is one byte for Protocol IDs in the range of 0x00-00 to 0x00-FF.
- PPP Payload - An encapsulation of IP datagrams or AppleTalk datagrams.
- Frame Check Sequence (FCS) - A 16-bit checksum that is used to check for bit-level errors in the PPP frame. If the receiver’s calculation of the FCS does not match the FCS in the PPP frame, the PPP frame is silently discarded.
The maximum size of a PPP frame, known as the maximum receive unit (MRU), is determined during the negotiation of the logical link. The default MRU is 1,500 bytes. If the MRU is negotiated lower than 1,500 bytes, a PPP host must still have the ability to receive 1,500-byte frames in the event of link synchronization failure.
The following table lists typical values for the PPP Protocol ID.
PPP Protocol IDs
|
Protocol
|
Protocol ID/Compressed Value
|
|---|
IP | 0x00-21 / 0x21 |
AppleTalk | 0x00-29 / 0x29 |
Van Jacobsen Compressed TCP/IP | 0x00-2D / 0x2D |
Multilink | 0x00-3D / 0x3D |
Microsoft Point-to-Point Compression Protocol (MPPC) | 0x00-FD / 0xFD |
Microsoft Point-to-Point Encryption Protocol (MPPE) | 0x00-FD / 0xFD |
If MPPE or MPPC are negotiated, then the PPP Protocol ID is set to 0x00-FD. With MPPE and MPPC both using the same PPP Protocol ID, each peer must know that the resulting PPP payload either is encrypted or compressed, or both.
-
If only MPPC is negotiated, then the PPP Protocol ID is set to 0x00-FD and the PPP payload is compressed.
-
If only MPPE is negotiated, then the PPP Protocol ID is set to 0x00-FD and the PPP payload is encrypted.
-
If both MPPC and MPPE are negotiated, then compression always occurs before encryption. The compressed PPP frame, consisting of the PPP protocol ID field set to 0xFD and the compressed data, is then encrypted and encapsulated with another PPP header consisting of the protocol ID field set to 0xFD and a 2-byte MPPE header.
PPPoE
PPPoE (PPP over Ethernet) is a method of encapsulating PPP frames so that they can be sent over an Ethernet network. PPPoE was created so that Internet service providers (ISPs) that deploy a broadband Internet access technology in a bridged Ethernet topology, such as cable modems or Digital Subscriber Line (DSL), can use the per-user authentication and connection identification facilities of PPP to identify individual customer connections for accounting and billing purposes. For more information about PPPoE, see RFC 2516.
The following figure shows a PPPoE frame.
PPPoE Frame Structure
The following are the fields in the PPPoE frame:
- Preamble - An 8-byte field that consists of 7 bytes of alternating 1s and 0s (each byte is the bit sequence 10101010) to synchronize a receiving station and a 1-byte 10101011 sequence that indicates the start of a frame. The Preamble provides receiver synchronization and frame delimitation services.
- Destination Address - A 6-byte field that indicates the destination’s address. The destination can be a unicast, a multicast, or the Ethernet broadcast address. The unicast address is also known as an individual, physical, hardware, or media access control (MAC) address. For the Ethernet broadcast address, all 48 bits are set to 1 to create the address 0xFF-FF-FF-FF-FF-FF.
- Source Address - A 6-byte field that indicates the sending node’s unicast address.
- EtherType - The Ethernet II header for PPPoE frames. EtherType is set to 0x88-63 for PPPoE discovery frames and 0x88-64 for PPP session frames. For more information about Ethernet II, see RFC 894.
- Version - A 4-bit field that is set to the value of 1.
- Type - A 4-bit field that is set to the value of 1.
- Code - A 1-byte field that is used to identify the type of PPPoE message. There are defined values for the PPPoE frames exchanged during the discovery phase. For PPP session frames, the Code field is set to 0.
- Session_ID - A 2-byte field that identifies the PPPoE session ID. This field is set to 0 until a session ID is negotiated with the access concentrator (AC) during the discovery phase of the PPPoE connection.
- Length - A 2-byte field that is used to indicate the size, in bytes, of the PPPoE payload.
- PPPoE Payload - A variable-sized payload that can contain either one or more PPPoE tags for PPPoE frames sent during the discovery phase or PPP frames for the PPP session phase. PPPoE tags are information elements in type-length-value (TLV) format. Typical PPPoE tags used during the discovery phase are Service-Name (the name of the ISP or service offered by the AC) and AC-Name (the name of the AC). For a complete list of PPPoE tags and their structure, see RFC 2516.
- Frame Check Sequence (FCS) - A 4-byte field that provides bit-level integrity verification on the bits in the Ethernet II frame. The FCS is also called a cyclical redundancy check (CRC). The source node calculates the FCS and places the result in this field. When the destination receives the FCS, it runs the same CRC algorithm and compares its own value with the one placed in the FCS field by the source node. If the two values match, the frame is considered valid and the destination node processes it. If the two values do not match, the frame is silently discarded.
For more information about the PPPoE connection process, see “Dial-up Remote Access Processes and Interactions” later in this section.
LCP (Link Control Protocol) negotiates link and PPP parameters to dynamically configure the data link layer of a PPP connection. Common LCP options include the PPP MRU, the authentication protocol, compression of PPP header fields, callback, and multilink options. For more information about LCP, see RFC 1661.
LCP Packet Structure
LCP uses the PPP Protocol ID of 0xC0-21. The packet structure of LCP is illustrated in the following figure. Each LCP packet is a single LCP message that consists of an LCP Code field identifying the type of LCP packet; an Identifier field so that requests and replies can be matched; a Length field indicating the size of the LCP packet; and LCP packet type-specific data.
LCP Packet Structure
The following table lists the LCP packet types.
LCP Packet Types
|
LCP Code
|
LCP Packet Type
|
Description
|
|---|
1 | Configure-Request | Sent to open or reset a PPP connection. Configure-Request contains a list of LCP options with changes to default option values. |
2 | Configure-Ack | Sent when all of the values of all of the LCP options in the last Configure-Request received are recognized and acceptable. When both PPP peers send and receive Configure-Acks, the LCP negotiation is complete. |
3 | Configure-Nack | Sent when all the LCP options are recognized, but the values of some options are not acceptable. Configure-Nack includes the offending options and their acceptable values. |
4 | Configure-Reject | Sent when LCP options are not recognized or not acceptable for negotiation. Configure-Reject includes the unrecognized or non-negotiable options. |
5 | Terminate-Request | Optionally sent to close the PPP connection. |
6 | Terminate-Ack | Sent in response to the Terminate-Request. |
7 | Code-Reject | Sent when the LCP code is unknown. The Code-Reject message includes the offending LCP packet. |
8 | Protocol-Reject | Sent when the PPP frame contains an unknown Protocol ID. The Protocol-Reject message includes the offending LCP packet. Protocol-Reject is typically sent by a PPP peer in response to a PPP NCP for a local area network (LAN) protocol not enabled on the PPP peer. |
9 | Echo-Request | Optionally sent to test the PPP connection. |
10 | Echo-Reply | Sent in response to an Echo-Request. The PPP Echo-Request and Echo-Reply are not related to the Internet Control Message Protocol (ICMP) Echo Request and Echo Reply messages. |
11 | Discard-Request | Optionally sent to exercise the link in the outbound direction. |
LCP Options
When using the Configure-Request, Configure-Ack, Configure-Nack, and Configure-Reject LCP packet types, the LCP data portion of the LCP packet consists of one or more LCP options, as illustrated in the following figure. Each LCP option consists of an option Type field; a Length field indicating the total length, in bytes, of the option; and the data associated with the option.
LCP Options
The following table lists common LCP options negotiated by Microsoft PPP peers.
LCP Options
|
Option Name
|
Option Type
|
Option Length
|
Description
|
|---|
Maximum Receive Unit (MRU) | 1 | 4 | The maximum size (up to 65,535) of the PPP frame. The default MRU is 1,500. If neither peer is changing the default, this option is not negotiated. |
Asynchronous Control Character Map (ACCM) | 2 | 6 | A bit map that enables (bit set to 1) or disables (bit set to 0) the use of character escapes for asynchronous links for the 32 ASCII control characters from 0x00 to 0x20. By default, character escapes are used. The ACCM bit map is set to 0x00-00-00-00 for links with XON/XOFF software flow control. |
Authentication Protocol | 3 | 5 or 6 | Indicates the authentication protocol used during the authentication phase of the connection. Values for this field for Microsoft PPP peers are 0xC2-27 for Extensible Authentication Protocol (EAP); 0xC2-23-80 for Microsoft Challenge Handshake Authentication Protocol version 1 (MS-CHAP); 0xC2-23-81 for MS-CHAP version 2; 0xC2-23-05 for Message Digest 5 Challenge Handshake Authentication Protocol (MD5-CHAP); 0xC0-27 for Shiva Password Authentication Protocol (SPAP); and 0xC0-23 for PAP. |
Magic Number | 5 | 6 | A random number chosen to distinguish a peer and detect looped back lines. |
Protocol Compression | 7 | 2 | A flag indicating that the PPP Protocol ID be compressed to a single octet when the 2-byte Protocol ID is in the range of 0x00-00 to 0x00-FF. |
Address and Control Field Compression | 8 | 2 | A flag indicating that the PPP Address field (always set to 0xFF) and the PPP Control field (always set to 0x03) must be removed from the PPP header. |
Callback | 13 or 0x0D | 3 | A 1-octet indicator of how callback is to be determined. For remote access clients and servers running Microsoft Windows 32-bit operating systems, the callback option octet is set to 0x06, indicating that the callback is determined during Callback Control Protocol (CBCP) negotiation. |
After the link and PPP parameters have been negotiated with LCP, the PPP peers then use a series of NCPs (Network Control Protocols) to negotiate the parameters of individual LAN protocols. Microsoft PPP supports the NCPs listed in the following table.
Network Control Protocols
|
Protocol
|
Description
|
|---|
IPCP | IPCP negotiates the use of IP. |
ATCP | ATCP negotiates the use of AppleTalk. |
Compression Control Protocol (CCP) | CCP packets are exchanged to configure MPPC (Microsoft Point-to-Point Compression Protocol) and MPPE (Microsoft Point-to-Point Encryption Protocol). |
BACP (Bandwidth Allocation Control Protocol) | Working with MP (Multilink Protocol) and BAP (Bandwidth Allocation Protocol), BACP elects a favored peer in case both PPP peers request to add or remove a connection at the same time. |
IPCP
IPCP (Internet Protocol Control Protocol) as used by Microsoft PPP peers is documented in RFC 1332 and RFC 1877. IPCP negotiates IP-based parameters to dynamically configure a TCP/IP-based PPP peer across a point-to-point link. Common IPCP options include an IP address and the IP addresses of Domain Name System (DNS) servers.
Packet Structure
IPCP uses the PPP Protocol ID of 0x80-21. The packet structure of IPCP is exactly the same as LCP, except only packet types 1 through 7 are defined. For Configure-Request, Configure-Ack, Configure-Nack, and Configure-Reject IPCP packet types, the IPCP data portion of the IPCP packet consists of one or more IPCP options. Each IPCP option consists of an Option Type field; an Option Length field indicating the total length, in bytes, of the option; and the data associated with the option.
Negotiated Options
The following table lists the IPCP options negotiated by Microsoft PPP peers.
IPCP Options
|
Option Name
|
Option Type
|
Option Length
|
Description
|
|---|
IP compression protocol | 2 | 4 | The Van Jacobsen TCP compression protocol. |
IP address | 3 | 6 | The IP address to be allocated to the remote access client. |
Primary DNS server address | 129 or 0x81 | 6 | The primary DNS server for the remote access client. |
Primary NBNS server address | 130 or 0x82 | 6 | The primary NBNS (WINS) server for the remote access client. |
Secondary DNS server address | 131 or 0x83 | 6 | The secondary DNS server for the remote access client. |
Secondary NBNS server address | 132 or 0x84 | 6 | The secondary NBNS (WINS) server for the remote access client. |
There are no IPCP options for these common TCP/IP configuration items:
-
Subnet mask
The subnet mask is assumed by the remote access client to be the class-based subnet mask of the IP address that is allocated to the remote access client.
-
Default gateway
The default gateway IP address is not allocated by the remote access server. However, a default route is created on the remote access client, which points to the remote access connection. If a default route already exists in the routing table, then the metric of the existing default route is increased and a new default route is added with a lower metric. This is the default behavior for remote access clients running Windows 32-bit operating systems. This behavior can be modified by disabling the UseDefault Gateway on Remote Network setting on the TCP/IP properties of a remote access client’s phone book entry or dial-up connection object.
-
DNS domain name
The DNS domain name configured from the TCP/IP protocol properties on the remote access server is not negotiated during IPCP. For Windows Server 2003 remote access clients, the DNS domain name can be obtained through a DHCPInform message. For more information, see “TCP/IP Configuration for Remote Access Clients” later in this section.
ATCP
ATCP (AppleTalk Control Protocol) as used by Microsoft PPP peers is documented in RFC 1378. ATCP negotiates AppleTalk-based parameters to dynamically configure an AppleTalk-based PPP peer across a point-to-point link. Common ATCP options include AppleTalk address and server information.
Packet Structure
ATCP uses the PPP Protocol ID of 0x80-29. The packet structure of ATCP is exactly the same as the packet structure for LCP, except that only packet types 1 through 7 are defined. For Configure-Request, Configure-Ack, Configure-Nack, and Configure-Reject ATCP packet types, the ATCP data portion of the ATCP packet consists of one or more ATCP options. Each ATCP option consists of an option Type field; an option Length field indicating the total length, in bytes, of the option; and the data associated with the option.
Negotiated Options
The following table lists the ATCP options negotiated by Microsoft PPP peers.
ATCP Options
|
Option Name
|
Option Type
|
Option Length
|
Description
|
|---|
AppleTalk Address | 1 | 6 | Negotiates the AppleTalk network and node numbers. |
Server Information | 3 | 16 | Used to convey information about the remote access server. |
CCP
CCP (Compression Control Protocol) is documented in RFC 1962. CCP negotiates parameters to dynamically configure, enable, and disable data compression algorithms between PPP peers across a point-to-point link. Common CCP options include an organization identifier and the use of MPPC.
Packet Structure
CCP uses the PPP Protocol ID of 0x80-FD. The packet structure of CCP is exactly the same as the packet structure for LCP, except only packet types 1 through 7 are defined. For Configure-Request, Configure-Ack, Configure-Nack, and Configure-Reject CCP packet types, the CCP data portion of the CCP packet consists of one or more CCP options. Each CCP option consists of an option Type field; an option Length field indicating the total length, in bytes, of the option; and the data associated with the option.
Negotiated Options
The following table lists the CCP options negotiated by Microsoft PPP peers.
CCP Options
|
Option Name
|
Option Type
|
Option Length
|
Description
|
|---|
Organization Unique Identifier | 0 | 6 or larger | Used to negotiate an organization’s proprietary compression protocol. |
MPPC | 18 or 0x12 | 6 | Used to indicate the use of MPPC, MPPE, and the encryption strength. |
MPPE and MPPC
With CCP option 18, Microsoft PPP peers negotiate both MPPC and MPPE at the same time. The option data field for CCP option 18 is 4 bytes (32 bits) long. Bits within this data field are used as flags to indicate:
-
Whether compression is enabled (0x00-00-00-01).
-
Whether 40-bit session keys are derived from the LAN Manager version of the user’s password (0x00-00-00-10).
-
Whether 40-bit session keys are derived from the Windows NT version of the user’s password (0x00-00-02-00).
-
Whether 56-bit session keys are derived from the Windows NT version of the user’s password (0x00-00-00-80).
-
Whether 128-bit session keys are derived from the Windows NT version of the user’s password (0x00-00-00-40).
-
Whether the encryption keys are refreshed with each PPP frame (0x01-00-00-00).
For multiple choices, the flag values are added together. For example, for compression (0x00-00-00-01) and 128-bit encryption keys (0x00-00-00-40), the resulting 32-bit option data field is set to 0x00-00-00-41.
Note
-
The Encryption Control Protocol (ECP) is used to negotiate a specific encryption method and is documented in RFC 1968. However, for Microsoft PPP peers, the only supported encryption is MPPE, which is negotiated during CCP with the negotiation of MPPC. Therefore, Microsoft PPP peers do not use ECP.
Windows Server 2003 remote access supports the Multilink protocols listed in the following table.
Multilink Protocols
|
Protocol
|
Description
|
|---|
MP | Allows multiple physical links to appear as a single logical link over which data can be sent and received. |
BAP | Used to dynamically add or remove additional links to an MP connection. |
BACP | Elects a favored peer in case both PPP peers request to add or remove a connection at the same time. |
MP
MP is defined in RFC 1990 and used to aggregate multiple physical links into a single logical link. A good example is the aggregation of both B-channels of an ISDN Basic Rate Interface (BRI) connection. MP fragments, sequences, and re-orders alternating packets sent across multiple physical connections so that the end result is a single logical link with the combined bandwidth of all of the aggregated physical links. MP is the recommended method of combining multiple B-channels of a BRI connection because the support for bonding, the combining of ISDN B-channels through hardware support, can be specific to the ISDN adapter. MP can be used for any ISDN adapter. MP must be supported on both sides of the connection.
The following figure illustrates the structure of an MP frame. The payload of a Multilink PPP packet is either a fragment of a PPP frame or the entire PPP frame. Multilink PPP fragmentation need not occur if the Multilink PPP packet fits within the MRU of the link. To prevent incorrect ordering of the datagrams or fragments across multiple links, additional fields are used between the PPP Protocol field and the IP datagram. Multilink PPP uses the PPP Protocol ID of 0x00-3D.
Multilink PPP
RFC 1717 defines two different packet formats for short sequence numbers and long sequence numbers. The sequence number is used to prevent the misordering of frames that are sent across multiple links, not to sequence fragments.
For short sequence numbers, a two-byte Delimitation/Sequence # field consists of four bits used for delimitation and 12 bits used for the sequence number. Within the delimitation field are two flags. The first bit (the Beginning bit) is an indicator that this fragment begins a sequence of fragments corresponding to a packet. The second bit (the Ending bit) is an indicator that this fragment ends a sequence of fragments corresponding to a packet. The other bits in the first four bits of the short sequence number header are set to 0.
For a PPP frame that is sent without fragmentation, both the Beginning and Ending bits are set. For a PPP frame that is larger than the MRU of the physical link, the PPP frame is fragmented, and each fragment is sent as a separate PPP packet. MP performs a data-link layer fragmentation that is not related to IP fragmentation.
For long sequence numbers, a four-byte Delimitation/Sequence # field consists of eight bits (one byte) used for delimitation, and 24 bits (3 bytes) used for the sequence number. Within the delimitation field, the same bits as the short sequence number header define the Beginning bit and the Ending bit. The other bits in the first byte of the long sequence number header are set to 0. The long sequence number header is used by default, unless the short sequence number is chosen during LCP negotiation.
The following table lists Multilink LCP options negotiated by Microsoft PPP peers. For information about other Multilink options, see RFC 1990.
Multilink LCP Options
|
Option Name
|
Option Type
|
Option Length
|
Description
|
|---|
Multilink Maximum Receive Reconstructed Unit | 17 or 0x11 | 4 | Specifies the number of octets that a peer can reconstruct when performing reassembly of fragmented MP frames. |
Short Sequence Number Header Format | 18 or 0x12 | 2 | Specifies the use of the short sequence number in the MP header. |
Multilink Endpoint Discriminator | 19 or 0x13 | 9 | A unique system identifier to differentiate links from two PPP peers with the same authenticated name. |
BAP
Although MP allows for multiple physical links to be aggregated, MP does not provide a mechanism to adapt to changing conditions by adding extra links when needed or terminating extra links when unneeded. This additional capability is provided by BAP and BACP, as defined in RFC 2125. BAP is a PPP control protocol that is used on an MP connection to dynamically manage links. BAP uses the PPP Protocol of ID 0xC0-2D.
For example, an MP and BAP-enabled remote access client and remote access server create an MP connection consisting of a single physical link. As the use of the single link rises to a configured level, the remote access client uses a BAP Call-Request message to request an additional link. The BAP Call-Request message specifies the type of link desired, such as analog phone, ISDN, or X.25. The remote access server then sends a BAP Call-Response message that contains the phone number of an available port on the remote access server of the same type specified by the remote access client in the BAP Call-Request.
When use on the second link drops to a specified level, either the remote access client or the remote access server can send a BAP Link-Drop-Query-Request message to drop the link.
BAP also supports a Callback-Request message in which the requesting peer specifies the link type and the number to call back. For more information about BAP messages, see RFC 2125.
The following table lists the BAP LCP option negotiated by Microsoft PPP peers.
BAP LCP Option
|
Option Name
|
Option Type
|
Option Length
|
Description
|
|---|
BAP Link Discriminator | 23 or 0x17 | 4 | A unique number used to identify a link in a Multilink PPP connection. |
BACP
BACP is a PPP NCP that negotiates a single option: the election of a favored peer. If both peers of an MP and BAP-enabled connection send BAP Call-Request or BAP Link-Drop-Query-Request messages at the same time, the favored peer is the peer whose requests are implemented.
BACP uses the PPP Protocol ID of 0xC0-2B. The packet structure of BACP is exactly the same as the packet structure for LCP, except that only packet types 1 through 7 are defined. For Configure-Request, Configure-Ack, Configure-Nack, and Configure-Reject BACP packet types, the BACP data portion of the BACP packet consists of the single BACP Favored-Peer option listed in the following table.
BACP Favored Peer Option
|
Option Name
|
Option Type
|
Option Length
|
Description
|
|---|
Favored-Peer | 1 | 6 | A randomly allocated 4-byte magic number used to elect a favored BAP peer. The favored peer is the peer with the lowest magic number. |
After both PPP peers agree on a single, specific PPP authentication protocol, authentication for PPP is accomplished through that protocol.
Windows Server 2003 remote access supports the PPP authentication protocols listed in the following table.
PPP Authentication Protocols
|
Protocol
|
Description
|
Security Level
|
|---|
PAP ( Password Authentication Protocol) | Uses plaintext passwords. It is typically negotiated if the remote access client and remote access server cannot negotiate a more secure form of validation. | The least secure authentication protocol. Does not protect against replay attacks, remote client impersonation, or remote server impersonation. |
SPAP (Shiva Password Authentication Protocol) | A reversible encryption mechanism employed by Shiva remote access servers. | More secure than PAP, but less secure than CHAP or MS-CHAP. Does not protect against remote server impersonation. |
CHAP (Challenge Handshake Authentication Protocol) | A challenge-response authentication protocol that uses the industry-standard Message Digest 5 (MD5) hashing scheme to encrypt the response. | An improvement over PAP and SPAP in that the password is not sent over the PPP link. Requires a plaintext version of the password to validate the challenge response. Does not protect against remote server impersonation. |
MS-CHAP (Microsoft Challenge Handshake Authentication Protocol version 1) | A nonreversible, encrypted password authentication protocol that is similar to CHAP. | More secure than CHAP. Requires an MD4 hash of the password to validate the challenge response. Does not protect against remote server impersonation |
MS-CHAP v2 (Microsoft Challenge Handshake Authentication Protocol version 2) | An upgrade of MS-CHAP. | Provides stronger security than MS-CHAP. A comparison of MS-CHAP and MS-CHAP v2 features appears later in this section. |
EAP (Extensible Authentication Protocol) | Allows for arbitrary authentication of a remote access connection through the use of authentication schemes known as EAP types. | Offers the strongest security by providing the most flexibility in authentication variations. |
For information about authentication processes for PPP authentication protocols, see “Dial-up and Remote Access Processes and Interactions” later in this section.
PAP
PAP is included in Windows Server 2003 so that:
-
Remote access clients running Windows 32-bit operating systems can connect to older remote access servers that do not support a secure authentication protocol
-
Remote access clients running Microsoft operating systems that do not support a secure remote access protocol can connect to remote access servers running Windows 32-bit operating systems.
Note
-
To make your remote access server more secure, ensure that PAP is disabled. As a consequence, however, older remote access clients not running Microsoft operating systems that do not support secure authentication protocols will be unable to connect.
SPAP
A Windows Server 2003 remote access client can use SPAP to authenticate itself to a Shiva remote access server. A remote access client running Windows 32-bit operating systems can use SPAP to authenticate itself to a Windows Server 2003 remote access server.
CHAP
CHAP is used by vendors of dial-in servers and clients. CHAP is supported by both the Windows Server 2003 remote access server and remote access client.
CHAP protects against replay attacks by using an arbitrary challenge string per authentication attempt. Instead of sending the password over the link, the password is used to create a one-way hash from a challenge string. The server, knowing the client’s password, can duplicate the operation and compare the result with that sent in the client’s response.
CHAP requires that local or domain passwords are stored in a reversibly encrypted form.
MS-CHAP
As in CHAP, the remote access server sends a challenge that 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.
One difference between CHAP and MS-CHAP is that, in CHAP, the plaintext version of the password must be available to validate the challenge response. With MS-CHAP, the remote access server requires only the MD4 hash of the password to validate the challenge response. In Windows Server 2003, the user’s password is stored as an MD4 hash and in a reversibly encrypted form. When CHAP is used, the remote access server decrypts the reversibly encrypted password to validate the remote access client’s response.
MS-CHAP also allows for error codes including a “password expired” code and password changes. MS-CHAP protects against replay attacks by using an arbitrary challenge string per authentication attempt.
If MS-CHAP is used as the authentication protocol and MPPE is negotiated, then shared secret encryption keys are generated by each PPP peer. MS-CHAP also provides a set of messages that allows a user to change the password during the user authentication process.
MS-CHAP v2
Windows Server 2003 includes support for MS-CHAP v2, which provides stronger security for remote access connections. The following table compares the security features of MS-CHAP to those of MS-CHAP v2.
MS-CHAP and MS-CHAP v2 Security Feature Comparison
|
MS-CHAP
|
MS-CHAP v2
|
|---|
LAN Manager encoding of the response used for backward compatibility with older Microsoft remote access clients is cryptographically weak. | LAN Manager-encoded responses are not allowed. |
LAN Manager encoding of password changes is cryptographically weak. | LAN Manager-encoded password changes are not allowed. |
Only one-way authentication is possible. The remote access client cannot verify that it is dialing in to its organization’s remote access server or a masquerading remote access server. | Two-way authentication, also known as mutual authentication, is provided. The remote access client receives verification that the remote access server that it is dialing in to has access to the user’s password. |
With 40-bit encryption, the cryptographic key is based on the user’s password. Each time the user connects with the same password, the same cryptographic key is generated. | The cryptographic key is always based on the user’s password and an arbitrary challenge string. Each time the user connects with the same password, a different cryptographic key is used. |
A single cryptographic key is used for data sent in both directions on the connection. | Separate cryptographic keys are generated for transmitted and received data. |
EAP
EAP is an extension to PPP that allows for arbitrary authentication mechanisms to be employed for the validation of a PPP connection. With PPP authentication protocols such as MS-CHAP and SPAP, a specific authentication mechanism is chosen during the link establishment phase. Then, during the connection authentication phase, the negotiated authentication protocol is used to validate the connection. The authentication protocol itself is a fixed series of messages sent in a specific order.
With EAP, the authentication mechanism is not chosen during the link establishment phase. Instead, each PPP peer negotiates to perform EAP during the connection authentication phase. After the connection authentication phase is reached, the PPP peers must first negotiate the use of a specific EAP authentication scheme known as an EAP type. After the EAP type is agreed on, EAP allows for an open-ended conversation between the remote access client and the remote access server that can vary based on the parameters of the connection. The conversation consists of requests for authentication information and the responses. The length and detail of the authentication conversation depends on the EAP type.
For example, when EAP is used with security token cards, the remote access server can separately query the remote access client for a name, PIN, and card token value. As each query is asked and answered, the user passes through another level of authentication. When all questions have been answered satisfactorily, the user is authenticated and permitted access to the network.
The use of EAP is negotiated during LCP negotiation by specifying the authentication protocol LCP option (type 3) and the authentication protocol 0xC2-27. After LCP negotiation is complete, EAP messages use the PPP Protocol ID of 0xC2-27. Windows Server 2003 includes support for the MD5-Challenge and Extensible Authentication Protocol-Transport Level Security (EAP-TLS) EAP types.
EAP is designed to allow authentication plug-in modules at both the client and server ends of a connection. By installing an EAP type library file on both the remote access client and the remote access server, a new EAP type can be supported. This presents vendors with the opportunity to supply a new authentication scheme at any time. EAP provides the most flexibility in authentication uniqueness and variations.
Note
EAP Infrastructure
EAP is a set of internal components that provide architectural support for EAP types. For successful authentication, both the remote access client and authenticator must have the same EAP authentication module installed. Windows Server 2003 provides two EAP types: MD5-Challenge and EAP-TLS. EAP-TLS is available only for members of a domain. In addition, EAP contains EAP-RADIUS, which is not an EAP type, but is used to send EAP messages to a RADIUS server for authentication.
You can also install additional EAP types. The components for an EAP type must be installed on every remote access client and every authenticator.
MD5-Challenge
MD5-Challenge is the CHAP authentication mechanism used within the EAP framework. Rather than negotiating to perform MD5-Challenge authentication during the link establishment phase, the authenticator and peer negotiate to use EAP during the connection authentication phase.
MD5-Challenge is a required EAP type and can be used to test EAP interoperability. Like CHAP, MD5-Challenge requires that local or domain passwords are stored in a reversibly encrypted form.
EAP-TLS
The Transport Layer Security (TLS) protocol, based on Secure Sockets Layer (SSL), allows applications to communicate securely. TLS provides authentication (user and data), data integrity, and data confidentiality services. To achieve these services, TLS specifies a framework that allows the following:
-
Client and two-way authentication using symmetric or asymmetric encryption.
-
Negotiation of the specific encryption algorithm (the cipher-suite).
-
Secured exchange of encryption keys to be used for encrypting messages.
-
Message integrity and user authentication using a message authentication code.
For more information about TLS, see RFC 2246. For more information about EAP-TLS, see RFC 2716.
EAP-TLS uses the TLS protocol for authentication during the establishment of a PPP connection. With EAP-TLS, mutual authentication between the PPP client and the authenticator is performed through the exchange and verification of certificates. The client attempting the connection sends a user certificate, and the authenticator sends a machine certificate. If smart cards are used for remote access authentication, EAP-TLS is the required authentication method. For more information about smart card authentication, see “IAS Technical Reference.”
EAP-TLS is supported only on Windows Server 2003 remote access server computers that are members of a Windows Server 2003 mixed or native domain. Stand-alone Windows Server 2003 remote access servers do not support EAP-TLS.
EAP-RADIUS
EAP-RADIUS passes EAP messages of any EAP type by the remote access server to a RADIUS server for authentication. The EAP messages sent between the remote access client and remote access server are encapsulated and formatted as RADIUS messages between the remote access server and the RADIUS server. The remote access server becomes a pass-through device passing EAP messages between the remote access client and the RADIUS server. All processing of EAP messages occurs at the remote access client and the RADIUS server.
EAP-RADIUS is used in environments in which Remote Authentication Dial-In User Service (RADIUS) is used as the authentication provider. An advantage of using EAP-RADIUS is that EAP types do not need to be installed at each remote access server, only at the RADIUS server.
In a typical use of EAP-RADIUS, the remote access server is configured to use EAP and to use RADIUS as its authentication provider. When a connection attempt is made, the remote access client negotiates the use of EAP with the remote access server. When the client sends an EAP message to the remote access server, the remote access server encapsulates the EAP message as a RADIUS message and sends it to its configured RADIUS server. The RADIUS server processes the EAP message and sends a RADIUS-encapsulated EAP message back to the remote access server. The remote access server then forwards the EAP message to the remote access client.
For more information about RADIUS support for EAP, see RFC 2869.
The Microsoft implementation of PPP includes the optional use of CBCP (Callback Control Protocol) immediately after authentication.
CBCP negotiates the use of callback in those cases in which the remote access server, after authenticating the remote access client, terminates the physical connection, waits a specified amount of time, and then calls the remote access client back at either a static or dynamically configured phone number. Common CBCP options include the phone number that will be used by the remote access server to call back the remote access client.
Packet Structure
CBCP uses the PPP Protocol ID of 0xC0-29. The packet structure of CBCP is exactly the same as the packet structure for LCP; however, only the Callback-Request (type 1), Callback-Response (type 2), and Callback-Ack (type 3) types are used. For all CBCP packet types, the CBCP data portion of the CBCP packet consists of one or more CBCP options. Each CBCP option consists of an option Type field; an option Length field indicating the total length, in bytes, of the option; and the data associated with the option.
Negotiated Options
The following table lists the CBCP options negotiated by Microsoft PPP peers.
CBCP Options
|
Option Name
|
Option Type
|
Option Length
|
Description
|
|---|
No callback | 1 | 2 | No callback is used for the connection. |
Callback to a user-specified number | 2 | variable | The user of the remote access client computer determines the callback number. |
Callback to an administrator-defined number | 3 | variable | Settings on the remote access server determine the callback number. |
Callback to any of a list of numbers | 4 | variable | The remote access server calls back to one of a list of phone numbers. |