3.1 Protocol Overview

  • Article

This protocol implements a proprietary Kerberos, NTLM, and TLS-DSK<1> authentication mechanism that is used by the SIP protocol client for client-to-server authentication and mutual signing of messages by both the SIP client and the SIP server. For more information about NTLM, see [MS-NLMP]. For more information about Kerberos, see [RFC4120] and [MS-KILE]. For more information about TLS, see [RFC2246], [RFC4346], and [RFC5246].

Authentication consists of two phases. In the first phase, a security association (SA) is established between the protocol client and the server. In the second phase, the protocol client and server use the existing SA to sign messages that they send, and to verify the messages that they receive. The exact message exchange in the first phase differs depending on whether NTLM, Kerberos, or TLS-DSK authentication is used.

The primary distinction between NTLM and Kerberos is the need for connectivity to the domain controller (DC). In Kerberos, the protocol client MUST request a Kerberos ticket from the Key Distribution Center (KDC), which in the proprietary implementation is a process that resides on the DC. In NTLM, the server verifies the protocol client's credentials by contacting the DC. This difference allows protocol clients that do not have connectivity to the DC 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.

The TLS-DSK authentication is based on certificates that SHOULD be obtained by the client through an out-of-band mechanism, such as contacting a security token service (STS). One such mechanism is specified in [MS-OCAUTHWS].

During the NTLM SA establishment phase, a three-way handshake, or three round trips, occurs between the protocol client and the protocol server.

  • The protocol client sends a request with no credential or authentication information. The server responds to that request with a 401 Unauthorized or 407 Proxy Authentication Required, indicating that it supports NTLM and possibly other protocols, such as Kerberos or TLS-DSK, and requires authentication.

  • The protocol client reissues the request, indicating its preference for NTLM authentication and including the content of NTLM NEGOTIATE_MESSAGE, as described in [MS-NLMP]. The server responds with an NTLM CHALLENGE_MESSAGE in a 401 Unauthorized or 407 Proxy Authentication Required.

  • The protocol client reissues the request with an NTLM response, an AUTHENTICATE_MESSAGE, to the server's challenge. If the protocol client negotiates version 4 of the authentication protocol, it MUST also sign the request, or include NTLMSSP_MESSAGE_SIGNATURE. The server processes the request and responds, including NTLMSSP_MESSAGE_SIGNATURE for the response.

  • The SA is now established on both the protocol client and server, and subsequent messages between the protocol client and server are signed, which means that they carry a signature formatted as NTLMSSP_MESSAGE_SIGNATURE in the message.

During the Kerberos SA establishment phase, a two-way handshake, or two round trips, occurs between the SIP protocol client and the SIP server.

  • The protocol client sends a request with no credential or authentication information. The server responds to that request with a 401 Unauthorized or 407 Proxy Authentication Required, indicating that it supports Kerberos and possibly other protocols, such as NTLM or TLS-DSK, and requires authentication.

  • The protocol client requests a Kerberos ticket for the server from the KDC, and reissues the request with this encoded Kerberos ticket information, or KRB_AP_REQ, as defined in [RFC4120]. If the protocol client negotiates version 4 of the authentication protocol, it MUST also sign the request, or include a Kerberos signature.

  • The server processes the request and responds, including a Kerberos signature for the response.

  • The SA is now established on both the protocol client and server, and subsequent messages between the protocol client and server are signed, which means that they carry an MIC token, as defined in [RFC4121], in the message.

During the TLS-DSK SA establishment phase, a four-way handshake, or four round trips, occurs between the SIP protocol client and the SIP server.

  • The protocol client sends a request with no credential or authentication information. The server responds to that request with a 401 Unauthorized or 407 Proxy Authentication Required, indicating that it supports TLS-DSK, and possibly other protocols, such as NTLM or Kerberos, and requires authentication. The response from the server SHOULD include a URI of a STS that the client can contact to obtain a certificate for authentication using the TLS-DSK protocol.

  • The protocol client locates or obtains a certificate and reissues the request, indicating its preference for TLS-DSK authentication and including data that encapsulates one or more TLS records in TLS record layer format, typically containing a TLS client_hello handshake message, as specified in [RFC2246], [RFC4346], and [RFC5246]. The server responds with a 401 Unauthorized or 407 Proxy Authentication Required response that encapsulates one or more TLS records that contain a TLS server_hello handshake message, followed by a TLS certificate, such as server_key_exchange, and then certificate_request, server_hello_done handshake messages.

  • The protocol client processes the response, reissues the request with data that encapsulates one or more TLS records containing TLS certificate, client_key_exchange, certificate_verify, change_cipher_spec, and finished handshake messages. The server processes the request, verifies the client certificate, and responds with a 401 Unauthorized or 407 Proxy Authentication Required response that encapsulates one or more TLS records that contain TLS change_cipher_spec and finished handshake messages.

  • The protocol client processes the response, and computes, or derives, client and server signing keys from the TLS-negotiated key material using an algorithm similar to the one specified in [RFC2716], and reissues the request with the signature. The server also computes, or derives, the server and client signing keys using the same algorithm and verifies the signature in the request. It can now respond and include the signature.

  • The SA is now established on both the protocol client and server, and subsequent messages between the protocol client and server are signed, which means that they carry a signature computed with the client and server signing keys.

For each SA, both the SIP protocol client and the server MUST keep track of the message sequence numbers by maintaining a sliding window. The initial range of this window is 1 to 256, and it is adjusted upward based on the highest sequence number received, while maintaining a window size of 256. Messages within the window can arrive in any order with regard to their sequence number, as long as no sequence number is used more than once. The purpose of maintaining this sliding window is to provide replay protection while allowing pipelining of messages for performance reasons.