asterisk users - Jul 2019 - Question on calculating PJSIP md5 authentication with NEC

I have done additional testing and I haven't been able to figure out why
it's failing.

Since my original testing we now set the realm on the authentication section to
match what we receive from NEC.  It's of the format abc at xyz.com
I have verified the md5_cred several times and it matches the
user:realm:password formula 3016:insiph at something0a646666.com:3016 where
username is 3016 and password is 3016

We suspect it has something to do with the format of the realm that NEC is
sending where it may not be working correctly supported by the Asterisk PJSIP
code.

Is there anyone who has used PJSIP outbound REGISTRATION using MD5 support that
can provide some insight?
Or even anyone who know chan_sip's REGISTER and how it calculates it's
HA1, HA2 for the MD5 authentication?

Dan

From: asterisk-users <asterisk-users-bounces at lists.digium.com> On
Behalf Of Dan Cropp
Sent: Wednesday, July 10, 2019 10:48 AM
To: asterisk-users at lists.digium.com
Subject: [asterisk-users] Question on calculating the md5_sum

Using chan_sip, we are able to register with an NEC switch.  When I try to
REGISTER with PJSIP, the authentication is being rejected.  Traces show it's
using md5 authentication.
The packets looks almost identical.  The one area that I suspect is causing the
problem is the md5_cred for my pjsip.conf registration.

I'm using a Poco MD5 utility to generate the MD5 passing
username:realm:password
Where username is 3016
Realm is asterisk (default)
Password is 3016 which is the same as chan_sip's secret
The value I'm setting the md5_cred in auth section to is
63e8aedc77335879c93123055d21211d

Would this value match what chan_sip would pass as the md5 credentials?


Our sip.conf looks like the following...
[general]
context = NECTEST
bindaddr = 0.0.0.0
bindport = 5060
websocket_enabled = false
srvlookup = no
allowguest = yes
debug = yes
sipdebug = yes
defaultexpiry = 480
deny = 0.0.0.0/24
permit = 10.100.102.0/24
permit = 192.168.9.0/24
canreinvite = yes
callcounter = yes
register = 3016:3016 at 10.100.102.82:5060/3016

[3016]
type = friend
qualify = no
nat = no
host = 10.100.102.82:5060
defaultuser = 3016
secret = 3016
incominglimit = 24
accountcode = 33
port = 5060
context = NECTEST
dtmfmode = auto
disallow = all
allow = ulaw
defaultexpiry = 480
insecure = invite
fromdomain = 10.100.102.82
acl = acl6

Have a great day!

Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20190712/282a9155/attachment.html>

Just tracked down the code for the chan_sip MD5 REGISTER and have been able to
verify that chan_sip is calculating the HA1 same as I am calculating the
md5_cred for PJSIP
3016:abc at xyz.com:3016

Both chan_sip and PJSIP REGISTER traces show the uri as sip:10.100.102.82
So the HA2 for both as MD5(method:uri)  (which in this case is
REGISTER:sip:10.100.102.82).

chan_sip response formula with qop detected (sent by NEC) is
ha1:nonce:noncecount:cnonce:auth:h2
Using this formula I am able to match it with my Asterisk chan_sip trace.
NEC accepts this REGISTER

Can anyone point me to the area where Asterisk PJSIP would be doing the response
for the REGISTER 401 reply?
NEC does not like the way PJSIP calculates the response value for the REGISTER
reply.
I tried to calculate the response exactly like chan_sip does (using the values
from the trace and the HA1/HA2) but it's not matching what the sip trace
shows Asterisk sending for the response.

Does Asterisk PJSIP support handle this or is it all done by PJSIP?

Dan


From: asterisk-users <asterisk-users-bounces at lists.digium.com> On
Behalf Of Dan Cropp
Sent: Friday, July 12, 2019 2:09 PM
To: Asterisk Users Mailing List - Non-Commercial Discussion <asterisk-users
at lists.digium.com>
Subject: Re: [asterisk-users] Question on calculating PJSIP md5 authentication
with NEC

I have done additional testing and I haven't been able to figure out why
it's failing.

