Correct digest authentication call flow for authentication of INVITEs at the network

[GoogleCodeExporter]

Authentication fails, if the SIP domain configured in SIPML5 does not match the 
authentication realm of the network. Furthermore, WebRTC2SIP expects the ha1 
used for digest authentication in a contact header param in the initial INVITE. 
This poses a security problem, when using unsecure websockets transport for 
signaling between browser and WebRTC2SIP.

It would be desirable, that WebRTC2SIP forward the digest authentication 
challenge from the network to the Browser (even if the web breaker is enabled), 
i.e. a call flow as depicted below.

Browser        WebRTC2SIP        Network
  |                |                |
  |- INVITE      ->|- INVITE      ->|
  |                |                |
  |                |<- 401 Unauth  -|
  |<- 401 Unauth  -|                |
  |-  ACK        ->|- ACK         ->|
  |                |                |
  |- INVITE/Cred ->|- INVITE/Cred ->|
  |                |                |
  |                |<- 200 OK      -|
  |<- 200 OK      -|                |
  |- ACK         ->|- ACK         ->|

Note, that for REGISTER, the call flow works like this, as of yet. Note also, 
that SIPML5 must be able to handle the authentication challenge for INVITE 
correctly (if it doesn't already).

Original issue reported on code.google.com by emil.kro...@gmail.com on 8 Apr 2013 at 8:47

[GoogleCodeExporter]

This was an option when we were developing the gateway but the issue is when 
qop parameter is equal to "auth-int" then, "A2" which is used to compute the 
digest response depends on the entity-body (INVITE content). This means the 
response computed at the browser side will be different than the one at the 
gateway as the INVITE content is different.

Discussion thread: 
https://groups.google.com/group/doubango/browse_thread/thread/c296f636cc4129d2

Original comment by boss...@yahoo.fr on 8 Apr 2013 at 2:46

• Changed state: Accepted

[GoogleCodeExporter]

After discussion with collegues, we came up with the following possible 
solution. The digest challenge is forwarded to the browser, the browser sends a 
new INVITE with the digest response. When the qop parameter is not auth-int, 
everything is fine. When the qop parameter is equal to auth-int, the browser 
adds the ha1 computed based on the realm and algorithm from the challenge, such 
that WebRTC2SIP can compute an updated digest response based on the forwarded 
SDP body.

Original comment by emil.kro...@gmail.com on 8 Apr 2013 at 3:55

[GoogleCodeExporter]

This will help big time with SIP interop with Industry standard SIP servers 
from various vendors that ITSPs have deployed. We have a Broadsoft softswitch, 
that is currently not working. It will open new doors to push WebRTC into the 
realm of ITSPs worldwide. Thanks for your attention and help to this issue.

Original comment by ujjvalk...@gmail.com on 14 Apr 2013 at 6:30

[GoogleCodeExporter]

Any chance to get this implemented

Original comment by ujjvalk...@gmail.com on 19 May 2013 at 5:09

[GoogleCodeExporter]

ANy update on this?

Original comment by ujjvalk...@gmail.com on 19 Jun 2013 at 1:44