通过

Office Communicator SIP Trace Analysis – Registration

  • 项目

When I changed my career path to Unified Communications a few years ago (after having spent two decades with several UNIX flavors, MS directory and MS messaging platforms), one of the biggest challenges for me was trying to understand what all those methods and headers in SIP protocol trace exactly meant.

In trying to decipher it’s meaning, especially when troubleshooting unsuccessful calls, it didn’t help that there was no abundance of helpful online information.

First huge help was the introduction of Snooper tool from Microsoft OCS 2007 Resource Kit Tools, as Snooper sorts related SIP messages and presents SIP methods and headers in very readable way, in contrast to plain text files you had to use for analysis before Snooper.

Having Snooper around and SIP protocol gaining on significance each day actually determined the first topic for my Unified Communications blog – understanding SIP traces. Once this was decided, why not start from the beginning – client registration itself.

In a series of Snooper screenshots that follow, we’ll go through the registration process when SIP client registers its address with SIP server. You will see two examples: Office Communicator user registering both from internal network, and from outside, as a remote user. You will also see that not every red message in Snooper immediately denotes an issue – in registration process it may be just a normal, expected message that fits in the expected registration flow.

 

Remote SIP client registration

So, let’s start with a remote client (sip:izabelaf\@uclab.org) that initiates the login sequence by sending a REGISTER request.

Figure 1

Figure 1: The remote client sends a REGISTER request with no credential or authentication information.

The more detailed look at the first packet (Figure 1) will reveal that the client connects from its local address (200.1.1.201) to port 443 of Access Edge Server (200.1.1.20). In Office Communications Server 2007 R2, port 443 of Access Edge server is used for remote user access. Note that the Call-ID header will have the same value throughout the session - in this case it will be the same for all 6 messages from the beginning of registration process till its end.

In this first packet the client sends REGISTER request without any credentials, as suggested in RFC 3261.

Note: From: and To: header values in Register request will typically be the same, as From: header denotes the client responsible for registration, while To: header denotes the client whose registration is to be created. The only case those two fields can differ would be if the request is third-party registration. For more information on mandatory SIP header fields in SIP requests, please check RFC 3261 - SIP: Session Initiation Protocol

 

Figure 2

Figure 2: The server responds to the request with a 401, indicating that it supports NTLM and requires authentication.

Since authentication is enabled on the server, it sends 401 Unauthorized message to the client and indicates a support for NTLM authentication. Note that server added “ms-user-logon-data: RemoteUser” header to indicate that the client is logging in from outside of corporate network. This information also tells the client that it should use the web service URLs that are accessible from the Internet for distribution list expansion, address book download, and meeting content download [1] The RemoteUser info also tells the client that it does not have direct media connectivity to the enterprise network.

[1] The client will obtain all necessary information later in a 200 OK response to the SUBSCRIBE request for In-band Provisioning event (Event: vnd-microsoft-provisioning-v2)

 

Figure 3

Figure 3: The client reissues the request

Client reissues the request, now with Authorization header, confirming it supports NTLM authentication. The client calls the NTLM authentication protocol implementation with Izabela’s credentials (user name, domain, and password) and several other (Datagram, Identify, and Integrity) parameters to initialize the security context and generate (an empty) NEGOTIATE_MESSAGE. You can use one of network trace tools (NetMon, Wireshark) to obtain more data about actual NTLM messages exchange.

NTLM Background Information: There are two major flavors of NTLM auth protocol: connection-oriented and connectionless (datagram). In connection-oriented NTLM, negotiation starts with a NEGOTIATE_MESSAGE, carrying the client's preferences, and the server replies with NegotiateFlags in the subsequent CHALLENGE_MESSAGE. In connectionless (datagram) NTLM, however, the server starts the negotiation with the CHALLENGE_MESSAGE and the client replies with NegotiateFlags in the subsequent AUTHENTICATE_MESSAGE.

In our example above, the client picked Datagram option, and that is the reason an empty NEGOTIATE_MESSAGE is sent.

 

Figure 4

Figure 4: The server responds with 401 sending an appropriate challenge in WWW-Authenticate SIP header

After receiving client’s reissued REGISTER request, the server calls its NTLM security subsystem which processes empty NEGOTIATE_MESSAGE and generates NTLM CHALLENGE_MESSAGE which it sends to the client (gssapi-data parameter carrying the challenge in WWW-Authenticate header) in another 401 Unauthorized message (Figure 4).

 

Figure 5

Figure 5: The client responds to the server's challenge.

Client now reissues the REGISTER request with the response to the server’s challenge (Figure 5).

The process of generating response to server’s challenge (simplified due to clarity) starts with client first having to decode base64-encoded content of gssapi-data parameter and passing the challenge to its NTLM subsystem that in turn generates AUTHENTICATE-MESSAGE. Gssapi-data parameter (sent in Proxy-Authorization header) thus carries client’s response to server challenge proving that the client knows the password.

 