Since my original testing we now set the realm on the authentication section to
match what we receive from NEC.  It's of the format abc at
xyz.com<mailto:abc at xyz.com>
I have verified the md5_cred several times and it matches the
user:realm:password formula 3016:insiph at something0a646666.com:3016 where
username is 3016 and password is 3016

We suspect it has something to do with the format of the realm that NEC is
sending where it may not be working correctly supported by the Asterisk PJSIP
code.

Is there anyone who has used PJSIP outbound REGISTRATION using MD5 support that
can provide some insight?
Or even anyone who know chan_sip's REGISTER and how it calculates it's
HA1, HA2 for the MD5 authentication?

Dan

From: asterisk-users <asterisk-users-bounces at
lists.digium.com<mailto:asterisk-users-bounces at lists.digium.com>> On
Behalf Of Dan Cropp
Sent: Wednesday, July 10, 2019 10:48 AM
To: asterisk-users at lists.digium.com<mailto:asterisk-users at
lists.digium.com>
Subject: [asterisk-users] Question on calculating the md5_sum

Using chan_sip, we are able to register with an NEC switch.  When I try to
REGISTER with PJSIP, the authentication is being rejected.  Traces show it's
using md5 authentication.
The packets looks almost identical.  The one area that I suspect is causing the
problem is the md5_cred for my pjsip.conf registration.

I'm using a Poco MD5 utility to generate the MD5 passing
username:realm:password
Where username is 3016
Realm is asterisk (default)
Password is 3016 which is the same as chan_sip's secret
The value I'm setting the md5_cred in auth section to is
63e8aedc77335879c93123055d21211d

Would this value match what chan_sip would pass as the md5 credentials?


Our sip.conf looks like the following...
[general]
context = NECTEST
bindaddr = 0.0.0.0
bindport = 5060
websocket_enabled = false
srvlookup = no
allowguest = yes
debug = yes
sipdebug = yes
defaultexpiry = 480
deny = 0.0.0.0/24
permit = 10.100.102.0/24
permit = 192.168.9.0/24
canreinvite = yes
callcounter = yes
register = 3016:3016 at 10.100.102.82:5060/3016

[3016]
type = friend
qualify = no
nat = no
host = 10.100.102.82:5060
defaultuser = 3016
secret = 3016
incominglimit = 24
accountcode = 33
port = 5060
context = NECTEST
dtmfmode = auto
disallow = all
allow = ulaw
defaultexpiry = 480
insecure = invite
fromdomain = 10.100.102.82
acl = acl6

Have a great day!

Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20190712/8a38e3d8/attachment.html>

On Fri, Jul 12, 2019, at 5:10 PM, Dan Cropp wrote:
>  
> Just tracked down the code for the chan_sip MD5 REGISTER and have been 
> able to verify that chan_sip is calculating the HA1 same as I am 
> calculating the md5_cred for PJSIP
> 
> 3016:abc at xyz.com:3016
> 
> 
> Both chan_sip and PJSIP REGISTER traces show the uri as sip:10.100.102.82
> 
> So the HA2 for both as MD5(method:uri) (which in this case is 
> REGISTER:sip:10.100.102.82).
> 
> 
> chan_sip response formula with qop detected (sent by NEC) is
> 
> ha1:nonce:noncecount:cnonce:auth:h2
> 
> Using this formula I am able to match it with my Asterisk chan_sip trace. 
> 
> NEC accepts this REGISTER
> 
> 
> Can anyone point me to the area where Asterisk PJSIP would be doing the 
> response for the REGISTER 401 reply?
> 
> NEC does not like the way PJSIP calculates the response value for the 
> REGISTER reply.
> 
> I tried to calculate the response exactly like chan_sip does (using the 
> values from the trace and the HA1/HA2) but it’s not matching what the 
> sip trace shows Asterisk sending for the response.
> 
> 
> Does Asterisk PJSIP support handle this or is it all done by PJSIP? 
The value is given to PJSIP[1] and it does the rest. You could use the password
option and trace how PJSIP is calculating it in that scenario, and then switch
to MD5 cred after you determine that and make it match.

[1]
https://github.com/asterisk/asterisk/blob/master/res/res_pjsip_authenticator_digest.c#L180

-- 
Joshua C. Colp
Digium - A Sangoma Company | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.asterisk.org