4.1 NTLM Authentication Example
Alice's SIP protocol client sends a REGISTER request with no authorization header field to the SIP server.
REGISTER sip:contoso.com SIP/2.0 Via: SIP/2.0/TLS 192.0.2.1:4320 From: <sip:alice@contoso.com>;tag=4a2b44d131;epid=8248ca9ebb To: <sip:alice@contoso.com> Call-ID: d5f2b95d5be64c2cbfb38aa5d3a87ae7 CSeq: 169 REGISTER Contact: <sip:192.0.2.1:4320;transport=tls>;proxy=replace;+sip.instance="<urn:uuid:4233FD41-093B-5FD6-B5D2-651ED55969E6>" UserAgent: UCCP/2.0.6362.0 OC/2.0.6362.0 (Microsoft Office Communicator) Supported: gruu-10 Content-Length: 0
Authentication is enabled at the server, which then challenges Alice's protocol client. The server indicates support for NTLM and Kerberos in the challenge and returns the realm and targetname values that it created during initialization, the version of the authentication protocol that it implements, and the Date header field.
SIP/2.0 401 Unauthorized Date: Thu, 31 Jan 2008 00:01:56 GMT WWW‑Authenticate: NTLM realm="SIP Communications Service", targetname="server.contoso.com", version=3 WWW‑Authenticate: Kerberos realm="SIP Communications Service", targetname="sip/server.contoso.com", version=3 From: <sip:alice@contoso.com>;tag=4a2b44d131;epid=8248ca9ebb To: <sip:alice@contoso.com>;tag=0858513FA91D3AAE1A5840DDB99599DF Call-ID: d5f2b95d5be64c2cbfb38aa5d3a87ae7 CSeq: 169 REGISTER Via: SIP/2.0/TLS 192.0.2.1:4320;ms-received-cid=1C500 Content-Length: 0
The protocol client decides to use NTLM and creates an SA with data from the authentication header, specifically, NTLM, realm, targetname, and version. It calls the NTLM authentication protocol implementation with Alice's credentials (user name, domain, and password) and Datagram, Identify, and Integrity parameters, to initialize the security context and generate NEGOTIATE_MESSAGE. In the current NTLM implementation, this message is not generated for datagram NTLM contexts, so the output from NTLM is an empty buffer. Thus, the protocol client generates an authorization header field and sends the following request to the server.
REGISTER sip:contoso.com SIP/2.0 Via: SIP/2.0/TLS 192.0.2.1:4320 From: <sip:alice@contoso.com>;tag=4a2b44d131;epid=8248ca9ebb To: <sip:alice@contoso.com> Call-ID: d5f2b95d5be64c2cbfb38aa5d3a87ae7 CSeq: 170 REGISTER Authorization: NTLM qop="auth", realm="SIP Communications Service", targetname="server.contoso.com", gssapi-data="", version=3 Contact: <sip:192.0.2.1:4320;transport=tls>;proxy=replace;+sip.instance="<urn:uuid:4233FD41-093B-5FD6-B5D2-651ED55969E6>" UserAgent: UCCP/2.0.6362.0 OC/2.0.6362.0 (Microsoft Office Communicator) Supported: gruu-10 Content-Length: 0
The server extracts the protocol client endpoint identity as the address-of-record in the From header field ("alice@contoso.com") and either the value of the epid parameter in the From header field ("8248ca9ebb") or the value of the +sip.instance parameter in the Contact header field ("urn:uuid:4233FD41093B5FD6B5D2651ED55969E6"). It creates the SA for the NTLM protocol, initializing it with the protocol client endpoint identifier, version (3), generated opaque value ("BCDC0C9D"), and calls into the NTLM implementation to process an empty NEGOTIATE_MESSAGE. The NTLM implementation creates the security context and generates a CHALLENGE_MESSAGE token that the server encodes and sends back to the protocol client in the following 401 Unauthorized response.
SIP/2.0 401 Unauthorized Date: Thu, 31 Jan 2008 00:01:56 GMT WWW‑Authenticate: NTLM opaque="BCDC0C9D", gssapi-data="12345678ABCDEF", targetname="server.contoso.com", realm="SIP Communications Service", version=3 From: <sip:alice@contoso.com>;tag=4a2b44d131;epid=8248ca9ebb To: <sip:alice@contoso.com>;tag=0858513FA91D3AAE1A5840DDB99599DF Call-ID: d5f2b95d5be64c2cbfb38aa5d3a87ae7 CSeq: 170 REGISTER Via: SIP/2.0/TLS 192.0.2.1:4320;ms-received-cid=1C500 Content-Length: 0
The protocol client locates the SA which it created for the first challenge message from the server, decodes the value of the gssapi-data parameter using the base64 algorithm, and passes it along as the security context information stored in the SA down to the NTLM implementation as CHALLENGE_MESSAGE. The NTLM implementation generates AUTHENTICATE_MESSAGE, which the protocol client encodes using the base64 algorithm, generates the authorization header field, and sends the following request to the server.
REGISTER sip:contoso.com SIP/2.0 Via: SIP/2.0/TLS 192.0.2.1:4320 From: <sip:alice@contoso.com>;tag=4a2b44d131;epid=8248ca9ebb To: <sip:alice@contoso.com> Call-ID: d5f2b95d5be64c2cbfb38aa5d3a87ae7 CSeq: 171 REGISTER Authorization: NTLM opaque="BCDC0C9D", qop="auth", realm="SIP Communications Service", targetname="server.contoso.com", gssapi-data="12345678ABCDE", version=3 Contact: <sip:192.0.2.1:4320;transport=tls>;proxy=replace;+sip.instance="<urn:uuid:4233FD41-093B-5FD6-B5D2-651ED55969E6>" UserAgent: UCCP/2.0.6362.0 OC/2.0.6362.0 (Microsoft Office Communicator) Supported: gruu-10 Content-Length: 0
The server extracts the protocol client endpoint identity from the request and the opaque value from the authorization header field, finds the existing SA and calls into the NTLM implementation to process AUTHENTICATE_MESSAGE. The NTLM implementation authenticates the protocol client. The server then extracts the user identity from the authentication protocol context and validates that the user is authorized to use the "alice@contoso.com" address-of-record. The server can now continue processing the REGISTER request, as described in [RFC3261], and pass it to the SIP registrar component.
After the SIP registrar component completes processing, it sends back a 200 OK response to the protocol client, which is processed by the authentication component on the server. This component locates the SA based on the reference it stored in the Via header field, or some other mechanism, and calls into the NTLM authentication protocol implementation to generate a signature token for the response. Based on the contents of the response shown in the following example, the server constructs the following buffer for the GSS_GetMic() call to NTLM.
<NTLM><0B9D33A2><1><SIP Communications Service><server.contoso.com><d5f2b95d5be64c2cbfb38aa5d3a87ae7><171><REGISTER><sip:alice@contoso.com><4a2b44d131><sip:alice@contoso.com><0858513FA91D3AAE1A5840DDB99599DF><><><7200><200>
NTLM returns the signature, and the server creates an authentication information header field and sends the following message to the protocol client.
SIP/2.0 200 OK Authentication‑Info: NTLM rspauth="01000000000000005CD422F0C750C7C6", srand="0B9D33A2", snum="1", opaque="BCDC0C9D", qop="auth", targetname="server.contoso.com", realm="SIP Communications Service" From: <sip:alice@contoso.com>;tag=4a2b44d131;epid=8248ca9ebb To: <sip:alice@contoso.com>;tag=0858513FA91D3AAE1A5840DDB99599DF Call-ID: d5f2b95d5be64c2cbfb38aa5d3a87ae7 CSeq: 171 REGISTER Via: SIP/2.0/TLS 192.0.2.1:4320;ms-received-cid=1C500 Contact: <sip:192.0.2.1:4320;transport=tls;msreceivedcid=1C500>;expires=7200;+sip.instance="<urn:uuid:4233fd41093b5fd6b5d2651ed55969e6>";gruu="sip:alice@contoso.com;opaque=user:epid:Qf0zQjsJ1l10mUe1Vlp5gAA;gruu" Expires: 7200 Content-Length: 0
The protocol client receives the message, locates the SA, and uses it to call into the NTLM implementation to verify the signature using its GSS_VerifyMIC call. The buffer that the protocol client creates for signature verification is identical to the buffer created by the server when it generated the signature.