3.1 NTLM/Kerberos Authentication Extensions Details

Session Initiation Protocol Extensions implements a proprietary Kerberos and NTLM Authentication Protocol authentication mechanism that is used by the client for client-to-server authentication and signing of messages. For more information on Kerberos, see [MS-KILE]. Encryption (privacy) is provided by TLS and is not explicitly covered by this authentication mechanism.

Authentication is broken down into two phases. In the first phase, a security association (SA) is established between the client and the server. In the second phase, the client and server use the existing SA to sign messages that they send and to verify the messages they receive. Unauthenticated messages from a client SHOULD NOT be accepted by the server. The exact message exchange in the first phase differs depending on whether NTLM or Kerberos authentication is used.

During the NTLM SA establishment phase, a three-way handshake occurs between the client and the server:

  1. The client sends a request with no credential or authentication information. The server responds to that request with a 401 or 407, indicating that it supports NTLM and Kerberos and requires authentication.

  2. The client reissues the request, indicating its preference for NTLM authentication. The server responds with an appropriate challenge in a 401 or 407.

  3. The client reissues the request with a response to the server's challenge. The server processes the request and responds (including its signature for the response).

  4. The SA is now established on both the client and server, and subsequent messages between the client and server are signed.

During the Kerberos SA establishment phase, a two-way handshake occurs between the client and the server:

  1. The client sends a request with no credential or authentication information. The server responds to that request with a 401 or 407, indicating that it supports NTLM and Kerberos and requires authentication.

  2. The client requests a Kerberos ticket for the server, and reissues the request with this encoded Kerberos ticket information.

  3. The server processes the request and responds (including its signature for the response).

  4. The SA is now established on both the client and server, and subsequent messages between the client and server are signed.

The primary distinction between NTLM and Kerberos is the need for connectivity to the domain controller. In Kerberos, the client must request a Kerberos ticket from the Key Distribution Center (KDC), which is a process that resides on the domain controller. In NTLM, the server verifies the client's NTLM credentials by contacting the domain controller. This difference allows clients that do not have connectivity to the domain controller to authenticate with the server using NTLM authentication, and it is the main reason for supporting NTLM in addition to the more secure and standard Kerberos authentication.