3.2.5.2 Crypto Binding

  • Article

During the SSL/TLS handshake, as part of establishing an HTTPS connection, the SSTP client authenticates the SSTP server. However, it is optional for the SSTP server to authenticate the client. The client is authenticated by the server during the higher-layer authentication (that is, PPP authentication). Therefore, it is possible for a man-in-the-middle to establish the HTTPS connection to the SSTP server and forward the PPP packets that it received from a client for a communication other than SSTP communications (for example, wireless communications). To prevent such attacks, it is important to cryptographically bind the two authentications.

This protocol implements cryptographic binding by requiring the client to send a value over the HTTPS connection as an SSTP message. This value is derived from the key data that is generated during PPP authentication. The SSTP protocol is agnostic of the mechanism used to generate key data, as long as SSTP server and client are using the same mechanism. The SSTP protocol neither carries any information pertaining to the key data generation mechanism nor does it enforce the mechanism to be the same on the client and server. The only requirement from the SSTP protocol is to have a higher layer authentication key (HLAK) of size 32 bytes which needs to be derived from the key data generated by the PPP authentication layer. By using this value, the SSTP client can prove that it is the entity that was authenticated with the SSTP server and that the PPP authentication was used for SSTP communications.

Because the client already authenticated the SSTP server during SSL/TLS handshake as part of establishing an HTTPS connection, the client can also confirm from the SSTP server that there is no man-in-the-middle or that the entity between the client and server is an entity that the SSTP server trusts (see section 5). This process, which is termed crypto binding, is used to protect the SSTP negotiation against man-in-the-middle attacks.

The sequence of steps that occurs is as follows:

  1. The TCP connection is established by the SSTP client to the SSTP server over TCP port 443.

  2. SSL/TLS handshake is completed over this TCP connection. The SSTP server is authenticated by the SSTP client. However, the client authentication by the server is only optional.

  3. The HTTPS request-response is completed.

  4. SSTP negotiation begins. The SSTP client sends a Call Connect Request message to the SSTP server. The SSTP server validates the request and sends a Call Connect Acknowledge message that contains a nonce to be used by the SSTP client in the Call Connected message.

  5. PPP negotiation is initiated, and PPP authentication is completed. For more information about PPP, see [RFC1661].

  6. The SSTP client sends the Call Connected message (section 2.2.11), which contains the following items:

    • The nonce that was sent by the SSTP server, that is, the ClientNonce.

    • The certificate received during HTTPS negotiation, that is, the ClientCertificateHash.

    • The Compound MAC, which is computed by using the key data that is generated during PPP authentication. If the PPP protocol supports Microsoft Point-to-Point Encryption (MPPE) key generation as defined in [RFC3079], the key data is used to generate the Higher Layer Authentication Key (HLAK) as specified in section 3.2.5.2.2 and 3.2.5.2.4.

      The SSTP server validates the Call Connected message, and SSTP negotiation is completed.

  7. PPP negotiation (that is, a network control protocol such as IP Control Protocol (IPCP) is negotiated) is completed.

Implementations MUST support the Crypto Binding feature of SSTP.

SSTP Version 1 allows either the SHA1 hash or the SHA256 hash to be used for generating the Compound MAC field in the Call Connected message.

If the SHA1 hash is used (and specified in the ClientHashProtocolChosen state variable described in section 3.2.1), then the Compound MAC field in the Crypto Binding packet (section 3.2.5.2) MUST contain the output of an HMAC-SHA1-160 operation (as specified in [RFC2104] and [RFC3174]), in which the key is derived from the higher-layer authentication method (that is, the PPP authentication method in SSTP Version 1). For information about how an implementation generates the data that is used in the HMAC-SHA1-160 operation for the Crypto Binding packet, see section 3.2.5.2.1. For information about how an implementation generates the key that is used in the HMAC-SHA1-160 operation for the Crypto Binding packet, see section 3.2.5.2.2.

If SHA256 is used (and specified in the ClientHashProtocolChosen state variable described in section 3.2.1), then the Compound MAC field in the Crypto Binding packet MUST contain the output of an HMAC-SHA256-256 operation (as specified in [SHA256]), in which the key is derived from the higher-layer authentication method (that is, the PPP authentication method in SSTP Version 1). For information about how an implementation generates the data that is used in the HMAC-SHA256-256 operation for the Crypto Binding packet, see 3.2.5.2.3. For information about how an implementation generates the key that is used in the HMAC-SHA256-256 operation for the Crypto Binding packet, see section 3.2.5.2.4.

For information about how the semantics are used by the SSTP client and server when performing the Crypto Binding exchanges, see sections 3.2.5.3.2 and 3.3.5.2.3.