6 Appendix A: Product Behavior

  • Article

The information in this specification is applicable to the following Microsoft products or supplemental software. References to product versions include updates to those products.

  • Windows Vista operating system

  • Windows Server 2008 operating system

  • Windows 7 operating system

  • Windows Server 2008 R2 operating system

  • Windows 8 operating system

  • Windows Server 2012 operating system

  • Windows 8.1 operating system

  • Windows Server 2012 R2 operating system

  • Windows 10 operating system

  • Windows Server 2016 operating system

  • Windows Server operating system

  • Windows Server 2019 operating system

  • Windows Server 2022 operating system

  • Windows 11 operating system

Exceptions, if any, are noted in this section. If an update version, service pack or Knowledge Base (KB) number appears with a product name, the behavior changed in that update. The new behavior also applies to subsequent updates unless otherwise specified. If a product edition appears with the product version, behavior is different in that product edition.

Unless otherwise specified, any statement of optional behavior in this specification that is prescribed using the terms "SHOULD" or "SHOULD NOT" implies product behavior in accordance with the SHOULD or SHOULD NOT prescription. Unless otherwise specified, the term "MAY" implies that the product does not follow the prescription.

<1> Section 2.1: Applicable Windows Server releases and Windows 10, except Windows Vista, do not support HTTPS client authentication, but support client authentication by using MS-CHAPv2 [RFC2759], EAP-TLS [RFC5216], PEAP-MSCHAPv2, and PEAP-TLS. See [MS-PEAP] for details on how to use PEAP with inner methods such as MS-CHAPv2 and EAP-TLS.

Applicable Windows Server releases also support client authentication by using Password Authentication Protocol (PAP), as referenced in [RFC1334], and CHAP [RFC1994], but do not recommend their use for security reasons.

<2> Section 2.2.8: Applicable Windows Server releases allow a retry count of 3.

<3> Section 2.2.13: Windows always send a Status Info attribute in a Call Abort message.

<4> Section 2.2.14: Windows always send a Status Info attribute in a Call Disconnect message.

<5> Section 3.2.1: In applicable Windows releases, except Windows Vista and Windows Server 2008, support bypass of PPP authentication. On the client side, this protocol exposes APIs to the management layer to indicate ClientBypassHLAuth and ClientHTTPCookie. On the server side, this protocol exposes Routing and Remote Access Server APIs to indicate Accept New Connection along with the cookie to the management layer. However, this Windows protocol does not generate the cookie, nor does it validate one on the server side. It relies totally on the management layer to do the same in its own implementation-specific way.

<6> Section 3.2.2.1: Windows client starts a timer with a value of 60 seconds after sending a Call Connected message and starts a timer with a value of 60 seconds after receiving a Call Connected message.

<7> Section 3.2.4.1: Applicable Windows Server releases, except Windows Server 2008, do not support the HTTPS termination proxy.

<8> Section 3.2.5.2.2:  The implementation uses AUTH_USE_EAP to cover the case of EAP TLS.

<9> Section 3.2.5.2.4:  The implementation uses AUTH_USE_EAP to cover the case of EAP TLS.

<10> Section 3.2.5.3.3: In Windows, except Windows Vista without service packs, only the Encapsulation Protocol ID is sent by the SSTP client in the SSTP_MSG_CALL_CONNECT_REQUEST (section 2.2.9) message, and a negative SSTP_MSG_CALL_CONNECT_NAK (section 2.2.12) will be received by the client only if the SSTP server does not support transport of PPP frames over SSTP. The Windows client retries 3 times.

<11> Section 3.3.1: In applicable Windows releases, except Windows Vista and Windows Server 2008, support bypass of PPP authentication. On the client side, SSTP exposes APIs to the management layer to indicate ClientBypassHLAuth and ClientHTTPCookie. On the server side, SSTP exposes Routing and Remote Access Server APIs to indicate Accept New Connection along with the cookie to the management layer. However, this Windows protocol does not generate the cookie, nor does it validate one on the server side. It relies totally on the management layer to do the same in its own implementation-specific way.

<12> Section 3.3.2.1: Applicable Windows Server releases wait 60 seconds for the Call Connected message and 60 seconds for the Call Connect Request message.

<13> Section 3.3.3: In applicable Windows Server releases, the Routing and Remote Access Service is used as the SSTP management layer on the server side. The SSTP server state is initialized when the Routing and Remote Access Service is started or when SSTP ports are configured within the service.

<14> Section 3.3.3: By default, Windows uses the URI: /sra_{BA195980-CD49-458b-9E23-C84EE0ADCD75}/.

<15> Section 3.3.4: Windows management layer supports administrator-determined disconnection of the SSTP connection. Windows also supports disconnections based on idle timeout and maximum connection lifetime. These values are retrieved by the management layer from Remote Authentication Dial-in User Service (RADIUS) attributes, if they are available:

  • Maximum connection lifetime is retrieved from the Session-Timeout attribute ([RFC2865] section 5.27).

  • Idle timeout is retrieved from the Idle-Timeout attribute ([RFC2865] section 5.28).

Otherwise, disconnections based on the idle timeout or maximum connection lifetime are not applied by the management layer.

<16> Section 3.3.5.2.2: Applicable Windows Server releases allow a retry count of 3.

<17> Section 3.3.5.2.3: Applicable Windows Server releases start allowing PPP control frames from the client and request the PPP layer to start the FSM. However, neither operating system will allow any data frames until the PPP negotiation is completed.

<18> Section 3.3.7.3: Windows, except Windows Vista and Windows Server 2008, support bypass of PPP authentication. On the client side, this protocol exposes APIs to the management layer to indicate ClientBypassHLAuth and ClientHTTPCookie. On the server side, this protocol exposes Routing and Remote Access Server APIs to indicate Accept New Connection along with the cookie to the management layer. However, this Windows protocol does not generate the cookie, nor does it validate one on the server side. It relies totally on the management layer to do the same in its own implementation-specific way.

<19> Section 4.1: Windows by default supports only HTTPS traffic. HTTP can be enabled via a registry key.