Figure 6

Figure 6: The server processes the request and responds (including its signature for the response) with Authentication-Info.

The server finds out the client identity from the request and the "opaque" value from the authorization header field received in previous REGISTER request (Figure 5), and calls its NTLM subsystem to process AUTHENTICATE_MESSAGE. The NTLM subsystem authenticates the client and validates that the user is authorized to use the "izabelaf@uclab.org" SIP URI. The server continues processing the REGISTER request (as described in RFC3261) and passes it to the SIP Registrar component which (after it completes processing) sends back a "200" response to the client (Figure 6).

 

Internal SIP client registration

Let’s see now what happens with internal client (sip:marinof\@uclab.org) issuing REGISTER request:

Figure 7

Figure 7: The client sends a REGISTER request with no credential or authentication information.

As you can see in Figure 7 showing the first REGISTER attempt for internal user, the client connects from its local address (172.31.255.247) to port 5061 of his home pool (172.31.255.222). Again, no credentials or authentication information is sent to the server.

 

Figure 8

Figure 8: The server responds with "401"

Figure 8 shows server sending 401 Unauthorized to the client, also stating its support for both Kerberos and NTLM authentication methods (WWW-Authenticate headers). Please note the difference in targetname parameter values between Kerberos and NTLM responses: The targetname parameter for Kerberos contains the SPN for Marino’s home server, while the targetname for NTLM carries the FQDN of home server.

Note: For Kerberos, the targetname value must be prefixed with a "sip/" service descriptor and the server must register its targetname value with the KDC database. If the server supports both the NTLM and Kerberos protocols, the targetname value in NTLM must be the same as the targetname value in Kerberos without the "sip/" service descriptor.

 

Figure 9

Figure 9: The client chooses Kerberos protocol and reissues REGISTER request to the home server

What is not visible from the SIP trace[2] is that client obtained a Kerberos ticket for the server (in KRB_TGS_REP message from Ticket Granting Service – see Kerberos background information (1) ). The client included this information in the gssapi-data parameter of the Proxy-Authorization header:

Proxy-Authorization: Kerberos qop=”auth”, realm =”SIP Communications Service”,

targetname=”sip/R2EE01.uclab.org”, version=4, gssapi-data”=”YIIE…”

The Proxy-Authorization: header above (and in more details in Figure 9) shows that client opts for Kerberos auth (Proxy-Authorization: Kerberos) and reissues the REGISTER requests to his home server identified by an SPN in targetname parameter (sip/R2EE01.uclab.org).

Please, also note the response parameter in Proxy-Authorization header – the value of this parameter carries the client signature, while analogous parameter on the server side is rspauth which carries the server signature (it can be found in Proxy-Authentication-Info header in servers response – Figure 10).

[2] The entire Kerberos ticket request/response message flow can be seen using a NetMon or Wireshark network trace

 

Figure 10

Figure 10: The server processes the request and responds

Marino’s home server received the REGISTER request, verified the Kerberos ticket (see Kerberos Background Information (2) ) and successfully processed the REGISTER request.

 

Kerberos vs NTLM Background info

Although the Kerberos vs. NTLM title may sound a bit pompous, as it’s not easy to compare these two protocols in just a few words, I’ll try to address just those most obvious differences that are important for our topic.

Office Communications Server 2007 R2 supports two authentication mechanisms when it comes to client-to-server authentication and mutual message signing: Kerberos and NTLM. While Kerberos is standard and a more secure protocol, there are situations where NTLM has to be used.

