Share via

3.1.4.2 Sending a SIP Message

  • Article

Before sending a message, the sender MUST generate a message signature or checksum that it will send with the message so that the receiver can authenticate the message. The client and the server SHOULD use the same algorithm to generate message signatures. The Microsoft implementation uses the GSS_GetMIC() and GSS_VerifyMIC() implementations of the NTLM or Kerberos security service provider interface to compute and verify a signature. For more information on NTLM GSS_GetMIC() and GSS_VerifyMIC(), see [MS-NLMP] section 3.1.4. For more information on Kerberos GSS_GetMIC() and GSS_VerifyMIC implementation, see [RFC1964] section 1.2.

The client MUST use the following values in order and enclosed by angle brackets to construct a secure buffer that is then used to compute the message signature:

  1. Authentication method (for example, NTLM or Kerberos)

  2. crand for client or srand for server

  3. cnum for client or snum for server

  4. realm

  5. targetname

  6. Call ID

  7. CSeq#

  8. CSeq method

  9. From URL

  10. From tag

  11. To tag

  12. Expires (optional)

  13. Response code (responses only)

The only difference from the client signature is the use of a server-generated salt (srand) and sequence number (snum) rather than the client-generated salt (crand) and sequence number (cnum).

Note Even though some parameter values are case-insensitive, these values MUST be used as they appear in the message when performing the signature computation.

For optional fields, such as Expires, an empty set of angle brackets (<>) is included in the buffer to signal when those headers do not exist in the SIP message.

The response code is only part of the signature computation for responses and is not part of the signature for requests. An empty set of angle brackets (<>) is not included in the buffer to sign for requests.

The client places the message signature in the response parameter of the Proxy-Authorization: header. The server places the signature in the rspauth parameter of the Proxy-Authentication-Info: header.

As an example, the following message,

 SUBSCRIBE sip:samtest1@pstntest.rtmp.selfhost.corp.microsoft.com SIP/2.0
 Via: SIP/2.0/TCP 172.24.34.1:16577
 Max-Forwards: 70
 From: <sip:samtest1@pstntest.rtmp.selfhost.corp.microsoft.com>;
        tag=82249b57436d4aa39ec38afa968fa994;
        epid=bd0238d966
 To: <sip:samtest1@pstntest.rtmp.selfhost.corp.microsoft.com>
 Call-ID: 72558074992e4f2cafb48c6e44b90a0c
 CSeq: 1 SUBSCRIBE
 Contact:
    <sip:samtest1@pstntest.rtmp.selfhost.corp.microsoft.com:16577;
     maddr=172.24.34.1;transport=tcp>;
     proxy=replace
 User-Agent: RTC/1.3
 Event: vnd-microsoft-roaming-contacts
 Accept: application/vnd-microsoft-roaming-contacts+xml
 Supported: com.microsoft.autoextend
 Supported: ms-benotify
 Proxy-Require: ms-benotify
 Supported: ms-piggyback-first-notify
 Proxy-Authorization: 
    NTLM qop="auth", 
    realm="SIP Communications Service",
    opaque="9C55D687", 
    crand="009139df", 
    cnum="1",
    targetname="pstn.pstntest.rtmp.selfhost.corp.microsoft.com",
    response="0100000039623537c854b2e8ca6a203e"
 Content-Length: 0

would result in the following signature buffer (line breaks not included).

 <NTLM>
 <009139df >
 <1>
 < SIP Communications Service>
 < pstn.pstntest.rtmp.selfhost.corp.microsoft.com >
 <72558074992e4f2cafb48c6e44b90a0c >
 <1>
 <SUBSCRIBE>
 < sip:samtest1@pstntest.rtmp.selfhost.corp.microsoft.com >
 <82249b57436d4aa39ec38afa968fa994>
 

Note The signature computed for the preceding example is "0100000039623537c854b2e8ca6a203e", which is included in the response parameter of the Proxy-Authorization header.

 For Kerberos, the buffer for signature computation is formed in a manner similar to what is shown in the preceding NTLM example. The only differences are that the first element in the signature buffer is <Kerberos> instead of <NTLM> and that Kerberos GSS-GetMIC() is used to compute the signature.