4.1 Registration with Kerberos

Article
02/14/2019

The following flow outlines how the Kerberos authentication mechanism works during the registration process. At this point in time, the client discovers its outbound proxy and initializes an SA (or context) with it.

Kerberos registration flow

Figure 1: Kerberos registration flow

The fundamental difference between the NTLM Authentication Protocol and Kerberos is the way in which the client answers a challenge from the server. With Kerberos, the client first acquires a Kerberos ticket from the KDC (Active Directory) for the specific server that is issuing the challenge. The server is identified by an SPN containing a fully qualified domain name (FQDN). The SPN is of the form sip/<FQDN>. The SPN for a challenge is carried in the targetname parameter in the Proxy-Authenticate: header of the challenge.

Alice's client sends a REGISTER request with no credentials (no Proxy-Authorization: header) to the outbound server it selected.

 REGISTER sip:registrar.contoso.com SIP/2.0
 Via: SIP/2.0/TLS alice1.contoso.com;branch=z9hG4bK7
 From: "Alice" <sip:Alice@contoso.com>;tag=354354535;epid=6534555
 To: "Alice" sip:Alice@contoso.com
 Call-ID: 123213@Alice1.contoso.com
 CSeq: 12345 REGISTER
 Max-Forwards: 70
 User-Agent: Windows RTC/1.1.2600
 Contact: "Alice" sip:Alice@Alice1.contoso.com
 Content-Length: 0

The epid parameter on the From: header uniquely identifies this particular endpoint for the user. The server uses this value in subsequent messages to determine the SA with which to sign the message.

Authentication is enabled at the outbound server, and it challenges Alice's client. The server indicates support for NTLM and Kerberos in the challenge.
```
 SIP/2.0 407 Proxy Authentication Required
 Via: SIP/2.0/TLS Alice1.contoso.com;branch=z9hG4bK7
 From: "Alice" <sip:Alice@contoso.com>;tag=354354535;epid=6534555
 To: "Alice" <sip:Alice@contoso.com>;tag=5564566
 Call-ID: 123213@Alice1.contoso.com
 CSeq: 12345 REGISTER
 Date: Sat, 13 Nov 2010 23:29:00 GMT
 Proxy-Authenticate: Kerberos realm="Contoso RTC Service Provider", 
    targetname="sip/hs1.contoso.com", qop="auth"
 Proxy-Authenticate: NTLM realm="Contoso RTC Service Provider", 
    targetname="hs1.contoso.com", qop="auth"
 Content-Length: 0
```
The targetname parameter carries the SPN for this proxy for Kerberos and the FQDN of the proxy for NTLM. The actual contents of this parameter are meaningful for this proxy but are opaque to other proxies and the client. It is merely a unique string for correlation of the message header to an SA. Two Proxy-Authenticate: headers are present, indicating the server's capability to do one of Kerberos or NTLM.

The proxy inserts a Date: header in the 407 challenge to allow the client to detect clock skew between the client and server. Both NTLM 2.0 and Kerberos 5.0 require synchronization of the client and server clocks. Clock skew can cause authentication to fail even with valid credentials. The presence of the Date: header allows the client to log this condition and the administrator to correct the deviation.
The client acquires a Kerberos ticket for the server indicated in the targetname parameter of the Kerberos Proxy-Authenticate: header. The client reissues the request with a Proxy-Authorization: header containing the encoded Kerberos ticket.
```
 REGISTER sip:registrar.contoso.com SIP/2.0
 Via: SIP/2.0/TLS Alice1.contoso.com;branch=z9hG4bK9
 From: "Alice" <sip:Alice@contoso.com>;tag=354354535;epid=6534555
 To: "Alice" sip:Alice@contoso.com
 Call-ID: 123213@Alice1.contoso.com
 CSeq: 12346 REGISTER
 Max-Forwards: 70
 User-Agent: Windows RTC/1.1.2600
 Proxy-Authorization: Kerberos realm="Contoso RTC Service Provider", 
    targetname="sip/hs1.contoso.com",qop="auth",gssapi-data="34fcdf9345345"
 Contact: "Alice" sip:alice@alice1.contoso.com
 Content-Length: 0
```
The Cseq number has been incremented. The Call-ID and epid remain the same.

The targetname parameter echoes the value of the targetname parameter in the previous Proxy-Authenticate: header. The gssapi-data parameter contains the Kerberos ticket information. The choice of Kerberos authentication is indicated by the scheme (Kerberos) as the first token in the header.
On reception of the REGISTER request, the outbound server authenticates the user with the information in the Proxy-Authorization: header. Authentication succeeds, and an SA is created in the outbound server for Alice's client.

