[Freeswitch-dev] Issue with Sofia SIP: username and colons

[Lorenzo Miniero]

Hi,

I'm not sure this is the right place to discuss a potential issue related
to Sofia SIP, especially considering I'm going to describe something that
happens in another software, but I thought that, considering that
Freeswitch uses Sofia SIP as well and has kept it alive so far, it would be
of interest to you guys as well, as you may be affected too.

To give you some context, I'm using Sofia SIP in one of the plugins of my
WebRTC server, Janus. Specifically, this plugin acts as a SIP client on
behalf of WebRTC users, meaning I create NUA instances for them, doing
registers, invites and stuff like that from the server side and exposing a
simpler API and events (not SIP) to users.

This usually works fine, but I recently encountered a weird problem that
can occur when users try to REGISTER and provide a username with a colon in
it. This fails, and apparently the cause is in how the NUTAG_AUTH works. As
you probably know, NUTAG_AUTH is the tag nua_authenticate requires when
answering a REGISTER challenge, and it needs a string that is basically a
colon-separated concatenation of digest/realm/user/pass, e.g.:

    Digest:"nokia proxy":xyz:secret

This breaks when the username contains a colon, as the method that parses
this concatenated string (auc_credentials() in auth_client.c) seems to do a
"brutal" split on the colon character. I tried wrapping the username in
quotes, but that didn't work, which seems to confirm what the code
suggests. Apparently the only way to get Sofia SIP to digest the username
with the colon in it, is escaping the colon (%3A) in there, but then this
obviously results in a broken authentication when it gets to the registrar,
as the usernames differ (ciccio:123 != ciccio%3A123). Some may argue that
it should be the registrar's responsibility to unescape the username part,
but this is a quoted string in the authorization challenge and not the
username part of a URI, so I don't think they're required to do that.

Is this something you encountered as well? Being more of a SIP server, I
guess this may be seen as less of an issue in Freeswitch, but it might
still occur if/when you're doing active REGISTERs yourself. If it's a known
problem, do you happen to know of any workaround that wouldn't require
patching auc_credentials to do the right thing? (which might be either
changing the delimiter in NUTAG_AUTH to a much less used character, or
automatically unescaping %3A internally when formatting the username).

Thanks in advance for any feedback you may have for me!
Lorenzo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20170620/b2b6fae3/attachment.html>