Authentication is a method of associating an identity with an entity. The process of authentication is to collect some form of authentication information from an entity, analyze it, and determine whether an identity can be associated with the entity. In computer technology, four forms of information are used to confirm an entity’s identity:
What the entity knows (such as passwords or secrets)
What the entity is (such as biometrics)
What the entity can do (such as typing analysis)
What the entity has (such as a security badge)
The following sections discuss the authentication technologies—NTLM and Kerberos—that Office Communications Server uses. Digest authentication is used by anonymous conference participants, which is discussed in Chapter 4.
NT LAN Manager (NTLM) is a Microsoft authentication protocol that is the successor of Microsoft LAN Manager (LANMAN). NTLM was later followed by NTLMv2, which is the strongest authentication protocol of these three. NTLM is a challenge/response authentication protocol, which means the server sends a challenge to the client that the client then encrypts with a hash of its password and responds back to the server for validation.
Kerberos is a considerably more secure authentication protocol than NTLMv2. Kerberos provides server authentication in addition to client authentication. Unlike NTLM, Kerberos makes use of a trusted third party, called a Key Distribution Center (KDC), which maintains a database of secret keys. These secret keys are known only by the KDC and the entity requesting authentication. Knowledge of these keys proves the identity of the entity.
Where possible, the client should always try to use the most secure authentication mechanism. However, when the client is accessing the server via an external network, the server will offer only NTLMv2 authentication because the client will be unable to access the internal KDC, which runs on an Active Directory domain controller.
At the time a client issues its first request, no security associations (SA) are between the client and any entities in the network. An SA is an establishment of shared security information between two user agents to enable them to communicate securely. Typically, the first request a client issues is a REGISTER request when it registers its presence in the network. This registration process requires the establishment of SAs between the client and any proxies in the path that have proxy-level authentication enabled. In addition, the registrar might require authentication, establishing an SA between the client and the registrar.
The establishment of an SA is based on authentication using NTLM or Kerberos. Once an SA has been established, subsequent messages are signed using this SA. Multiple SAs might be established at this time, potentially one for each proxy along the signaling path and one for the registrar itself. Each of these SAs falls under the same security domain or realm.
To avoid resource denial because of an abundance of inactive SAs, SAs that are inactive are dropped by Office Communications Server. Inactive means no properly signed message has been received or sent within the time-to-live (TTL) interval. The TTL interval is determined based on the registration refresh interval or any other session timers in the dialogs that traverse the server. A client can avoid resource denial by issuing another request in the defined time period and signing with the SA. Any properly signed request refreshes the SA. The server resets the TTL interval of the SA every time it authenticates a request with that SA. An SA lives a maximum of 8 hours on the server, after which time the client must establish a new SA. The SA is valid for the maximum of either the lifetime of the Kerberos ticket (if Kerberos is used to establish the SA) or 8 hours.
Once an SA has been established between a client and server, the client might want to pre-authenticate future requests by inserting a Proxy-Authorization header with credentials matching the SAs for proxies that are likely to be on the signaling path for that request. Pre-authenticating requests avoids one round trip from having the client’s first hop server challenge a request, which it would do for a request without any Proxy-Authorization header.
Within a SIP dialog established by an INVITE, SUBSCRIBE, or REGISTER request, the client pre-authenticates the request by inserting the same set of Proxy-Authorization headers for all requests based on the proxies that challenged the first request of that session.
Additionally, the client keeps track of the SA that it established with the first authenticating proxy for REGISTER requests the client sends for registration. When the client receives a 401 or 407 challenge to a REGISTER request that is not signed by any other proxy (that is, there are no Proxy-Authentication-Info headers), the client remembers the SA established with this proxy. In all subsequent requests, the client pre-authenticates those requests by inserting a signature for the request using the SA established at registration time.
Note that in the case where a re-registration traverses a different path (and therefore has a different authenticating proxy), the new SA established with the new authenticating proxy replaces the old SA, and the client from that point onward pre-authenticates with the new SA.
During an NTLM SA establishment phase, a three-way handshake occurs between the client and the server, as detailed in the following steps.
The client sends a request with no credentials or authentication information. The server responds to that request with a 401 or 407 response, indicating that it supports NTLM and Kerberos and requires authentication.
The client re-issues the request, indicating its preference for NTLM authentication. The server responds with an appropriate challenge in a 401 or 407 response.
The client re-issues the request with a response to the server’s challenge. The server processes the request and responds, including its signature in the response.
The SA is now established on both the client and server, and subsequent messages between the client and server are signed.
The call flow shown in Figure 22-6 outlines how the NTLM authentication mechanism works for a local area network (LAN) user. At this point in time, the client discovers its outbound proxy and initializes a security context with it. The outbound proxy is determined by a Domain Name System (DNS) query and differs depending on whether the user is an extranet or intranet user. For extranet users, the Access Edge Server is the outbound proxy. For intranet users, the Director generally is the outbound proxy (however, the administrator can configure it differently).
The process is detailed in the following steps.
Ned’s client selects an Office Communications Server at random from a list of servers obtained from a DNS Service Record Locator (SRV) query. This server will be referred to as the outbound server.
Ned’s client sends a REGISTER request with no credentials (that is, no Proxy-Authorization header) to the outbound server it selected. In the following example, the FQDN of the server selected by Ned’s client is registrar.litwareinc.com.
REGISTER sip:registrar.litwareinc.com SIP/2.0 Via: SIP/2.0/TLS ned1.litwareinc.com;branch=z9hG4bK7 From: "Ned" <sip:[email protected]>;tag=354354535;epid=6534555 To: "Ned" <sip:[email protected]> Call-ID: [email protected] CSeq: 12345 REGISTER Max-Forwards: 70 User-Agent: Windows RTC/1.1.2600 Contact: "Ned" <sip:[email protected]> Content-Length: 0
The epid parameter on the From header uniquely identifies this particular endpoint of the user. The server uses this epid value in subsequent messages to determine the SA with which to sign the message. The server establishes a different SA for each endpoint (client) the user signs in from.
Authentication is enabled at the outbound server, and it challenges Ned’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 ned1.litwareinc.com;branch=z9hG4bK7 From: "Ned" <sip:[email protected]>;tag=354354535;epid=6534555 To: "Ned" <sip:[email protected]>;tag=5564566 Call-ID: [email protected] CSeq: 12345 REGISTER Date: Sat, 13 Nov 2010 23:29:00 GMT Proxy-Authenticate: Kerberos realm="SIP Communications Service", targetname="sip/hs1.litwareinc.com", qop="auth" Proxy-Authenticate: NTLM realm="SIP Communications Service", targetname="hs1. litwareinc.com", qop="auth" Content-Length: 0
The targetname parameter carries the FQDN of the outbound server for NTLM and the service principal name (SPN) of the outbound server for Kerberos. The actual contents of this parameter must be meaningful for this outbound server, but they 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 ability to do either Kerberos or NTLM authentication.
The outbound server inserts a Date header in the 407 challenge to enable the client to detect clock skew between the client and server. Both NTLMv2 and Kerberos V5 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 enables the client to log this condition and the administrator to correct the deviation.
The client re-issues the REGISTER request, indicating support for NTLM authentication.
REGISTER sip:registrar.litwareinc.com SIP/2.0 Via: SIP/2.0/TLS ned1.litwareinc.com;branch=z9hG4bK8 From: "Ned" <sip:[email protected]>;tag=354354535;epid=6534555 To: "Ned" <sip:[email protected]> Call-ID: [email protected] CSeq: 12346 REGISTER Max-Forwards: 70 User-Agent: Windows RTC/1.1.2600 Proxy-Authorization: NTLM realm="SIP Communications Service", targetname="hs1.litwareinc.com",qop="auth",gssapi-data="" Contact: "Ned" <sip:[email protected]> Content-Length: 0
The Cseq header value has been incremented. The Cseq header value is a command sequence number and is incremented by the client. The Call-ID and epid remain the same. The Call-ID header is used to uniquely identify a session between two clients.
The targetname parameter echoes the value of the targetname parameter in the previous Proxy-Authenticate header. The empty gssapi-data parameter indicates that no credentials (password) are being sent in this header. The choice of NTLM authentication is indicated by the scheme (NTLM) shown as the first token in the Proxy-Authorization header.
The outbound server responds with a 407 response containing a Proxy-Authenticate header, which includes the NTLM challenge.
SIP/2.0 407 Proxy Authentication Required Via: SIP/2.0/TLS ned1.litwareinc.com;branch=z9hG4bK8 From: "Ned" <sip:[email protected]>;tag=354354535;epid=6534555 To: "Ned" <sip:[email protected]>;tag=5564566 Call-ID: [email protected] CSeq: 12346 REGISTER Date: Sat, 13 Nov 2010 23:29:00 GMT Proxy-Authenticate: NTLM realm="SIP Communications Service", targetname="hs1.litwareinc.com", qop="auth", gssapi-data ="345435acdecbba",opaque="ACDC123" Content-Length: 0
The gssapi-data parameter carries the challenge. The opaque parameter serves as an index to the incomplete SA state on the outbound server.
Ned’s client re-issues the REGISTER request with a response to the outbound server’s challenge.
REGISTER sip:registrar.litwareinc.com SIP/2.0 Via: SIP/2.0/TLS ned1.litwareinc.com;branch=z9hG4bK9 From: "Ned" <sip:[email protected]>;tag=354354535;epid=6534555 To: "Ned" <sip:[email protected]> Call-ID: [email protected] CSeq: 12347 REGISTER Max-Forwards: 70 User-Agent: Windows RTC/1.1.2600 Proxy-Authorization: NTLM realm="SIP Communications Service", targetname="hs1.litwareinc.com",qop="auth", gssapi-data="34fcdf9345345",opaque="ACDC123" Contact: "Ned" <sip:[email protected]> Content-Length: 0
The Cseq header value has been incremented. The Call-ID and epid remain the same. The gssapi-data parameter carries the client’s response to the challenge. The opaque parameter is echoed from the previous challenge.
Upon receipt 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 Ned’s client.
The outbound server 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 ned1.litwareinc.com;branch=z9hG4bK9 From: "Ned" <sip:[email protected]>;tag=354354535;epid=6534555 To: "Ned" <sip:[email protected]> Call-ID: [email protected] CSeq: 12347 REGISTER Proxy-Authenticate-Info: NTLM realm="SIP Communications Service", targetname="hs1.litwareinc.com", qop="auth", opaque="ACDC123", srand="3453453", snum=1, rspauth="23423acfdee2" Contact: <sip:hs2.litwareinc.com> Content-Length: 0
The Proxy-Authenticate-Info header carries the signature for this SIP message. The snum parameter is set to 1 because 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 client receives the redirect response, verifies the signature by using the now complete SA for the outbound server, and re-issues the REGISTER request to its proper home server, hs2.litwareinc.com, as specified in the Contact header.
REGISTER sip:hs2.litwareinc.com SIP/2.0 Via: SIP/2.0/TLS ned1.litwareinc.com;branch=z9hG4bKa From: "Ned" <sip:[email protected]>;tag=354354535;epid=6534555 To: "Ned" <sip:[email protected]> Call-ID: [email protected] CSeq: 12348 REGISTER Max-Forwards: 70 User-Agent: Windows RTC/1.1.2600 Contact: "Ned" <sip:[email protected]> Content-Length: 0
The client replaces its current outbound server with the proxy indicated in the Contact header of the 301 response. The REGISTER request is sent to this new proxy, hs2.litwareinc.com (the user’s true home server). Because no SA exists yet with this new proxy, no Proxy-Authenticate header is present in the request.
Ned’s home server receives the REGISTER request and issues a challenge indicating support for NTLM and Kerberos authentication.
SIP/2.0 407 Proxy Authentication Required Via: SIP/2.0/TLS ned1.litwareinc.com;branch=z9hG4bKa From: "Ned" <sip:[email protected]>;tag=354354535;epid=6534555 To: "Ned" <sip:[email protected]>;tag=8823488 Call-ID: [email protected] CSeq: 12348 REGISTER Date: Sat, 13 Nov 2010 23:29:00 GMT Proxy-Authenticate: Kerberos realm="Litwareinc RTC Service Provider", targetname="hs2.litwareinc.com", qop="auth" Proxy-Authenticate: NTLM realm="SIP Communications Service", targetname="hs2.litwareinc.com", qop="auth" Content-Length: 0
The targetname parameter contains the FQDN for Ned’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.
Ned’s client receives the challenge, selects NTLM authentication, and re-issues the REGISTER request to his home server.
REGISTER sip:hs2.litwareinc.com SIP/2.0 Via: SIP/2.0/TLS ned1.litwareinc.com;branch=z9hG4bKb From: "Ned" <sip:[email protected]>;tag=354354535;epid=6534555 To: "Ned" <sip:[email protected]> Call-ID: [email protected] CSeq: 12349 REGISTER Max-Forwards: 70 User-Agent: Windows RTC/1.1.2600 Proxy-Authorization: NTLM realm="SIP Communications Service", targetname="hs2.litwareinc.com",qop="auth",gssapi-data="" Contact: "Ned" <sip:[email protected]> Content-Length: 0
The Cseq header value is incremented. The Call-ID and epid remain the same. The Proxy-Authorization header indicates support for NTLM authentication.
Ned’s home server receives the REGISTER request and issues an appropriate NTLM challenge.
SIP/2.0 407 Proxy Authentication Required Via: SIP/2.0/TLS ned1.litwareinc.com;branch=z9hG4bKb From: "Ned" <sip:[email protected]>;tag=354354535;epid=6534555 To: "Ned" <sip:[email protected]>;tag=8823488 Call-ID: [email protected] CSeq: 12349 REGISTER Date: Sat, 13 Nov 2010 23:29:00 GMT Proxy-Authenticate: NTLM realm="SIP Communications Service", targetname="hs2.litwareinc.com", qop="auth", opaque="CDEF1245", gssapi-data="dfd345435d" Content-Length: 0
The gssapi-data parameter contains the NTLM challenge. The opaque parameter identifies the incomplete SA on Ned’s home server.
Ned’s client responds to the challenge from Ned’s home server by re-issuing the REGISTER request.
REGISTER sip:hs2.litwareinc.com SIP/2.0 Via: SIP/2.0/TLS ned1.litwareinc.com;branch=z9hG4bKc From: "Ned" <sip:[email protected]>;tag=354354535;epid=6534555 To: "Ned" <sip:[email protected]> Call-ID: [email protected] CSeq: 12350 REGISTER Max-Forwards: 70 User-Agent: Windows RTC/1.1.2600 Proxy-Authorization: NTLM realm="SIP Communications Service", targetname="hs2.litwareinc.com",qop="auth", gssapi-data="8234934234", opaque="CDEF1245" Contact: "Ned" <sip:[email protected]> Content-Length: 0
The CSeq header value is incremented. The Call-ID remains the same. The opaque parameter is echoed from the server’s challenge. The gssapi-data parameter carries the response to the server’s challenge.
Ned’s home server receives the REGISTER request, verifies the response to its challenge, and processes the REGISTER request. The SA between Ned’s home server and Ned’s client is now complete. The server responds to the REGISTER request and signs the response by using the newly completed SA. The epid parameter from the From header is saved as part of the registration information for Ned. This value will be inserted in the To header of subsequent requests that are forwarded to Ned via his home server (registrar).
SIP/2.0 200 OK Via: SIP/2.0/TLS ned1.litwareinc.com;branch=z9hG4bKc From: "Ned" <sip:[email protected]>;tag=354354535;epid=6534555 To: "Ned" <sip:[email protected]>;tag=8823488 Call-ID: [email protected] CSeq: 12350 REGISTER Expires: 3600 Proxy-Authentication-Info: NTLM realm="SIP Communications Service", targetname="hs2.litwareinc.com", qop="auth", opaque="CDEF1245", rspauth="fefeacdd", srand=98984345, snum=1 Contact: "Ned" <sip:[email protected]> Content-Length: 0
The server uses the epid parameter on the From header 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.
During a Kerberos SA establishment phase, a two-way handshake occurs between the client and the server, as detailed in the following steps.
The client sends a request with no credential or authentication information. The server responds to that request with a 401 or 407 response, indicating that it supports NTLM and Kerberos and requires authentication.
The client requests a Kerberos ticket for the server from a KDC and re-issues the request with this encoded Kerberos ticket information.
The server processes the request and responds, including its signature in the response.
The SA is now established on both the client and server, and subsequent messages between the client and server are signed.
With Kerberos, the client first acquires a Kerberos ticket from the KDC (on an Active Directory domain controller) for the specific server that is issuing the challenge. The server is identified by an SPN containing a FQDN.
If the client is configured to talk to its local outbound proxy via Transport Layer Security (TLS), the client enables any SPN for the very first challenge it receives. Otherwise, the client requires that the SPN for the very first challenge it receives match sip:<FQDN of local outbound proxy>. The intention is to require either TLS connectivity to the service provider or the local outbound proxy to authenticate to the client. The SPN for a challenge is carried in the targetname parameter in the Proxy-Authenticate header of the challenge.
In the event the client receives a challenge with an SPN of any other form, particularly one that has a service other than "sip", the client ignores the challenge (response) and, as necessary, fails the request if no other final response is received. This action is taken to prevent an attacker from obtaining Kerberos tickets from the client for any other service besides Office Communications Server.
The SPN of the server is associated with the service account under which the Office Communications Server runs. This association is managed in Active Directory and initialized at the time of installation of the server. Any changes in either the FQDN or the service account of the server require the administrator to re-establish this association of SPN to server.
Note
The lifetime of the SA established using Kerberos is set to 8 hours (the same as for NTLM) regardless of the lifetime of the Kerberos ticket. If the Kerberos ticket expires before 8 hours, the underlying Security Support Provider Interface (SSPI) calls to verify or create a signature for a message will fail and, if possible, the server will challenge the request to establish a new SA.
The call flow shown in Figure 22-7 outlines how the Kerberos authentication mechanism works.
The process is detailed in the following steps.
Nina’s client selects a home server at random from a list of servers attained from a DNS SRV query.
Nina’s client sends a REGISTER request with no credentials (that is, no Proxy-Authorization header) to the outbound server it selected.
REGISTER sip:registrar.litwareinc.com SIP/2.0 Via: SIP/2.0/TLS ned1.litwareinc.com;branch=z9hG4bK7 From: "Nina" <sip:[email protected]>;tag=354354535;epid=6534555 To: "Nina" <sip:[email protected]> Call-ID: [email protected] CSeq: 12345 REGISTER Max-Forwards: 70 User-Agent: Windows RTC/1.1.2600 Contact: "Nina" <sip:[email protected]> 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 Nina’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 nina1.litwareinc.com;branch=z9hG4bK7 From: "Nina" <sip:[email protected]>;tag=354354535;epid=6534555 To: "Nina" <sip:[email protected]>;tag=5564566 Call-ID: [email protected] CSeq: 12345 REGISTER Date: Sat, 13 Nov 2010 23:29:00 GMT Proxy-Authenticate: Kerberos realm="SIP Communications Service", targetname="sip/hs1.litwareinc.com", qop="auth" Proxy-Authenticate: NTLM realm="Litwareinc RTC Service Provider", targetname="hs1.litwareinc.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 must be meaningful for this proxy, but they 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 ability to do either Kerberos or NTLM authentication.
The proxy inserts a Date header in the 407 challenge to enable the client to detect clock skew between the client and server. Both NTLMv2 and Kerberos V5 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 enables the client to log this condition and the administrator to correct the deviation.
The client acquires a Kerberos ticket for the outbound server indicated in the target-name of the Kerberos Proxy-Authenticate header. The client re-issues the request with a Proxy-Authorization header containing the encoded Kerberos ticket.
REGISTER sip:registrar.litwareinc.com SIP/2.0 Via: SIP/2.0/TLS nina1.litwareinc.com;branch=z9hG4bK9 From: "Nina" <sip:[email protected]>;tag=354354535;epid=6534555 To: "Nina" <sip:[email protected]> Call-ID: [email protected] CSeq: 12346 REGISTER Max-Forwards: 70 User-Agent: Windows RTC/1.1.2600 Proxy-Authorization: Kerberos realm="SIP Communications Service", targetname="sip/hs1.litwareinc.com",qop="auth", gssapi-data="34fcdf9345345" Contact: "Ned" <sip:[email protected]> Content-Length: 0
The Cseq header value 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.
Upon 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 Nina’s client.
The outbound server 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 nina1.litwareinc.com;branch=z9hG4bK9 From: "Nina" <sip:[email protected]>;tag=354354535;epid=6534555 To: "Nina" <sip:[email protected]> Call-ID: [email protected] CSeq: 12346 REGISTER Proxy-Authenticate-Info: Kerberos realm="SIP Communications Service", targetname="sip/hs1.litwareinc.com", qop="auth", opaque="ACDC123", srand="3453453", snum=1, rspauth="23423acfdee2" Contact: <sip:hs2.litwareinc.com> Content-Length: 0
The Proxy-Authenticate-Info header carries the signature for this SIP message. The snum parameter is set to 1 because this is the first message signed with the newly established SA. The srand parameter contains the random SALT value the server uses 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 re-issues the REGISTER request to its proper home server.
REGISTER sip:hs2.litwareinc.com SIP/2.0 Via: SIP/2.0/TLS nina1.litwareinc.com;branch=z9hG4bKa From: "Nina" <sip:[email protected]>;tag=354354535;epid=6534555 To: "Nina" <sip:[email protected]> Call-ID: [email protected] CSeq: 12347 REGISTER Max-Forwards: 70 User-Agent: Windows RTC/1.1.2600 Contact: "Nina" <sip:[email protected]> Content-Length: 0
The client replaces 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.
Nina’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 nina1.litwareinc.com;branch=z9hG4bKa From: "Nina" <sip:[email protected]>;tag=354354535;epid=6534555 To: "Nina" <sip:[email protected]>;tag=8823488 Call-ID: [email protected] CSeq: 12347 REGISTER Date: Sat, 13 Nov 2010 23:29:00 GMT Proxy-Authenticate: Kerberos realm="SIP Communications Service", targetname="sip/hs2.litwareinc.com", qop="auth" Proxy-Authenticate: NTLM realm="Litwareinc RTC Service Provider", targetname="hs2.litwareinc.com", qop="auth" Content-Length: 0
The targetname parameter for Kerberos contains the SPN for Nina’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.
Nina’s client receives the challenge, selects Kerberos authentication, and re-issues the REGISTER request to her home server. The client acquires a Kerberos ticket for HS2 and includes this information in the gssapi-data parameter of the Proxy-Authorization header.
REGISTER sip:hs2.litwareinc.com SIP/2.0 Via: SIP/2.0/TLS nina1.litwareinc.com;branch=z9hG4bKc From: "Nina" <sip:[email protected]>;tag=354354535;epid=6534555 To: "Nina" <sip:[email protected]> Call-ID: [email protected] CSeq: 12348 REGISTER Max-Forwards: 70 User-Agent: Windows RTC/1.1.2600 Proxy-Authorization: Kerberos realm="SIP Communications Service", targetname="sip/hs2.litwareinc.com",qop="auth", gssapi-data="8234934234", opaque="CDEF1245" Contact: "Ned" <sip:[email protected]> Content-Length: 0
The Cseq header value is incremented. The Call-ID and epid remain the same. The Proxy-Authorization header indicates support for Kerberos authentication.
Nina’s home server receives the REGISTER request, verifies the Kerberos ticket, and processes the REGISTER request. The SA between Nina’s home server and Nina’s client is now complete. The server responds to the REGISTER request and signs the response by using the newly completed SA. The epid parameter from the From header is saved as part of the registration information for Nina. This value will be inserted in the To header of subsequent requests that are forwarded to Nina via her home server (registrar).
SIP/2.0 200 OK Via: SIP/2.0/TLS nina1.litwareinc.com;branch=z9hG4bKc From: "Nina" <sip:[email protected]>;tag=354354535;epid=6534555 To: "Nina" <sip:[email protected]>;tag=8823488 Call-ID: [email protected] CSeq: 12348 REGISTER Expires: 3600 Proxy-Authentication-Info: Kerberos realm="SIP Communications Service", targetname="sip/hs2.litwareinc.com", qop="auth", opaque="CDEF1245", rspauth="fefeacdd", srand=98984345, snum=1 Contact: "Nina" <sip:[email protected]> Content-Length: 0
The server uses the epid parameter on the From header to determine how to sign this response (that is, to 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.
The server generally challenges with a 407 response. The headers associated with proxy authentication are Proxy-Authenticate, Proxy-Authentication-Info, and Proxy-Authorization. The format and content of these headers correspond to the WWW-Authenticate, Authentication-Info, and Authorization headers, respectively, which are used in conjunction with a 401 response. Either a 401 or a 407 response achieves the goals of this document.
The server inserts a Date header into all 407 responses to the client so that the client can detect clock skew, which can cause NTLMv2 and Kerberos V5 authentication to fail.
The Proxy-Authenticate header is used to signal that a proxy requires authentication and to carry a challenge (from a proxy) during the SA initialization phase. The server initially inserts one Proxy-Authenticate header for every authentication method it supports (for example, NTLM, Kerberos, and so on). In the event the request has been forked, it is also possible to receive a 407 response containing a list of Proxy-Authenticate headers—one for each proxy that requested authentication.
The Proxy-Authorization header is used to carry the client’s response to a challenge from an Office Communications Server (proxy). A client also uses it in signing a request or response. There might be more than one Proxy-Authorization header in a given request/response—one for each proxy with which the client has an SA established on this signaling path.
The Proxy-Authentication-Info header is used to carry the signature created by the Office Communications Server for a request or response once an SA has been established with the client.
The protocol information used during the SA establishment phase differs from the information used once an SA has been established. During the establishment phase, the gssapi-data parameter carries the bulk of the credentials information. The realm parameter provides additional context information. Once an SA has been established, the srand, crand, cnum, snum, and opaque parameters are used in the signing of requests and responses. Those signatures are carried in the response and rspauth parameters.
In the event that problems occur while signing in to Office Communications Server, a 401 response might be sent back to the client even though users have provided valid sign-in credentials. This can occur if you have configured Office Communications Server to use Kerberos authentication and one of the following is true:
NetBIOS is disabled on the computer
The computer is running Microsoft Windows XP Home Edition
The computer is configured to run behind an Internet Connection Sharing device or behind another Universal Plug and Play (UPnP) Network Address Translation (NAT) device
The computer is not joined to the same domain as the Office Communications Server computer
The account is disabled, or time-based restrictions apply to the account login
In certain Office Communications Server topologies, you cannot successfully sign in by entering your credentials in the user principal name (UPN) format ([email protected]). You might have to specify the FQDN together with your user name when you enter it in Universal Naming Convention (UNC) format to successfully sign in. For example, when you type your user name information in a dialog box, you might have to use the following format to successfully sign in:
domain.example.comusername
Where domain.example.com is the FQDN of your domain, and username is your user name. If entering the FQDN of your domain does not work, try enabling NTLM instead of Kerberos.