The Director then redirects the REGISTER request to point the client at the appropriate home server for this user. The redirect response is signed, using the newly established SA between the client and this proxy.
```
 SIP/2.0 301 Moved Permanently
 Via: SIP/2.0/TLS Alice1.contoso.com;branch=z9hG4bK9
 From: "Alice" <sip:Alice@contoso.com>;tag=354354535;epid=6534555
 To: "Alice" sip:Alice@contoso.com
 Call-ID: 123213@Alice1.contoso.com
 CSeq: 12346 REGISTER
 Proxy-Authentication-Info: 
     Kerberos realm="Contoso RTC Service Provider", 
     targetname="sip/hs1.contoso.com", qop="auth", opaque="ACDC123", 
     srand="3453453", snum=1, rspauth="23423acfdee2"
 Contact: sip:hs2.contoso.com
 Content-Length: 0
```
The Proxy-Authentication-Info: header carries the signature for this SIP message. The snum is set to 1 as this is the first message signed with the newly established SA. The srand parameter contains the (random) salt value used by the server to generate the signature. The opaque parameter contains a unique token for this newly established SA.
The client receives the redirect response, verifies the signature using the now complete SA for the outbound proxy, and reissues the REGISTER request to its proper home server.
```
 REGISTER sip:hs2.contoso.com SIP/2.0
 Via: SIP/2.0/TLS Alice1.contoso.com;branch=z9hG4bKa
 From: "Alice" <sip:Alice@contoso.com>;tag=354354535;epid=6534555
 To: "Alice" sip:Alice@contoso.com
 Call-ID: 123213@Alice1.contoso.com
 CSeq: 12347 REGISTER
 Max-Forwards: 70
 User-Agent: Windows RTC/1.1.2600
 Contact: "Alice" sip:Alice@Alice1.contoso.com
 Content-Length: 0
```
The client will replace its current outbound proxy with the proxy indicated in the Contact: header of the 301 response. The REGISTER request is sent to this new outbound proxy (the user's true home server). Because no SA exists yet with this new outbound proxy, no Proxy-Authorization: header is present in the request.

Alice's home server receives the REGISTER request and issues a challenge, indicating support for NTLM and Kerberos.

 SIP/2.0 407 Proxy Authentication Required
 Via: SIP/2.0/TLS Alice1.contoso.com;branch=z9hG4bKa
 From: "Alice" <sip:Alice@contoso.com>;tag=354354535;epid=6534555
 To: "Alice" <sip:Alice@contoso.com>;tag=8823488
 Call-ID: 123213@Alice1.contoso.com
 CSeq: 12347 REGISTER
 Date: Sat, 13 Nov 2010 23:29:00 GMT
 Proxy-Authenticate: Kerberos realm="Contoso RTC Service Provider",
    targetname="sip/hs2.contoso.com", qop="auth"
 Proxy-Authenticate: NTLM realm="Contoso RTC Service Provider", 
    targetname="hs2.contoso.com", qop="auth"
 Content-Length: 0

The targetname parameter for Kerberos contains the SPN for Alice's home server. The two Proxy-Authenticate: headers indicate support for Kerberos and NTLM, respectively. The realm is the same as for HS1 because they fall under the same protection space. This means the client will use the same credentials in responding to HS2's challenge.

Alice's client receives the challenge, selects Kerberos authentication, and reissues the REGISTER request to her home server. The client will acquire a Kerberos ticket for HS2 and include this information in the gssapi-data parameter of the Proxy-Authorization: header.

 REGISTER sip:hs2.contoso.com SIP/2.0
 Via: SIP/2.0/TLS Alice1.contoso.com;branch=z9hG4bKc
 From: Alice <sip:Alice@contoso.com>;
       tag=354354535;
       epid=6534555
 To: Alice sip:Alice@contoso.com
 Call-ID: 123213@Alice1.contoso.com
 CSeq: 12348 REGISTER
 Max-Forwards: 70
 User-Agent: Windows RTC/1.1.2600
 Proxy-Authorization: Kerberos realm=Contoso RTC Service Provider,
      targetname=sip/hs2.contoso.com,
      qop=auth, gssapi-data=8234934234,
      opaque=CDEF1245
 Contact: Alice sip:alice@alice1.contoso.com
 Content-Length: 0

The Cseq: number is incremented. The Call-ID and epid remain the same. The Proxy-Authorization: header indicates support for Kerberos authentication.

Alice's home server receives the REGISTER request, verifies the Kerberos ticket, and processes the REGISTER request. The SA between Alice's home server and Alice's client is now complete. The server responds to the REGISTER request and signs the response using the newly completed SA. The epid parameter from the From: header is saved as part of the registration information for Alice. This value will be inserted in the To: header of subsequent requests that are forwarded to Alice via her home server (registrar).
```
 SIP/2.0 200 OK
 Via: SIP/2.0/TLS Alice1.contoso.com;branch=z9hG4bKc
 From: "Alice" <sip:Alice@contoso.com>;tag=354354535;epid=6534555
 To: "Alice" <sip:Alice@contoso.com>;tag=8823488
 Call-ID: 123213@Alice1.contoso.com
 CSeq: 12348 REGISTER
 Expires: 3600
 Proxy-Authentication-Info: 
    Kerberos realm="Contoso RTC Service Provider", 
    targetname="sip/hs2.contoso.com", qop="auth", 
    opaque="CDEF1245", rspauth="fefeacdd", srand=98984345, snum=1
 Contact: "Alice" sip:Alice@Alice1.contoso.com
 Content-Length: 0
```
The epid parameter on the From: header is used by the server to determine how to sign this response (find the SA). The signature for this response is carried in the rspauth parameter of the Proxy-Authentication-Info: header. The opaque parameter indicates the newly established SA. Because this is the first signed message from HS2 to the client, the snum parameter is set to 1.

Share via

4.1 Registration with Kerberos

Additional resources