Authentication is the process of determining if someone is in fact who he says he is. There are several different types of authentication technologies. For example, in computer networks, typically authentication is done by the use of logon passwords. However, passwords can be stolen or accidentally revealed. For this reason, there is a more stringent authentication process. For example, digital certificates issued and verified by a certificate authority (CA) as part of a public key infrastructure (PKI) provides stronger authentication on the Internet.
The following sections discuss in more detail authentication technologies—such as Transport Layer Security (TLS), certificates, NTLM and Kerberos—that are used by Office Communications Server.
You can configure TLS and certificates within your Office Communications Server 2007 deployment. Using TLS and certificates has the following benefits:
Confidentiality Data that is transferred between clients and servers needs to be encrypted to prevent its exposure over public Internet links.
Mutual Server authentication Servers need a way to verify the identity of each other during communication.
Office Communications Server 2007 uses certificates for the following purposes:
TLS connections between client and server
Mutual transport layer security (MTLS) connections between servers
Federation between partners
Remote access
Note
Certificates are discussed in more detail in Chapter 3.
Transport Layer Security (TLS) is a protocol that ensures privacy between communicating applications and their users on the Internet. TLS ensures that no third party can eavesdrop or tamper with any message between the client and the server.
As described in RFC 2246, TLS is composed of two layers: the TLS Record Protocol and the TLS Handshake Protocol. The TLS Record Protocol provides connection security with some encryption method, such as the Data Encryption Standard (DES). The TLS Record Protocol can also be used without encryption. The TLS Handshake Protocol allows the server and client to authenticate each other and to negotiate an encryption algorithm and cryptographic keys before data is exchanged.
Figure 18-8 is an example of the call flow of a TLS handshake over the network as described in RFC 2246.
Note
In Figure 18-8 an asterisk (*) indicates optional or situation-dependent messages that are not always sent.
The TLS Handshake Protocol as described in RFC 2246 involves the following steps:
Exchange hello messages to agree on algorithms, exchange random values, and check for session resumption.
Exchange the necessary cryptographic parameters to allow the client and server to agree on a premaster secret.
Exchange certificates and cryptographic information to allow the client and server to authenticate themselves.
Generate a master secret from the premaster secret and exchanged random values.
Allow the client and server to verify that their peer has calculated the same security parameters and that the handshake occurred without tampering by an attacker.
The client sends a client hello message to which the server responds with a server hello message. The client hello and server hello are used to establish security enhancement capabilities between client and server. The client hello and server hello establish the following attributes: Protocol Version, Session ID, Cipher Suite, and Compression Method. Additionally, two random values are generated and exchanged: ClientHello.random and ServerHello.random.
The actual key exchange uses up to four messages: the server certificate, server key exchange, client certificate, and client key exchange. New key exchange methods can be created by specifying a format for these messages and defining the use of the messages to allow the client and server to agree upon a shared secret. This secret should be long. Currently defined key exchange methods exchange secrets that range from 48 to 128 bytes in length.
Following the hello messages, the server sends its certificate if it needs to be authenticated. Additionally, a server key exchange message might be sent if it is required. If the server is authenticated, it might request a certificate from the client, depending on the cipher suite selected. The server then sends the server hello done message, which indicates that the hello-message phase of the handshake is complete. The server then waits for a client response. If the server has sent a certificate request message, the client must send the certificate message. The client key exchange message is now sent, and the content of that message depends on the public key algorithm selected between the client hello and the server hello. If the client has sent a certificate with signing ability, a digitally-signed certificate verify message is sent to explicitly verify the certificate.
At this point, a change cipher spec message is sent by the client, and the client copies the pending Cipher Spec into the current Cipher Spec. The client then immediately sends the finished message under the new algorithms, keys, and secrets. In response, the server sends its own change cipher spec message, transfers the pending Cipher Spec to the current Cipher Spec, and sends its finished message under the new Cipher Spec. At this point, the handshake is complete and the client and server can begin to exchange application layer data.
TLS connections are recycled every 24 hours between servers. Similarly, idle TLS connections are recycled every 15 minutes.
Note
For more information on how to adjust the cipher suites and the key exchange algorithms, see http://support.microsoft.com/kb/216482 and http://support.microsoft.com/kb/245030.
There are two enterprise user authentication mechanisms supported in Office Communications Server: NTLM and Kerberos. Anonymous conference participants are authenticated using Digest authentication.
NT Lan Manager (NTLM) is a Microsoft authentication protocol that is the successor of Microsoft Lan Manager (LANMAN). NTLM is a challenge/response authentication protocol. NTLM was followed by NTLM v2, the strongest authentication protocol of these three. NTLM v2 is a cryptographically strengthened replacement for NTLM v1.
Kerberos is a considerably more secure authentication protocol than NTLM v2. Kerberos provides mutual authentication as opposed to only client authentication. With NTLM, the client is challenged to provide credentials, but the client could be providing credentials to a bogus server. Kerberos, on the other hand, provides server authentication in addition to the 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, as well as by the client and the server. Knowledge of these keys prove the client or server identity.
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 NTLM v2 authentication because the client will be unable to assess the internal KDC or Active Directory.
The Direct from the Source: How NTLM and Kerberos Work in SIP sidebar describes in more detail the process of authentication using NTLM and Kerberos.
Direct from the Source: How NTLM and Kerberos Work in SIP
At the time a client issues its first request, there are no security associations (SA) between the client and any entities in the network. An SA is an establishment of shared security information between two endpoints to enable them to communicate securely. Typically, the first request a client issues is a REGISTER request as 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 as well, 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.
For more information on NTLM and Kerberos requirements, see http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/523ae943-5e6a-4200-9103-9808baa00157.mspx?mfr=true.
Refreshing a Security Association
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 time-to-live interval of the SA every time it authenticates a request with that SA. An SA lives a maximum of eight hours on the server, after which time a new SA must be established by the client. 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.
Pre-Authentication of a Message
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/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 on pre-authenticates with the new SA.
Example of NTLM in SIP
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 18-9 on the next page 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 process is detailed in the following steps:
Ned's client selects a home server at random from a list of servers attained from a DNS SRV query.
Ned's client sends a REGISTER request with no credentials (that is, no Proxy-Authorization: header) to the outbound server it selected.
REGISTER sip:registrar.northwind.com SIP/2.0 Via: SIP/2.0/TLS ned1.northwind.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 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 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.northwind.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.northwind.com", qop="auth" Proxy-Authenticate: NTLM realm="SIP Communications Service", targetname="hs1.northwind.com", qop="auth" Content-Length: 0
The targetname parameter carries the FQDN for this proxy for NTLM and the service principal name (SPN) of the proxy for Kerberos. 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. Three 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 allow 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 allows 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.northwind.com SIP/2.0 Via: SIP/2.0/TLS ned1.northwind.com;branch=z9hG4bK8 From: "Ned" <sip:[email protected]>;tag=354354535;epid="6534555 To: -id002"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.northwind.com",qop="auth",gssapi-data="" Contact: "Ned" <sip:[email protected]> 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 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 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.northwind.com;branch=z9hG4bK8 From: "Ned" <sip:[email protected]>;tag=354354535;epid="6534555 To: -id003"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.northwind.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 proxy.
Ned's client re-issues the REGISTER request with a response to the outbound server's challenge.
REGISTER sip:registrar.northwind.com SIP/2.0 Via: SIP/2.0/TLS ned1.northwind.com;branch=z9hG4bK9 From: "Ned" <sip:[email protected]>;tag=354354535;epid="6534555 To: -id004"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.northwind.com",qop="auth", gssapi-data="34fcdf9345345",opaque="ACDC123" Contact: "Ned" <sip:[email protected]> Content-Length: 0
The Cseq number 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 a security association 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.northwind.com;branch=z9hG4bK9 From: "Ned" <sip:[email protected]>;tag=354354535;epid="6534555 To: -id005"Ned" <sip:[email protected]> Call-ID: [email protected] CSeq: 12347 REGISTER Proxy-Authenticate-Info: NTLM realm="SIP Communications Service", targetname="hs1.northwind.com", qop="auth", opaque="ACDC123", srand="3453453", snum=1, rspauth="23423acfdee2" Contact: <sip:hs2.northwind.com> Content-Length: 0
The Proxy-Authenticate-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 client receives the redirect response, verifies the signature by using the now complete SA for the outbound proxy, and it re-issues the REGISTER request to its proper home server.
REGISTER sip:hs2.northwind.com SIP/2.0 Via: SIP/2.0/TLS ned1.northwind.com;branch=z9hG4bKa From: "Ned" <sip:[email protected]>;tag=354354535;epid="6534555 To: -id006"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 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-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.northwind.com;branch=z9hG4bKa From: "Ned" <sip:[email protected]>;tag=354354535;epid="6534555 To: -id007"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="Northwind RTC Service Provider", targetname="hs2.northwind.com", qop="auth" Proxy-Authenticate: NTLM realm="SIP Communications Service", targetname="hs2.northwind.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.northwind.com SIP/2.0 Via: SIP/2.0/TLS ned1.northwind.com;branch=z9hG4bKb From: "Ned" <sip:[email protected]>;tag=354354535;epid="6534555 To: -id008"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.northwind.com",qop="auth",gssapi-data="" Contact: "Ned" <sip:[email protected]> Content-Length: 0
The Cseq: number 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.northwind.com;branch=z9hG4bKb From: "Ned" <sip:[email protected]>;tag=354354535;epid="6534555 To: -id009"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.northwind.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.northwind.com SIP/2.0 Via: SIP/2.0/TLS ned1.northwind.com;branch=z9hG4bKc From: "Ned" <sip:[email protected]>;tag=354354535;epid="6534555 To: -id010"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.northwind.com",qop="auth", gssapi-data="8234934234", opaque="CDEF1245" Contact: "Ned" <sip:[email protected]> Content-Length: 0
The CSeq number 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 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.northwind.com;branch=z9hG4bKc From: "Ned" <sip:[email protected]>;tag=354354535;epid="6534555 To: -id011"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.northwind.com", qop="auth", opaque="CDEF1245", rspauth="fefeacdd", srand=98984345, snum=1 Contact: "Ned" <sip:[email protected]> 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.
Example of Kerberos in SIP
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 and reissues 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.
The fundamental difference between NTLM 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 (on an Active Directory domain controller) for the specific server that is issuing the challenge. The server is identified by a SPN containing a fully qualified domain name (FQDN).
If the client is configured to talk to its local outbound proxy via TLS, the client allows 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 that the local outbound proxy authenticates 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 requires the administrator to re-establish this association of SPN to server. Re-establishing the association is a manual process that the administrator must perform after installation.
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 18-10 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.northwind.com SIP/2.0 Via: SIP/2.0/TLS ned1.northwind.com;branch=z9hG4bK7 From: "Nina" <sip:[email protected]>;tag=354354535;epid="6534555 To: -id012"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.northwind.com;branch=z9hG4bK7 From: "Nina" <sip:[email protected]>;tag=354354535;epid="6534555 To: -id013"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.northwind.com", qop="auth" Proxy-Authenticate: NTLM realm="Northwind RTC Service Provider", targetname="hs1.northwind.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 allow 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 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 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.northwind.com SIP/2.0 Via: SIP/2.0/TLS nina1.northwind.com;branch=z9hG4bK9 From: "Nina" <sip:[email protected]>;tag=354354535;epid="6534555 To: -id014"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.northwind.com",qop="auth", gssapi-data="34fcdf9345345" contact: "Ned" <sip:[email protected]> 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.
Upon reception of the REGISTER request, the outbound server authenticates the user with the information in the Proxy-Authorization: header. Authentication succeeds, and a security association 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.northwind.com;branch=z9hG4bK9 From: "Nina" <sip:[email protected]>;tag=354354535;epid="6534555 To: -id015"Nina" <sip:[email protected]> Call-ID: [email protected] CSeq: 12346 REGISTER Proxy-Authenticate-Info: Kerberos realm="SIP Communications Service", targetname="sip/hs1.northwind.com", qop="auth", opaque="ACDC123", srand="3453453", snum=1, rspauth="23423acfdee2" Contact: <sip:hs2.northwind.com> Content-Length: 0
The Proxy-Authenticate-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 re-issues the REGISTER request to its proper home server.
REGISTER sip:hs2.northwind.com SIP/2.0 Via: SIP/2.0/TLS nina1.northwind.com;branch=z9hG4bKa From: "Nina" <sip:[email protected]>;tag=354354535;epid="6534555 To: -id016"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.northwind.com;branch=z9hG4bKa From: "Nina" <sip:[email protected]>;tag=354354535;epid="6534555 To: -id017"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.northwind.com", qop="auth" Proxy-Authenticate: NTLM realm="Northwind RTC Service Provider", targetname="hs2.northwind.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.northwind.com SIP/2.0 Via: SIP/2.0/TLS nina1.northwind.com;branch=z9hG4bKc From: "Nina" <sip:[email protected]>;tag=354354535;epid="6534555 To: -id018"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.northwind.com",qop="auth", gssapi-data="8234934234", opaque="CDEF1245" Contact: "Ned" <sip:[email protected]> 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.
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 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.northwind.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.northwind.com", qop="auth", opaque="CDEF1245", rspauth="fefeacdd", srand=98984345, snum=1 Contact: "Nina" <sip:[email protected]> Content-Length: 0
The epid parameter on the From: header is used by the server 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 Proxy Authentication Required" 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 Unauthorized" response. Either a "401" or "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). It is also used by a client 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.
–Sean Olson
Principal Group Program Manager, OCS Server
In the event that problems occur while signing into Office Communications Server 2007, a "401" response might be sent back even though users have provided valid sign-in credentials. This can occur if you have configured Office Communications Server 2007 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]). Additionally, 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 into a dialog box, you might have to use the following format to successfully sign in:
domain.example.comusername
In this format, 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.
NTLM version 1 was used in legacy operating systems such as Windows NT and Windows 98. Recent improvements in computer hardware and software algorithms have made these protocols vulnerable to widely published attacks for obtaining user passwords. In its ongoing efforts to deliver more secure products to its customers, Microsoft has developed an enhancement, called NTLM version 2, that significantly improves both the authentication and session security mechanisms. You can enable NTLM version 2 on these legacy operating systems, thereby preventing the weaker NTLM version 1 from being used. For more information on how to enable NTLM version 2, see http://support.microsoft.com/kb/239869.