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.
When a SIP protocol client receives a message from the server that contains an Authentication-Info or Proxy-Authentication-Info header field, it MUST attempt to locate an existing security association that was created from the challenge that had the same authentication protocol, realm, and authentication target values as in the Authentication-Info or Proxy-Authentication-Info header field. For the NTLM and TLS-DSK<9> authentication protocols, the authentication target is the value of the targetname parameter without quotes. For the Kerberos authentication protocol, the authentication target is the value of the targetname parameter without quotes and the sip/ service descriptor. The protocol client MUST then process the message as described in the following steps:
If the protocol client does not find the SA with a matching authentication protocol, realm
,and authentication target values, it discards the message and stops further processing.If the protocol client does find the SA with a matching authentication protocol, realm, and authentication target values, the protocol client constructs a buffer with the information from the message that will be used in signature verification.
The buffer is constructed from the following string values in order, each of them enclosed by angle brackets (<>), and with the same syntax and case, even if the field is case-insensitive, as they appear in the message headers:
Authentication protocol ("NTLM", "Kerberos", or "TLS-DSK").
srand value.
snum value.
realm parameter value without quotes.
targetname parameter value without quotes.
The value of the Call-ID header field.
The sequence number from the CSeq header field.
The method from the CSeq header field.
The URI in the From header field.
The tag parameter value from the From header field.
If the protocol version on the authenticating server is 3 or higher, the URI in the To header field.
The tag parameter value from the To header field.
If the protocol version on the authenticating server is 3 or higher, the sip URI from the P-Asserted-Identity header field.
If the protocol version on the authenticating server is 3 or higher, the tel URI from the P-Asserted-Identity header field.
The value of the Expires header field.
If the message is a response, the response code value as a decimal string.
If a field mentioned in the list does not exist in the message, an empty string enclosed by angle brackets is included. This does not apply to fields included conditionally depending on protocol version or message type; an empty string enclosed by angle brackets is not needed if the condition is not satisfied. However, empty angle brackets are included if the condition is satisfied, but there is no corresponding header field in the message.
The protocol client decodes the value of the rspauth parameter using the base16 decoding procedure, as specified in [RFC3548] section 6, and passes it, along with the buffer constructed in the preceding step 2, and the authentication protocol context from the SA to the GSS_VerifyMic call, as specified in [MS-NLMP] section 3.1.4 for NTLM, or [RFC2743] section 2.3.2 for Kerberos.
Note that for the NTLM SSPI, the protocol client provides a fixed message sequence number of 100 in addition to the buffer.
For TLS-DSK, the client computes the signature token using the HMAC algorithm specified in [RFC2104], with the hash function and server authentication key obtained when TLS negotiation completed, which means that the finished handshake message was received from the server, as described in section 3.2.5.1, and the buffer constructed in step 2. It then compares the binary value of the computed signature token with the decoded binary value of the rspauth parameter.
If the GSS_VerifyMic call fails, indicating that the signature could not be verified or the binary value of the computed TLS-DSK signature token is not the same as the binary value of the rspauth parameter, the protocol client discards the message and stops further processing.
If the GSS_VerifyMic call succeeds, the protocol client verifies that the sequence number in the snum parameter value does not fall outside the sliding window that it maintains and is not a replay of the message within the window. If the highest sequence number that the protocol client has processed so far for this SA exceeds the received sequence number by more than 256, or another message with the same sequence number has been received, the protocol client discards the message and stops processing.
If the sequence number is the highest seen so far for the SA, the protocol client adjusts the window and records the fact that this particular sequence number has been used.
If the SA used for verification is not yet in the "established" state, the protocol client determines whether the message it is processing is a 403 Forbidden response. If the message is a 403 Forbidden response, the protocol client destroys the SA and requests different credentials from the user to retry the authentication.
Otherwise, the protocol client transitions the SA to the "established" state and destroys any other SAs with the same realm and authentication target values.