SIP peer authentication

Asterisk Asterisk SIP
1

Hello
I’m trying to deploy SIP peer authentication to a SIP connection between two asterisk boxes. I have tried the following configuration:

asterisk box 67 <— SIP —> asterisk box 68

sip.conf for box 68:

[general]
t38pt_udptl=yes,none,maxdatagram=400
    
[test]
host=192.168.0.68
type=peer
secret=testtest
context=from-trunk
qualify=yes
insecure=port,invite
canreinvite=no

sip.conf for box 67:

[general]
t38pt_udptl=yes,none,maxdatagram=400
    
[test]
host=192.168.0.67
type=peer
secret=testtest
context=from-trunk
qualify=yes
insecure=port,invite
canreinvite=no

Setting or changing secret and username does not affect the connection at all! What am I doing wrong?

2

You are specifying insecure.

Unfortunately, people ignore the hint, in the name, that this reduces security, and widely copy it. insecure=invite is no longer really needed, as remotesecret allows you to disable attempts to authenticate an ITSP (ITSP’s generally want you to authenticate, but won’t authenticate themselves) and people use isecure=port because they think more is better. ITSP’s like specifying it because any reduction in security going to reduce the number of ways in which the “connection” could fail, and there is no incentive on them to relax it to just the minimum extent needed.

Your problem here is you are using inecure=invite, but nothing here seems to indicate a need for insecure=port, either.

1 Like
3

Thanks for your reply. I changed the configuration as follow:

sip.conf box 68:

[general]
t38pt_udptl=yes,none,maxdatagram=400

[FOO]
secret=123
host=192.168.0.68
type=peer
context=from-trunk
qualify=yes

sip.conf box 67:

[general]
t38pt_udptl=yes,none,maxdatagram=400

[FOO]
secret=TESTT
host=192.168.0.67
type=peer
context=from-trunk
qualify=yes

As you can see I removed insecure and secrets does not match, but after reloading chan_sip module, peers become reachable!

4

I don’t think OPTIONs is authenticated. Even if it is, a 401 response is as good as any other response in confirming that it is reachable (in many cases a qualify probe actually produces a 404, but that is still sufficient). You will need to test with an actual call.

5

I will test with real calls. Could you please suggest a resource about “SIP peer authentication” concept?

6

https://tools.ietf.org/html/rfc3261#section-22

7

I have got it worked. Consider the following scenario:

Linphone A <-> Asterisk box <—> CISCO <-> Linphone B

sip.conf in Asterisk box:

[general]
t38pt_udptl=yes,none,maxdatagram=400

allow=all
[peer-1]
host=192.168.0.66
type=peer
context=from-trunk
qualify=yes
insecure=port
canreinvite=no



[Foo]
username=Foo
secret=password
host=192.100.100.2
type=peer
context=from-trunk
qualify=yes
insecure=port
canreinvite=no

and CISCO configuration:

!
dial-peer voice 1 voip
 destination-pattern 1.+
 session protocol sipv2
 session target ipv4:192.100.100.1
 codec g711alaw
!         
dial-peer voice 2 voip
 destination-pattern 2.+
 session protocol sipv2
 session target ipv4:192.168.0.197
 codec g711alaw
!
!
sip-ua 
 authentication username Foo password passw0rd

When I call Linphone B from Linphone A, Linphone B rings and call is established while passwords do not match! If call Linphone A from Linphone B, authentication works fine and I get the following message in Asterisk box cli:

handle_request_invite: Failed to authenticate device

What am I doing wrong? I expect that call should not establish in neither ways