4.4 TLS-DSK Authentication Example for version 4 of the protocol

Article
11/16/2021

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=22fafb15b8;epid=2ebb6f264f
 To: <sip:alice@contoso.com>
 Call-ID: d5f2b95d5be64c2cbfb38aa5d3a87ae7
 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 client. The server indicates support for TLS-DSK, Kerberos, and NTLM 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: TLS-DSK realm="SIP Communications Service", targetname="server.contoso.com", version=4
 WWW-Authenticate: Kerberos realm="SIP Communications Service", targetname="sip/server.contoso.com", version=4
 WWW-Authenticate: NTLM realm="SIP Communications Service", targetname="server.contoso.com", version=4
 From: <sip:alice@contoso.com>;tag=22fafb15b8;epid=2ebb6f264f
 To: <sip:alice@contoso.com>;tag=9588410E2DA11CEE9D0AE7733E07830F
 Call-ID: d5f2b95d5be64c2cbfb38aa5d3a87ae7
 CSeq: 1 REGISTER
 Via: SIP/2.0/TLS 192.0.2.1:4849;ms-received-cid=900
 Content-Length: 0

The client decides to use TLS-DSK and creates an SA with data from the authentication header field, specifically TLS-DSK, realm, targetname, and version. It uses the TLS protocol implementation to generate a client_hello handshake message, which the client then encodes as the gssapi-data parameter, using the base64 algorithm, 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: d5f2b95d5be64c2cbfb38aa5d3a87ae7
 CSeq: 2 REGISTER
 Authorization: TLS-DSK qop="auth", realm="SIP Communications Service", targetname="server.contoso.com", gssapi-data="FgMBAJMBAACPAwFJ5nVu5crf6v0bJApguL4gJbjafFaRyH7qNr", version=4
 Contact: <sip:192.0.2.1:4849;transport=tls>;proxy=replace;+sip.instance="<urn:uuid:124841E4-264D-52E8-96C5-D22AA8CDC316>"
 User Agent: UCCP/2.0.6362.0 OC/2.0.6362.0 (Microsoft Office Communicator)
Supported: gruu-10
Content-Length: 0

The server extracts the 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:124841E4264D52E896C5D22AA8CDC316"). It creates the SA for the TLS-DSK protocol, initializing it with the client endpoint identifier, version ("3"), generated opaque value ("72118CF0"), and calls into the TLS implementation to process a client_hello message. The TLS implementation creates the negotiation context and generates a response that encapsulates several TLS records containing a TLS server_hello handshake message, followed by a TLS certificate, such as server_key_exchange, and then certificate_request and server_hello_done handshake messages. The server encodes the TLS response as the gssapi-data parameter, using the base64 algorithm, and sends it back to the client in the following 401 Unauthorized response.
```
 SIP/2.0 401 Unauthorized
 WWW-Authenticate: TLS-DSK opaque="72118CF0", gssapi-data="FgMBCJasdasd", targetname="server.contoso.com", realm="SIP Communications Service", version=4
 From: <sip:alice@contoso.com>;tag=4a2b44d131;epid=8248ca9ebb
 To: <sip:alice@contoso.com>;tag=0858513FA91D3AAE1A5840DDB99599DF
 Call-ID: d5f2b95d5be64c2cbfb38aa5d3a87ae7
 CSeq: 2 REGISTER
 Via: SIP/2.0/TLS 192.0.2.1:4320;ms-received-cid=1C500
 Content-Length: 0
```
The client locates the SA that 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 with the security context information stored in the SA down to the TLS implementation. The client obtains or locates a previously obtained certificate, and calls the TLS implementation to generate an output token that carries TLS certificate, client_key_exchange, certificate_verify, change_cipher_spec, and finished handshake messages. The client then encodes the TLS token as the gssapi-data parameter, 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=2ebb6f264f
 To: <sip:alice@contoso.com>
 Call-ID: d5f2b95d5be64c2cbfb38aa5d3a87ae7
 CSeq: 3 REGISTER
 Authorization: TLS-DSK opaque="72118CF0", qop="auth", realm="SIP Communications Service", targetname="server.contoso.com", gssapi-data="FgMBAzasdasd", version=4
 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 client endpoint identity from the request and the opaque value from the authorization header field, finds the existing SA, decodes the value of the gssapi-data parameter using the base64 algorithm, and passes it, along with the security context information stored in the SA, down to the TLS implementation. The TLS implementation validates the information passed to it and generates a response that encapsulates one or more TLS records that contain TLS change_cipher_specand finished handshake messages. At this point, the server notes that TLS negotiation resulted in selecting a ciphersuite with SHA-256 hash function [NIST.FIPS.180-4]. The server also computes, or derives, client and server authentication keys, as described in section 3.3.5.2. The server then encodes the TLS response as the gssapi-data parameter, using the base64 algorithm, and sends it back to the client in the following 401 Unauthorized response.
