Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
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:4849 From: <sip:alice@contoso.com>;tag=604168c9c0;epid=2ebb6f264f To: <sip:alice@contoso.com> Call-ID: c7142b90f8c94668807a382f552a6770 CSeq: 1 REGISTER Contact: <sip:192.0.2.1:4849;transport=tls>;proxy=replace;+sip.instance="<urn:uuid:124841E4-264D-52E8-96C5-D22AA8CDC316>" 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: Sun, 16 Dec 2007 05:11:19 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=604168c9c0;epid=2ebb6f264f To: <sip:alice@contoso.com>;tag=9588410E2DA11CEE9D0AE7733E07830F Call-ID: c7142b90f8c94668807a382f552a6770 CSeq: 1 REGISTER Via: SIP/2.0/TLS 192.0.2.1:4849;ms-received-cid=900 Content-Length: 0
The protocol client decides to use Kerberos and creates an SA with data from the authentication header field, specifically, Kerberos, realm, targetname, and version. It obtains a Kerberos ticket for the service principal (2) in the targetname parameter ("sip/server.contoso.com"), and calls the Kerberos authentication protocol implementation with it and the Identify and Integrity parameters to initialize the security context and generate a KRB_AP_REQ token. The protocol client encodes the Kerberos token, using the base64 algorithms, and sends the following request to the server.
REGISTER sip:contoso.com SIP/2.0 Via: SIP/2.0/TLS 192.0.2.1:4849 From: <sip:alice@contoso.com>;tag=604168c9c0;epid=2ebb6f264f To: <sip:alice@contoso.com> Call-ID: c7142b90f8c94668807a382f552a6770 CSeq: 2 REGISTER Authorization: Kerberos qop="auth", realm="SIP Communications Service", targetname="sip/server.contoso.com", gssapi-data="1234ABCDEF", version=3 Contact: <sip:192.0.2.1:4849;transport=tls>;proxy=replace;+sip.instance="<urn:uuid:124841E4-264D-52E8-96C5-D22AA8CDC316>" 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 ("2ebb6f264f") or the value of the +sip.instance parameter in the Contact header field ("urn:uuid:124841E4-264D-52E8-96C5-D22AA8CDC316"). It creates the SA for the Kerberos protocol, initializing it with a protocol client endpoint identifier, version, the generated opaque value ("A9A0BB9C"), and calls into the Kerberos implementation to initialize the security context and process the KRB_AP_REQ token. The Kerberos 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. The component locates the SA based on the reference it stored in the Via header field, or on some other mechanism, and calls into the Kerberos authentication protocol implementation to generate a signature token for the response. Based on the content of the following response, the server constructs the following buffer for the GSS_GetMic() call to Kerberos.
<Kerberos><211639C4><1><SIP Communications Service><sip/server.contoso.com><c7142b90f8c94668807a382f552a6770><2><REGISTER><sip:alice@contoso.com><604168c9c0><sip:alice@contoso.com><9588410E2DA11CEE9D0AE7733E07830F><><><7200><200>
Kerberos 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: Kerberos rspauth="602306092", srand="211639C4", snum="1", opaque="A9A0BB9C", qop="auth", targetname="sip/server.contoso.com", realm="SIP Communications Service" From: <sip:alice@contoso.com>;tag=604168c9c0;epid=2ebb6f264f To: <sip:alice@contoso.com>;tag=9588410E2DA11CEE9D0AE7733E07830F Call-ID: c7142b90f8c94668807a382f552a6770 CSeq: 2 REGISTER Via: SIP/2.0/TLS 192.0.2.1:4849;ms-received-cid=900 Contact: <sip:192.0.2.1:4849;transport=tls;msreceivedcid=900>;expires=7200;+sip.instance="<urn:uuid:124841E4264D52E896C5D22AA8CDC316>";gruu="sip:alice@contoso.com;opaque=user:epid:5EFIEk0m6FKWxdIqqM3DFgAA;gruu" Expires: 7200 Content-Length: 0
The protocol client receives the message, locates the SA, and uses it to call into the Kerberos implementation to verify the signature using its GSS_VerifyMIC call. The buffer that it creates for signature verification is identical to the buffer created by the server when it generated the signature.