An example is when remote user (not having connectivity to the Domain Controller) tries to register to its home pool. With Kerberos, the client must request Kerberos ticket from the KDC (Key Distribution Center), which, in Microsoft implementation, resides on the domain controller (see Kerberos Background Information (3) .

Although you can find some background info below, a full Kerberos authentication details are not in the scope of this blog, so to make the long story short – with Kerberos auth, client have to have access to Domain Controller to be able to authenticate which is not the case with remote clients (I am not discussing the clients connected through VPN, but “real” remote clients accessing their OCS infrastructure by means of Edge servers).

NTLM is a bit more benevolent when it comes to authenticating remote users. With NTLM, the client doesn’t have to directly contact DC, but the server verifies the client's credentials by contacting the domain controller. This NTLM’s approach to authentication allows clients that do not have connectivity to the domain controller to authenticate with the server using NTLM authentication. This is also the main reason for supporting NTLM, in addition to the more secure and standard Kerberos authentication.

 

Kerberos background information (1)

For more details on Kerberos message flow, please take a look at How the Kerberos Version 5 Authentication Protocol Works and particularly RFC 4120 - The Kerberos Network Authentication Service (V5) . I will provide just a short overview of the process that should be sufficient for the blog topic.

In a nutshell, there are three types of ticket exchanges with six messages exchanged:

· Authentication Service Exchange: KRB_AS_REQ and KRB_AS_REP

· Ticket Granting Service Exchange: KRB_TGS_REQ and KRB_TGS_REP

· Client/Server Exchange: KRB_AP_REQ and KRB_AP_REP

A little more details on each of these messages:

KRB_AS_REQ

As its name implies, the client contacts KDC’s Authentication Service (residing on Domain Controller) with request to obtain a TGT. Client will use TGT every time when it requests a service ticket to access a service or application on the server. Without TGT, client would have to enter password each time it requests a service ticket, and this way it enters password only during logon. So, in this first KRB_AS_REQ message, client sends username and user’s domainname in clear text, together with Pre-authenticator (e.g. machine timestamp encrypted with user’s password hash)

KRB_AS_REP

if AS can decrypt Pre-authenticator (which would prove that client knows the proper password), it will create a session ticket with session key for client-to-KDC communication, as well as a TGT (readable only by KDC) which contains client authorization data. The client will use obtained session key to encrypt further communication with TGS, for example, to encrypt Authenticator (usually contains client ID and client machine’s timestamp) that it will present to Ticket Granting Service (together with TGT) when requesting service ticket.

KRB_TGS_REQ

When client needs access to network (or even local computer) resources it will send a request to TGS for the service ticket. To get the service ticket, client will present TGT (obtained in KRB_AS_REP), an Authenticator and the name of target server (in a form of Service Principal Name, or SPN). If TGS can decrypt authenticator using the session key known only to client and KDC, it would prove that client is the one who it claims to be (in any case, it’s someone who knows the correct session key :). Just to shortly discuss this smiley – although Kerberos is secure protocol, password policy is critical here, as with very weak password, brute force attack can be successful in decrypting pre-authenticator mentioned in KRB_AS_REQ. In that case, all further steps could be compromised, so please, pay attention to complex passwords that are long enough and combination of lowercase, uppercase, non-alphanumeric characters, and digits.

KRB_TGS_REP

The Ticket Granting Service will examine the TGT and authenticator and if both are acceptable, TGS will create a service ticket. Apart from service ticket (that only server can decrypt), TGS will send a session key for client/server encrypted communication. I didn’t mention so far that TGT (which is btw, encrypted with krbtgt account’s password hash) contains user’s (security principal’s) authorization information in a field called PAC (Privilege Attribute Certificate). The content of PAC (group membership of security principal requesting access) is copied to service ticket and will be used later to construct access token for the client.

KRB_AP_REQ

As soon as client needs to access the server/service, it will send the service ticket to the server as well as Authenticator (client ID and machine timestamp encrypted with client/server session key). When server obtains the service ticket, it will decrypt it (using the key known only to server and KDC), extract its own copy of the client/server session key, use this session key to verify authenticator and if everything is ok, it will create an access token for the user based on SIDs found in service ticket.

KRB_AP_REP

The last message actually is optional, and is used if client requested mutual authentication. The server will use its copy of client/server key to encrypt (modified) authenticator and send it back to the client. It’s necessary to modify and re-encrypt the authenticator to prove that authenticator is not just replay attempt.

Please note that this is just very condensed information about Kerberos ticket exchange and I would suggest to refer to RFC 4120 - The Kerberos Network Authentication Service (V5) each time you need detailed information about all Kerberos aspects.

 

Kerberos background information (2)

When client request any service from the server, one of the messages it sends to the server (in KRB_AP_REQ request) is an Authenticator – it can simply be a Client ID and client machine’s timestamp encrypted with the key only client and server know. The client obtained this client/server key in earlier, KRB_TGS_REP exchange from Ticket Granting Service. Apart from client/server key that client could decrypt, TGS also sent service ticket (that contains the same client/server key) that only server can decrypt. The server will use server/KDC key to decrypt the service ticket, extract client/server key, use it to decrypt Authenticator and thus verify that client is who he claims to be. The last step would be for server to modify authenticator, encrypt it with client/server key and send back to client for mutual authentication (as described in KRB_AP_REP) above.

 

Kerberos background information (3)

Again, the whole story is a bit more complex, as client first needs to obtain a ticket to access Ticket Granting Service on KDC, by contacting Kerberos Authentication Service first, as described in Kerberos background information (1)

Comments

  • Anonymous
    January 26, 2012
    I was searching for this a tutorial which will explain how to analyse OCS logs and what are the normal loging sequence which will help in troubleshooting .This is an excellent post.Have you done any similar document which will demonstrate clearly what excactly happening (or expected to be happen ) while doing a live meeting, Live meeting with audio and video,Calling one to one or many using PSTN/OCS platforms etc etc. .If so please provide me the details to sachinrajtn@hotmail.com or post it here