```
 SIP/2.0 401 Unauthorized
 WWW-Authenticate: TLS-DSK opaque="72118CF0", gssapi-data="FAMBAAEBFgasdasd", targetname="server.contoso.com", realm="SIP Communications Service", version=4
 From: <sip:alice@contoso.com>;tag=4a2b44d131;epid=8248ca9ebb
 To: <sip:alice@contoso.com>;tag=0858513FA91D3AAE1A5840DDB99599DF
 Call-ID: d5f2b95d5be64c2cbfb38aa5d3a87ae7
 CSeq: 3 REGISTER
 Via: SIP/2.0/TLS 192.0.2.1:4320;ms-received-cid=1C500
 Content-Length: 0
  
```
The client locates the SA that it created for the first challenge message from the server and used in the second challenge, decodes the value of the gssapi-dataparameter using the base64 algorithm, and passes it, along with the security context information stored in the SA, down to the TLS implementation for validation. Once server information is validated, the client notes that the TLS negotiation resulted in selecting a ciphersuite with SHA-256 function. The client also computes, or derives, client and server authentication keys as described in section 3.2.5.1. Because the server indicated support for version 4 of the protocol in the challenge, and the client also supports version 4, the client generates a crand parameter value, and performs the HMAC computation with the client authentication key and the following buffer, which is based on the content of the REGISTER request.
```
 <TLS-DSK><1d7d4ecf><1><SIP Communications Service><server.contoso.com><d5f2b95d5be64c2cbfb38aa5d3a87ae7><4><REGISTER><alice@contoso.com><4a2b44d131><alice@contoso.com><><><><>
  
```

The client encodes the result of the HMAC computation call as the responseparameter, using the base16 algorithm, replaces characters 'A' through 'F' in the output with their lowercase equivalents ('a' through 'f'), 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=4a2b44d131;epid=8248ca9ebb
 To: <sip:alice@contoso.com>
 Call-ID: d5f2b95d5be64c2cbfb38aa5d3a87ae7
 CSeq: 4 REGISTER
 Authorization: TLS-DSK qop="auth", realm="SIP Communications Service", targetname="server.contoso.com", version=4, crand="1d7d4ecf", cnum="1", response="4321abcdef"
 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 client endpoint identity from the request and the opaquevalue from the authorization header field, finds the existing SA, decodes the value of the response parameter, using the base16 algorithm, and performs HMAC with the client authentication key and the buffer, which is the same as constructed by the client in step 7. 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 registrar component completes processing, it sends back a 200 OK response to the 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 it performs the HMAC computation using the server authentication key and the following buffer, constructed based on the following 200 OK response.
```
 <TLS-DSK><211639C4><SIP Communications Service><server.contoso.com><d5f2b95d5be64c2cbfb38aa5d3a87ae7><4><REGISTER><alice@contoso.com><4a2b44d131><alice@contoso.com><9588410E2DA11CEE9D0AE7733E07830F><><><7200>
```

The server creates an authentication information header field with the result of the preceding HMAC computation, and sends the following response to the client.

 SIP/2.0 200 OK
 AuthenticationInfo: TLS-DSK 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=4a2b44d131;epid=8248ca9ebb
 To: <sip:alice@contoso.com>;tag=9588410E2DA11CEE9D0AE7733E07830F
 Call-ID: d5f2b95d5be64c2cbfb38aa5d3a87ae7
 CSeq: 4 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 client receives the message, locates the SA, and uses it to compute the HMAC over the server authentication key and buffer created based on the message data. The buffer that it creates for signature verification is identical to the buffer created by the server when it generated the signature.

4.4 TLS-DSK Authentication Example for version 4 of the protocol

Additional resources