when DIGEST qop=auth-int, the body hash is wrong

[dpocock]

repro is refusing to authenticate when qop=auth-int. Using qop=auth is OK.

I checked the logs on both JsSIP and the repro proxy

The body hashes don't match

I compared the body text from the browser console log and the repro log and found the text is identical

I manually did the MD5 on the text and the value returned is the same as the value in the repro log, this makes me feel there is an error in JsSIP

I notice you have a unit test for auth-int

Then I had a lucky guess: your code is calculating the hash of the body before it changes the line endings to CRLF. Would you know where to fix this?

JSCommunicator also has some code for modifying the body but I disabled that code while testing. In any case, I believe this code would have been called before the DIGEST stuff: https://github.com/opentelecoms-org/jscommunicator/blob/master/JSCommManager.js#L229

[dpocock]

Also discussed on mailing list here: https://groups.google.com/forum/#!topic/jssip/Tihqc1MaVEI

[ibc]

Thanks, Daniel. Will check when possible (terribly busy these days). If you know how to fix it, a PR would be super welcomed.

[ikq]

The "auth-int" authorization don't work with our SBC server.

It works if in calculateMD5 inner function: utf8Encode(str), comment the line: str = str.replace(/\r\n/g, '\n');

(I did not find corresponding RFC that describe that for auth-int in body CRLF should be replaced to LF)

[ibc]

If this is based on what the RFC says, then could you make a PR or at least a code diff?

[ikq]

File : https://github.com/versatica/JsSIP/blob/master/lib/Utils.js

>diff -u Utils.js Utils_mod.js
--- Utils.js    2021-11-18 19:57:15.895093900 +0200
+++ Utils_mod.js        2021-11-18 20:00:11.387105200 +0200
@@ -377,7 +377,7 @@

   function utf8Encode(str)
   {
-    str = str.replace(/\r\n/g, '\n');
+    // str = str.replace(/\r\n/g, '\n');
     let utftext = '';

     for (let n = 0; n < str.length; n++)

Оur chief SIP specialist thinks that it is not necessary to replace CRLF with LF in message body when calculating MD5.

We tested the issue and found that if we comment out this line, "auth-int" authorization works with our SBC server.

[ikq]

Corresponding RFC ?

Probably: https://datatracker.ietf.org/doc/html/rfc2617

From SIP forums: https://lists.cs.columbia.edu/pipermail/sip-implementors/2006-February/011835.html