3.3.5.2 Processing Messages with Authentication Response from the SIP Client

  • Article

When the SIP server receives a request from the SIP protocol client that carries either an Authorization or Proxy-Authorization header field and the realm and targetname parameter values in this header field match the values that the server created during initialization, and the gssapi-data parameter is present, the server MUST perform the following steps:

  1. Extract all endpoint identifiers for the UAC endpoint that are present in the request. The server compliant with this specification MUST use the following UAC endpoint identifiers, as specified in [MS-SIPRE]:

    1. Address-of-record from the From header field and the epid parameter value from the From header field.

    2. Address-of-record from the From header field and the +sip.instance parameter value from the Contact header field.

    3. Address-of-record from the From header field and the GRUU from the Contact header field.

      A message can have one or more endpoint identifiers. If more than one endpoint identifier is present in the request, the server MUST validate that the +sip.instance value was properly derived from the epid value, as specified in [MS-SIPRE], and that the GRUU was generated by the SIP registrar for the endpoint identified with either the epid or the +sip.instance values, as specified in [MS-SIPRE].

  2. If the authorization header field is for the NTLM or TLS-DSK<23> authentication protocols, which require more than one round trip to complete the handshake, the server MUST attempt to locate the SA that it already created during the first round-trip of the negotiation.

    To locate the SA, the server SHOULD use the opaque parameter value from the authorization header field in the request along with the UAC endpoint identifier extracted from the request in step 1. If the server locates such an SA, it MUST skip step 3 and proceed directly to step 4.

  3. If the authorization header field is for the Kerberos authentication protocol, or the server could not locate the SA for the NTLM or TLS-DSK protocol in the previous step, it MUST create the SA and capture the authentication protocol and the identity of the UAC endpoint in it. The server MUST also capture the version parameter value from the authorization header field in the request. If the version parameter does not exist, the server MUST conclude that the protocol client uses a version number of 2. The server SHOULD generate the value for the opaque parameter and capture it in the SA.

  4. The server MUST then decode the value of the gssapi-data parameter from the authorization header field using the base64 encoding defined in [RFC3548] section 3, and use it in the GSS_accept_security_context call, as specified in [RFC2743] for Kerberos, or pass it down to the NTLM implementation as NEGOTIATE_MESSAGE if this is the first round-trip of the NTLM handshake, or as AUTHENTICATE_MESSAGE if it is the second round-trip, as specified in [MS-NLMP]. When creating a security context for the Kerberos authentication protocol, the server MUST use the Mutual Authentication, Integrity, and Identify parameters, as specified in [MS-KILE]. When creating a security context for the NTLM authentication protocol, the server MUST use the Datagram, Identify, and Integrity parameters, as specified in [MS-NLMP]. For TLS-DSK, the server MUST pass the decoded value of the gssapi-data parameter to the TLS implementation for processing, as specified in [RFC2246], [RFC4346], and [RFC5246]. During the first round-trip, the value contains the TLS client_hello handshake message, while during the second round-trip the value carries the TLS certificate, client_key_exchange, certificate_verify, change_cipher_spec, and finished handshake messages, and the third round-trip does not have the gssapi-data parameter.

  5. If the authentication protocol processing in step 4 failed, indicating that the protocol client could not be authenticated, and the authorization header field is for the Kerberos authentication protocol, or it is for NTLM and this is the second round-trip, which means that the SA already existed when the request arrived and it was located in step 2, or it is for TLS-DSK and this is the second or the third round trip, which means that the SA already existed when the request arrived and it was located in step 2, the server MUST reject the request with a 401 Unauthorized or 407 Proxy Authentication Required response and stop further processing, as described in section 3.2.5.1, as though the request did not have the authorization header field.

  6. If authentication protocol processing in step 4 succeeded and returned no output data, the server MUST proceed directly to the next step . If the authentication protocol implementation produced output data, the server MUST process the output of the authentication protocol and send it back to the protocol client using a 401 Unauthorized response with a WWW-Authenticate header field if the server is acting as a UAS, and a 407 Proxy Authentication Required response with a Proxy-Authenticate header field if the server is acting as a proxy as follows:

    1. If the authorization header field is for the NTLM authentication protocol and this is the first round-trip and the SA was created in step 3, the NTLM authentication protocol implementation on the server generates the CHALLENGE_MESSAGE.If the authorization header field is for the TLS-DSK authentication protocol and this is the first round trip, the TLS implementation on the server generates a response that encapsulates one or more TLS records that contain a TLS server_hello handshake message, followed by a TLS certificate, such as server_key_exchange, and then the certificate_request and server_hello_done handshake messages, as specified in [RFC2246], [RFC4346], and [RFC5246]. If the authorization header field is for the TLS-DSK authentication protocol and it is the second round trip, the TLS implementation on the server generates a response that encapsulates one or more TLS records that contain TLS change_cipher_spec and finished handshake messages. At this point the server MUST note the hash function from the ciphersuite selected by the TLS negotiation and compute the server and client authentication keys as follows (the key derivation procedure that follows is similar to the one described in [RFC2716] section 3.5):

      1. Given the master secret negotiated by the TLS handshake, the pseudo-random function (PRF) defined in the specification for the version of TLS in use, and the value randomly defined as the concatenation of the handshake message fields client_hello.random and server_hello.random, in that order, the value PRF (master secret, "client EAP encryption", random) is computed up to 128 bytes.

      2. The client authentication key, which is the one used for computing and validating signatures for messages from client to server, is obtained by truncating to the correct length the third 32 bytes of the PRF output string.

      3. The server authentication key, which is the one used for computing and validating signatures for messages from server to client, is obtained by truncating to the correct length the fourth 32 bytes of this same PRF output string.

    2. The server MUST encode the CHALLENGE_MESSAGE returned by the NTLM implementation or the preceding TLS responses, using the base64 encoding described in [RFC3548] section 3, and populate the WWW-Authenticate or Proxy-Authenticate header field with the following parameters:

      • Authentication protocol ("NTLM" or "TLS-DSK").

      • realm with the value selected by the server during initialization.

      • targetname with the value selected by the server during initialization.

      • opaque with the value that the server generated during SA creation.

      • version with a value of 3 or 4, depending on the version of the authentication protocol that the server supports.

      • gssapi-data with the base64 encoded CHALLENGE_MESSAGE from NTLM or the response from TLS.

    3. After sending the 401 or 407 response with the data described in the previous step, the server MUST discard the request and stop further processing.

  7. If the server implements version 4 of the authentication protocol, and the authorization header has a version parameter with a value of 4 or higher, the server MUST check if the authorization header also contains response, crand, and cnum parameters. If any of these parameters are not present, the server MUST reject the request with a 401 Unauthorized or 407 Proxy Authentication Required response and stop further processing, as described in section 3.2.5.1, as though the request did not have the authorization header field.

  8. If the server implements version 4 of the authentication protocol, it MUST check if the authorization header contains the response, crand, and cnum parameters. These parameters MUST be present if the protocol client also implements version 4 of the authentication protocol and are enforced by the check in the previous step. However, they might also be present in the responses generated by the protocol client implementing a lower version of the authentication protocol.

    1. If all of the parameters are present, the server MUST perform signature validation, as described in section 3.3.5.3 steps 2, 3, 4, and 5. If one of the steps failed, the server MUST stop further processing. Otherwise it MUST proceed to step 9.

    2. If not all of the parameters are present and the server already has an SA in "established" state and not marked as waiting for signature with the same protocol client endpoint connected from the same transport address, the server MUST proceed to the step 9 as though it has successfully validated the signature.

    3. If not all of the parameters are present and message being processed is:

      1. A REGISTER request with the Expires header field value greater than 0, or

      2. An INVITE request with a URI in the To header field that conforms to the ABNF of conf-endpoint-gruu, as specified in [MS-SIPRE] section 2, or

      3. A SUBSCRIBE request with the Event header field value of "vndmicrosoftprovisioningv2" and the Content-Type header field value of "application/vnd-microsoft-roaming-provisioning-v2+xml", the server MUST set the waiting for signature flag in the SA and proceed to step 9.

    4. Otherwise, the server MUST reject the request with a 401 Unauthorized or 407 Proxy Authentication Required response and stop further processing, as described in section 3.3.5.1, as though the request did not have the authorization header field.

  9. If the authentication processing in the preceding steps succeeded, the server MUST determine whether the user authenticated by the NTLM, Kerberos, or TLS-DSK protocol is authorized to use the address-of-record in the URI of the From header field of the request.

    If an authenticated user is not authorized, the server MUST reject the request with a 403 Forbidden response. The server MUST add an authentication information header field to the 403 Forbidden response, as described in section 3.3.4.1, using the SA located in step 2 or created in step 3. After a 403 Forbidden response is sent, the server MUST destroy the SA and stop further processing.

  10. If the authorization in step 9 succeeded, the server MUST transition the SA into the "established" state. The server SHOULD then continue processing the request as required by the SIP protocol.