ASTERISK-02795: User control of specific authentication methods

[Home]

Summary: ASTERISK-02795: User control of specific authentication methods

Reporter: brads (brads) Labels:

Date Opened: 2004-11-11 23:53:40.000-0600 Date Closed: 2011-06-07 14:10:11

Priority: Minor Regression? No

Status: Closed/Complete Components: Channels/chan_sip/Interoperability

Versions: Frequency of
Occurrence

Related
Issues:

Environment: Attachments: ( 0) chan_sip.c_digest_patch.txt
( 1) chan_sip.c.sipauth.patch.txt
( 2) pac2

Description: Asterisk send a Cseq of 102 options for authentication.
If trying to authenticate to a secure SIP network, obviously "you can not query". There is no "known" method to control the Cseq request. Cseq should be invite, not options.
Yes, we can authenticate using username:password@IPaddress:5060
But!
This create a whole new set of issues when trying to Dirctly recieve a DID call directly to a phone extention!
Authentication must e easily managable via {context} not register =>???
Specific enhancements for authentication requested!

****** ADDITIONAL INFORMATION ******

ask me any question on the specifics of this issue!
BradS@AudioVisualNetworks.com
USMC netork security specialist

Comments: By: Olle Johansson (oej) 2004-11-12 03:47:10.000-0600

* We never send OPTION messages for authentication.
* Cseq belongs in every SIP message and transaction

Please mail me or find me on IRC to explain this a bit more, I am sure I misunderstand you.
By: Mark Spencer (markster) 2004-11-12 08:09:57.000-0600

I don't think I understand what your complaint is -- we only use OPTIONS when doing "qualify" to make sure a host is alive, and I certainly don't understand how anything even remotely like this would qualify as MAJOR under the bug guidelines. Can you provide a bit more detail and/or make an explanation perhaps in meaningful, complete sentences, or with an annotated sip debug?
By: Brian West (bkw918) 2004-11-12 09:28:35.000-0600

Sounds like he doesn't understand how to do user/peer matching in sip.conf.
By: brads (brads) 2004-11-12 14:33:27.000-0600

The discussion between myself and Primus
Hence "where is the control over the authentication parameters?"

tsmarttg1 [9:48 AM]: ok. I have the traces. I am sending them to the developer to look at
tsmarttg1 [9:49 AM]: I do see a couple of differences between devices that work and your Asterisk
tsmarttg1 [9:49 AM]: Our devices have a uri field populated, yours just has /
BSUMRALLL [9:49 AM]: do you think it will take long? If so, can you switch us back temporarily so we can continue troubleshooting the DID issue. or if it is ony going to take a few,,, it is all good for us to wait!
BSUMRALLL [9:49 AM]: uri field?
BSUMRALLL [9:50 AM]: hmmmm
tsmarttg1 [9:50 AM]: Also you send a parameter opaque ="".. ours doesnt' have that
BSUMRALLL [9:50 AM]: let me see!

Via: SIP/2.0/UDP 67.94.247.42:5060;branch=z9hG4bK4429cd29
From: <sip:IS59366435@209.227.167.232>;tag=as2e51b4dd
To: <sip:IS59366435@209.227.167.232>;tag=08637e42
Call-ID: 2d1d5ae96763845e75a2a8d408edbdab@67.94.247.43
CSeq: 466 REGISTER
User-Agent: Asterisk PBX
Authorization: Digest username="xxxxxxxx", realm="sipinfo.iprimus.net", algorithm=MD5, uri="/", nonce="tyYWO7XoAwA=ca7319faafedea8add89dd7f69ce618223480bdc", response="ef2e5e6264c436f607acca7e9be2e573", opaque=""
Expires: 160
Contact: <sip:s@67.94.247.42>
Event: registration
Content-Length: 0
By: Brian West (bkw918) 2004-11-12 16:31:05.000-0600

attach your sip.conf and you sip debug. I suspect you're trying to match an inbound call to a context and it isn't working right?
By: brads (brads) 2004-11-12 20:15:24.000-0600

Ok, take a look at this new posting. If you use either user or peer or friend in sip.conf, it send options packets. A proxy with any decent security will "BLOCK" options. If it doesn't the lead tech needs to go back to school! I am posting the options packet now. As long as option packets are being sent, they will be "denied". and this using the following configuration.
[primus]
type=friend
host=209.227.167.232
username=xxxxxxxxx
md5secret=xxxxxxx
insecure=no
qualify=700
canreinvite=yes
nat=no
auth=md5
context=from-sip
disallow=all
allow=gsm

This will with out question be blocked by any decent security
and is require by asterisk for proper routing of DIDs

under the registration that worked on a "no secure server, we used the following configuration.

register => xxxxxxxx:xxxxxxx@ipaddress:5060

And had zero success in recovering incoming DIDs in asterisk "EVEN though" the packets sent to us met RFC standards
To: DID@ourIP
From DID@PrimusIP

Hence!
One must be able to manage Authentication parameters to meet RFC standards from other heterogeneous networks! Not just asterisk version of RFC.
By: brads (brads) 2004-11-12 20:19:16.000-0600

SIP debug

Call-ID: 3ed7699a01f6ba7f29f6fa060f9849b4@67.94.247.42
CSeq: 102 OPTIONS
User-Agent: Asterisk PBX
Date: Sat, 13 Nov 2004 02:17:56 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER
Content-Length: 0

to 209.227.167.232:5060
Retransmitting #4 (no NAT):
OPTIONS sip:209.227.167.232 SIP/2.0
Via: SIP/2.0/UDP xxxxxxxxxxx:5060;branch=z9hG4bK45c6b2f3
From: "asterisk" <sip:asterisk@xxxxxxxxxxxx>;tag=as15580208
To: <sip:209.227.167.232>
Contact: <sip:asterisk@xxxxxxxxx>
Call-ID: 3ed7699a01f6ba7f29f6fa060f9849b4@67.94.247.42
CSeq: 102 OPTIONS
User-Agent: Asterisk PBX
Date: Sat, 13 Nov 2004 02:17:56 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER
Content-Length: 0

to 209.227.167.232:5060
Destroying call '3ed7699a01f6ba7f29f6fa060f9849b4@67.94.247.42'
== Parsing '/etc/asterisk/manager.conf': Found
== Manager 'cron' logged on from 127.0.0.1
11 headers, 0 lines
Reliably Transmitting:
OPTIONS sip:68.7.17.223:5062 SIP/2.0
Via: SIP/2.0/UDP xxxxxxxx:5060;branch=z9hG4bK5c54c73c
From: "asterisk" <sip:asterisk@xxxxxxxxx>;tag=as456749cb
To: <sip:68.7.17.223:5062>
Contact: <sip:asterisk@xxxxxxxxxx>
Call-ID: 266dc7054a45d81937cea7a668285a80@67.94.247.42
CSeq: 102 OPTIONS
User-Agent: Asterisk PBX
Date: Sat, 13 Nov 2004 02:18:00 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER
Content-Length: 0

(no NAT) to 68.7.17.223:5062
ip67-94-247-43*CLI>

Sip read:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 67.94.247.42:5060;branch=z9hG4bK5c54c73c
From: "asterisk" <sip:asterisk@xxxxxxxx>;tag=as456749cb
To: <sip:68.7.17.223:5062>;tag=001193cef4390a4a13440a4a-7005b48d
Call-ID: 266dc7054a45d81937cea7a668285a80@67.94.247.42
CSeq: 102 OPTIONS
Server: CSCO/7
Content-Type: application/sdp
Content-Length: 233
Allow: OPTIONS,INVITE,BYE,CANCEL,REGISTER,ACK,NOTIFY,REFER

v=0
o=Cisco-SIPUA 0 0 IN IP4 192.168.0.8
s=SIP Call
c=IN IP4 192.168.0.8
t=0 0
m=audio 1 RTP/AVP 0 8 18 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

10 headers, 11 lines
Destroying call '266dc7054a45d81937cea7a668285a80@67.94.247.42'
== Manager 'cron' logged off from 127.0.0.1
11 headers, 0 lines
Reliably Transmitting:
OPTIONS sip:209.227.167.232 SIP/2.0
Via: SIP/2.0/UDP xxxxxxxxxx:5060;branch=z9hG4bK1b676724
From: "asterisk" <sip:asterisk@xxxxxxxx>;tag=as08710c38
To: <sip:209.227.167.232>
Contact: <sip:asterisk@xxxxxxxx>
Call-ID: 0cd09ec0543f35632b95165f4ba8085a@xxxxxxx
CSeq: 102 OPTIONS
User-Agent: Asterisk PBX
Date: Sat, 13 Nov 2004 02:18:10 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER
Content-Length: 0

(no NAT) to 209.227.167.232:5060
Retransmitting #1 (no NAT):
OPTIONS sip:209.227.167.232 SIP/2.0
Via: SIP/2.0/UDP xxxxxxxxx:5060;branch=z9hG4bK1b676724
From: "asterisk" <sip:asterisk@xxxxxxxxx>;tag=as08710c38
To: <sip:209.227.167.232>
Contact: <sip:asterisk@xxxxxxxxx>
Call-ID: 0cd09ec0543f35632b95165f4ba8085a@xxxxxxxxx
CSeq: 102 OPTIONS
User-Agent: Asterisk PBX
Date: Sat, 13 Nov 2004 02:18:10 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER
Content-Length: 0

to 209.227.167.232:5060
Retransmitting #2 (no NAT):
OPTIONS sip:209.227.167.232 SIP/2.0
Via: SIP/2.0/UDP xxxxxxxx:5060;branch=z9hG4bK1b676724
From: "asterisk" <sip:asterisk@xxxxxxxxxx>;tag=as08710c38
To: <sip:209.227.167.232>
Contact: <sip:asterisk@xxxxxxxxx>
Call-ID: 0cd09ec0543f35632b95165f4ba8085a@xxxxxxxxxx
CSeq: 102 OPTIONS
User-Agent: Asterisk PBX
Date: Sat, 13 Nov 2004 02:18:10 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER
Content-Length: 0

edited on: 11-16-04 12:15
By: brads (brads) 2004-11-12 20:32:56.000-0600

PS, we tried
peer, friend,user,,, and even made up a few!!!!!!!!!!
Context = options = failure
forced registration = no DIDs
By: brads (brads) 2004-11-12 20:34:39.000-0600

You can consult Matt O in your office who has been working with me on this issue as a pre-paid support issue! My money is where my mouth is on this one!
By: brads (brads) 2004-11-12 20:36:42.000-0600

Oh!
we just upgraded to the newest version of asterisk! Same thing.... problem still exist!
By: Olle Johansson (oej) 2004-11-13 03:35:27.000-0600

Disable the OPTIONs packets by entering "qualify=no" in the configuration of the peer. Simple, if you read the documentation.

If we forget the options packets, that has *NOTHING* to do with authentication, what is your problem with authentication? There's no complete REGISTER dialogue in this report, only part of a REGISTER packet that answers a challenge we do not see. Please add a full SIP debug of the REGISTER transaction so we can see what happens.
By: Brian West (bkw918) 2004-11-13 14:39:12.000-0600

No his register line need a /contact

In addition he needs insecure=very and type=user in addition to a type=peer for outbound. This is clearly an example of how someone doesn't understand how asterisk matches peers/users (which isn't the greatest ya know) But you can make it work.. This IS SO NOT A BUT.

bkw
By: brads (brads) 2004-11-16 11:29:19.000-0600

We tried what you recommened. All it did was stop the registration attemts. Not registered with Primus yet, and now asterisk is not even trying. What can I post to assist with this?
By: Olle Johansson (oej) 2004-11-16 11:45:07.000-0600

In order to help you, I need to see a full SIP debug from a session with at least a debug level of 5.
By: brads (brads) 2004-11-16 11:55:01.000-0600

How do I get rid of the opaque parameter?

This is the conversation dealing with this!

tsmarttg1 [9:50 AM]: From what we can see, you should not be sending the opaque field in your REGISTER since we are not sending it to you
BSUMRALLL [9:52 AM]: that looks like the only thing?
BSUMRALLL [9:52 AM]: What should it look like?
tsmarttg1 [9:52 AM]: from what we see yes
tsmarttg1 [9:53 AM]: I believe the opaque parameter is an additional security feature. If we send it to you in the Challenge, you are supposed to send it back to us unchanged. Since we dont' even send the parameter, I don't think you should be sending it either
By: brads (brads) 2004-11-16 12:10:06.000-0600

attempt 1

Via: SIP/2.0/UDP 67.94.247.42:5060;branch=z9hG4bK059ec291
From: <sip:xxxxxxxxxx@209.227.167.232>;tag=as66ef438d
To: <sip:xxxxxxxx@209.227.167.232>
Call-ID: 7545e146515f007c5bd062c212200854@67.94.247.43
CSeq: 102 REGISTER
User-Agent: Asterisk PBX
Expires: 160
Contact: <sip:s@xxxxxxxxx>
Event: registration
Content-Length: 0

edited on: 11-16-04 12:17
By: brads (brads) 2004-11-16 12:10:35.000-0600

401 first attempt

Via: SIP/2.0/UDP xxxxxxxxx:5060;received=xxxxxxxxxxx;rport=5060;branch=z9hG4bK059ec291
From: <sip:xxxxxxxx@209.227.167.232:5060>;tag=as66ef438d
To: <sip:xxxxxxxx@209.227.167.232:5060>;tag=68e41402
Call-ID: 7545e146515f007c5bd062c212200854@xxxxxxxx
CSeq: 102 REGISTER
WWW-Authenticate: Digest algorithm=MD5,domain="/",nonce="nD94DQTpAwA=5fe5dd55d52b99e4d267e7c106a980f2675bf4bb",realm="sipinfo.iprimus.net"
Content-Length: 0

edited on: 11-16-04 12:18
By: brads (brads) 2004-11-16 12:11:20.000-0600

attempt 2

From: <sip:xxxxxxxxx@209.227.167.232>;tag=as66ef438d
To: <sip:xxxxxxxxx@209.227.167.232>;tag=68e41402
Call-ID: 7545e146515f007c5bd062c212200854@67.94.247.43
CSeq: 103 REGISTER
User-Agent: Asterisk PBX
Authorization: Digest username="xxxxxxxxxx", realm="sipinfo.iprimus.net", algorithm=MD5, uri="/", nonce="nD94DQTpAwA=5fe5dd55d52b99e4d267e7c106a980f2675bf4bb", response="bed09bedec400c684812b4e87c9e5d27", opaque=""
Expires: 160
Contact: <sip:s@xxxxxxxx>
Event: registration
Content-Length: 0

edited on: 11-16-04 12:19
By: brads (brads) 2004-11-16 12:12:17.000-0600

retry 401

Via: SIP/2.0/UDP 67.94.247.42:5060;received=67.94.247.42;rport=5060;branch=z9hG4bK6f66cfa6
From: <sip:xxxxxxxxx@209.227.167.232:5060>;tag=as66ef438d
To: <sip:xxxxxxxxx@209.227.167.232:5060>;tag=68e41402
Call-ID: 7545e146515f007c5bd062c212200854@67.94.247.43
CSeq: 103 REGISTER
WWW-Authenticate: Digest algorithm=MD5,domain="/",nonce="syd6DQTpAwA=a5ec63e01f3a1b305ff831fca502302bff54fb69",realm="sipinfo.iprimus.net"
Content-Length: 0

edited on: 11-16-04 12:19
By: Olle Johansson (oej) 2004-11-16 12:17:07.000-0600

Brads, I need a full SIP debug output, not incomplete packets.
I will check into the opaque part of the digest auth.
By: brads (brads) 2004-11-16 12:25:25.000-0600

The packets should be the most helpful,,, this is "exactly" what the software is spitting out. I can send you the actual packets themselves if you like!
sip debug reviels this!

== Manager 'cron' logged on from 127.0.0.1
== Manager 'cron' logged off from 127.0.0.1
Nov 16 10:20:13 NOTICE[1089333952]: chan_sip.c:4035 sip_reg_timeout: Registration for 'xxxxxxxxxx@209.227.167.232' timed out, trying again
Nov 16 10:20:13 NOTICE[1089333952]: chan_sip.c:6752 handle_response: Failed to authenticate on REGISTER to '<sip:xxxxxxxxx@209.227.167.232>;tag=as7da505be'
Nov 16 10:20:33 NOTICE[1089333952]: chan_sip.c:4035 sip_reg_timeout: Registration for 'xxxxxxxx@209.227.167.232' timed out, trying again
Nov 16 10:20:33 NOTICE[1089333952]: chan_sip.c:6752 handle_response: Failed to authenticate on REGISTER to '<sip:xxxxxxxxxxxx@209.227.167.232>;tag=as258b25e2'
sip debug
SIP Debugging Enabled
*CLI> Nov 16 10:20:53 NOTICE[1089333952]: chan_sip.c:4035 sip_reg_timeout: Registration for 'xxxxxxxxxxx@209.227.167.232' timed out, trying again
11 headers, 0 lines
Reliably Transmitting:
REGISTER sip:209.227.167.232 SIP/2.0
Via: SIP/2.0/UDP xxxxxxxxxxx:5060;branch=z9hG4bK5a6d9160
From: <sip:xxxxxxxxxxx@209.227.167.232>;tag=as5bb3186f
To: <sip:xxxxxxxxxxx@209.227.167.232>
Call-ID: 7545e146515f007c5bd062c212200854@xxxxxxxxxx
CSeq: 321 REGISTER
User-Agent: Asterisk PBX
Expires: 160
Contact: <sip:s@xxxxxxxxxxx>
Event: registration
Content-Length: 0

(no NAT) to 209.227.167.232:5060

Sip read:
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP xxxxxxxxxxx:5060;received=xxxxxxxxxxx;rport=5060;branch=z9hG4bK5a6d9160
From: <sip:xxxxxxxxxxx@209.227.167.232:5060>;tag=as5bb3186f
To: <sip:xxxxxxxxxxx@209.227.167.232:5060>;tag=e90f252a
Call-ID: 7545e146515f007c5bd062c212200854@67.94.247.43
CSeq: 321 REGISTER
WWW-Authenticate: Digest algorithm=MD5,domain="/",nonce="gcioZATpAwA=d698543378b32ce922f6b6a066a9b1581b61f71f",realm="sipinfo.iprimus.net"
Content-Length: 0

8 headers, 0 lines
12 headers, 0 lines
Reliably Transmitting:
REGISTER sip:209.227.167.232 SIP/2.0
Via: SIP/2.0/UDP xxxxxxxxxxx:5060;branch=z9hG4bK71374a03
From: <sip:xxxxxxxxxxx@209.227.167.232>;tag=as5bb3186f
To: <sip:xxxxxxxxxxx@209.227.167.232>;tag=e90f252a
Call-ID: 7545e146515f007c5bd062c212200854@67.94.247.43
CSeq: 322 REGISTER
User-Agent: Asterisk PBX
Authorization: Digest username="xxxxxxxxxxx", realm="sipinfo.iprimus.net", algorithm=MD5, uri="/", nonce="gcioZATpAwA=d698543378b32ce922f6b6a066a9b1581b61f71f", response="28d5ea0f5a6349e790190c2c3cb739f2", opaque=""
Expires: 160
Contact: <sip:s@xxxxxxxxxxx>
Event: registration
Content-Length: 0

(no NAT) to 209.227.167.232:5060

Sip read:
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP xxxxxxxxxxx:5060;received=xxxxxxxxxxx;rport=5060;branch=z9hG4bK71374a03
From: <sip:xxxxxxxxxxx@209.227.167.232:5060>;tag=as5bb3186f
To: <sip:xxxxxxxxxxx@209.227.167.232:5060>;tag=e90f252a
Call-ID: 7545e146515f007c5bd062c212200854@67.94.247.43
CSeq: 322 REGISTER
WWW-Authenticate: Digest algorithm=MD5,domain="/",nonce="v2CqZATpAwA=486ddebedb45f870afca54f627995eb54a059217",realm="sipinfo.iprimus.net"
Content-Length: 0

8 headers, 0 lines
12 headers, 0 lines
Reliably Transmitting:
REGISTER sip:209.227.167.232 SIP/2.0
Via: SIP/2.0/UDP xxxxxxxxxxx:5060;branch=z9hG4bK56716099
From: <sip:xxxxxxxxxxx@209.227.167.232>;tag=as5bb3186f
To: <sip:xxxxxxxxxxx@209.227.167.232>;tag=e90f252a
Call-ID: 7545e146515f007c5bd062c212200854@67.94.247.43
CSeq: 323 REGISTER
User-Agent: Asterisk PBX
Authorization: Digest username="xxxxxxxxxxx", realm="sipinfo.iprimus.net", algorithm=MD5, uri="/", nonce="v2CqZATpAwA=486ddebedb45f870afca54f627995eb54a059217", response="e8465977ede8ca6f2aead35866c3afb8", opaque=""
Expires: 160
Contact: <sip:s@xxxxxxxxxxx>
Event: registration
Content-Length: 0

(no NAT) to 209.227.167.232:5060

Sip read:
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP xxxxxxxxxxx:5060;received=xxxxxxxxxxx;rport=5060;branch=z9hG4bK56716099
From: <sip:xxxxxxxxxxx@209.227.167.232:5060>;tag=as5bb3186f
To: <sip:xxxxxxxxxxx@209.227.167.232:5060>;tag=e90f252a
Call-ID: 7545e146515f007c5bd062c212200854@xxxxxxxxxx
CSeq: 323 REGISTER
WWW-Authenticate: Digest algorithm=MD5,domain="/",nonce="nfmrZATpAwA=11abb4a913533b4b5804815ddd37b6269b56272f",realm="sipinfo.iprimus.net"
Content-Length: 0

8 headers, 0 lines
Nov 16 10:20:53 NOTICE[1089333952]: chan_sip.c:6752 handle_response: Failed to authenticate on REGISTER to '<sip:xxxxxxxxxxx@209.227.167.232>;tag=as5bb3186f'
Destroying call '7545e146515f007c5bd062c212200854@xxxxxxxxxx'
== Parsing '/etc/asterisk/manager.conf': Found
== Manager 'cron' logged on from 127.0.0.1
== Manager 'cron' logged off from 127.0.0.1
Nov 16 10:21:13 NOTICE[1089333952]: chan_sip.c:4035 sip_reg_timeout: Registration for 'xxxxxxxxxxx@209.227.167.232' timed out, trying again
11 headers, 0 lines
Reliably Transmitting:
REGISTER sip:209.227.167.232 SIP/2.0
Via: SIP/2.0/UDP xxxxxxxxxxx:5060;branch=z9hG4bK40e59456
From: <sip:xxxxxxxxxxx@209.227.167.232>;tag=as48735aff
To: <sip:xxxxxxxxxxx@209.227.167.232>
Call-ID: 7545e146515f007c5bd062c212200854@xxxxxxxxxx
CSeq: 324 REGISTER
User-Agent: Asterisk PBX
Expires: 160
Contact: <sip:s@xxxxxxxxxxx>
Event: registration
Content-Length: 0

(no NAT) to 209.227.167.232:5060

Sip read:
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP xxxxxxxxxxx:5060;received=xxxxxxxxxxx;rport=5060;branch=z9hG4bK40e59456
From: <sip:xxxxxxxxxxx@209.227.167.232:5060>;tag=as48735aff
To: <sip:xxxxxxxxxxx@209.227.167.232:5060>;tag=374eb12c
Call-ID: 7545e146515f007c5bd062c212200854@xxxxxxxxxx
CSeq: 324 REGISTER
WWW-Authenticate: Digest algorithm=MD5,domain="/",nonce="V9faZQTpAwA=2f5cd4f5d6151359a5883ed74f9a666e4f3a1f3e",realm="sipinfo.iprimus.net"
Content-Length: 0

8 headers, 0 lines
12 headers, 0 lines
Reliably Transmitting:
REGISTER sip:209.227.167.232 SIP/2.0
Via: SIP/2.0/UDP xxxxxxxxxxx:5060;branch=z9hG4bK429982b8
From: <sip:xxxxxxxxxxx@209.227.167.232>;tag=as48735aff
To: <sip:xxxxxxxxxxx@209.227.167.232>;tag=374eb12c
Call-ID: 7545e146515f007c5bd062c212200854@xxxxxxxxxx
CSeq: 325 REGISTER
User-Agent: Asterisk PBX
Authorization: Digest username="xxxxxxxxxxx", realm="sipinfo.iprimus.net", algorithm=MD5, uri="/", nonce="V9faZQTpAwA=2f5cd4f5d6151359a5883ed74f9a666e4f3a1f3e", response="5b4c5e38f73a38710053483ce3a3e021", opaque=""
Expires: 160
Contact: <sip:s@xxxxxxxxxxx>
Event: registration
Content-Length: 0

(no NAT) to 209.227.167.232:5060

Sip read:
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP xxxxxxxxxxx:5060;received=xxxxxxxxxxx;rport=5060;branch=z9hG4bK429982b8
From: <sip:xxxxxxxxxxx@209.227.167.232:5060>;tag=as48735aff
To: <sip:xxxxxxxxxxx@209.227.167.232:5060>;tag=374eb12c
Call-ID: 7545e146515f007c5bd062c212200854@xxxxxxxxxx
CSeq: 325 REGISTER
WWW-Authenticate: Digest algorithm=MD5,domain="/",nonce="C4fcZQTpAwA=4a67b6a7faccbc7cc5835fe97cb23a9f7eba8c1d",realm="sipinfo.iprimus.net"
Content-Length: 0

8 headers, 0 lines
12 headers, 0 lines
Reliably Transmitting:
REGISTER sip:209.227.167.232 SIP/2.0
Via: SIP/2.0/UDP xxxxxxxxxxx:5060;branch=z9hG4bK1c940a15
From: <sip:xxxxxxxxxxx@209.227.167.232>;tag=as48735aff
To: <sip:xxxxxxxxxxx@209.227.167.232>;tag=374eb12c
Call-ID: 7545e146515f007c5bd062c212200854@xxxxxxxxxx
CSeq: 326 REGISTER
User-Agent: Asterisk PBX
Authorization: Digest username="xxxxxxxxxxx", realm="sipinfo.iprimus.net", algorithm=MD5, uri="/", nonce="C4fcZQTpAwA=4a67b6a7faccbc7cc5835fe97cb23a9f7eba8c1d", response="b711d332abd0e3972a98c171c2d0e0ec", opaque=""
Expires: 160
Contact: <sip:s@xxxxxxxxxxx>
Event: registration
Content-Length: 0

(no NAT) to 209.227.167.232:5060

edited on: 11-16-04 12:32
By: brads (brads) 2004-11-16 12:29:41.000-0600

registration parameters

register => xxxxxxxxxxx:xxxxxxxxxxx@209.227.167.232:5060
;register => xxxxxxxxxxx:xxxxxxxxxxx@209.227.167.232:5060/2139880045
;register => xxxxxxxxxxx:xxxxxxxxxxx@209.227.167.232:5060/2139880065

[primus]
type=user
type=peer
host=209.227.167.232
username=xxxxxxxxxxx
md5secret=xxxxxxxxxxx
insecure=very
qualify=no
;canreinvite=yes
nat=no
;auth=md5
context=from-sip
disallow=all
allow=gsm

;[primus]
;type=peer
;secret=xxxxxxxxxxx
;insecure=very
;username=xxxxxxxxxxx
;fromuser=xxxxxxxxxxx
;host=209.227.167.232
;context=from-sip

;[primus]
;type=user
;secret=xxxxxxxxxxx
;insecure=very
;username=xxxxxxxxxxx
;fromuser=xxxxxxxxxxx
;host=209.227.167.232
;context=from-sip
By: brads (brads) 2004-11-16 18:32:27.000-0600

Oh, the packets are not incomplete, they are in readable format. I could submit the binary version "in full" if you like!
By: brads (brads) 2004-11-16 21:29:02.000-0600

A request to assist me and all whom embrace asterisk as a standard!

specific documentation to be published that exactly defines the Asterisk key words ex... type=,qualify=,host=,,,, etc.... and how it is directly translated into the specific outgoing packet!

No body will have authentication "unknown" issues!
ex.
qualify will translate to the packet looking like this...........
host will translate to the packet looking like this............
etc.....

NOT "RFC" implies this!, which is all that is availible now!
Please provide us with the smoking gun!
because the packet is "truely" all that matters!

edited on: 11-16-04 23:53
By: brads (brads) 2004-11-17 11:22:14.000-0600

Any word on the opaque?
By: khb (khb) 2004-11-17 13:37:10.000-0600

There is nothing wrong with your opaque value, Asterisk should just return whatever the server supplies. It's used for maintaining state on the server.

The problem with your requests is that the domain is transmitted as "/", asterisk will take that and formulate the URI and digest with it in response, whereas it should be the same as the request uri for the REGISTER. That's why your authentication fails.
Asterisk should be handling this better.

edited on: 11-17-04 14:03
By: brads (brads) 2004-11-17 14:27:30.000-0600

OK, maybe, but that leaves me alittle confused. They first send the value domain="/" . That means that they have no specific request for "domain" in that field, hence the blank seperator, right? Asterisk the returns the value domain="/" . Matching thier request, right? But in that same 2nd packet, it is transmiting opaque="" . Then thier server says opaque=""????? what is that? hence
401 Unauthorized

Proxy should be a "match exacty or you do not pass" technology!

We request
102 REGISTER

They Reply

algorithm=MD5
domain="/"
nonce="nD94DQTpAwA=5fe5dd55
d52b99e4d267e7c106a980f2675bf4bb"
realm="sipinfo.iprimus.net"
username and password are a given that it needs them!

We respond
username="xxxxxxxxx"
realm="sipinfo.iprimus.net"
algorithm=MD5
uri="/" "I am not 100% sure they
require a domain in thier proxy config,
but can't this simply be staticaly
configured in asterisk somewhere to
meet this value????
nonce="nD94DQTpAwA=5fe5dd55d52
b99e4d267e7c106a980f2675bf4bb"
response="bed09bedec
400c684812b4e87c9e5d27"
opaque=""

They Reply

algorithm=MD5 good
domain="/" we don't need
one, so good
realm="sipinfo.iprimus.net" good
"no response to opaque" They say
they have
no idea what
to do with
this value
nonce="syd6DQTpAw
=a5ec63e01f3a1b305f
f831fca502302bff54fb69" now changed

edited on: 11-17-04 15:10

edited on: 11-17-04 15:12
By: brads (brads) 2004-11-17 15:49:24.000-0600

RoryNOC is away at 1:13 PM
BSUMRALLL [1:14 PM]: Rory, do you have a minute? I have a question for you?
BSUMRALLL [1:14 PM]: is your proxy requesting a domain name in your authentication?
The packets request from you is domain="/"
our response to you is uri="/"
"we are not configued for a domain on this box!"
I am told that the

There is nothing wrong with your opaque value, "Asterisk should just return whatever the server supplies."

Not sure on that one myself

But if you are looking for a domain, it is not configured on this box!!
RoryNOC returned at 1:17 PM
RoryNOC [1:17 PM]: I have sent this off to Tommy
BSUMRALLL [1:26 PM]: thank you!
RoryNOC [1:38 PM]: we don't even send teh opaque field though

edited on: 11-17-04 15:50
By: khb (khb) 2004-11-17 16:08:58.000-0600

Again, the opaque value is totally irrelevant here. If they don't send it, that's ok too, it's blank therefore. Asterisk should probably also not return it.

The problem is the domain="/" value. domain should be a list of URIs that the client can send the authentication request to. I suppose that "/" is actually a valid relative URI for the sending server, so Asterisk should probably [A] treat it as if domain was empty or [B] properly translate it into absoluteURI.
Is there any way you can reconfigure the server to not send domain or send domain=""

Attached patch might implement solution [A]
but Asterisk should properly break down the domain value into absolute URIs and then start contacting them in sequence.

edited on: 11-17-04 16:13
By: brads (brads) 2004-11-17 16:17:52.000-0600

example of proxy authentication... Notice, "no opaque" as per RFC 3261

20.28 Proxy-Authorization

The Proxy-Authorization header field allows the client to identify
itself (or its user) to a proxy that requires authentication. A
Proxy-Authorization field value consists of credentials containing
the authentication information of the user agent for the proxy and/or
realm of the resource being requested.

See Section 22.3 for a definition of the usage of this header field.

This header field, along with Authorization, breaks the general rules
about multiple header field names. Although not a comma-separated
list, this header field name may be present multiple times, and MUST
NOT be combined into a single header line using the usual rules
described in Section 7.3.1.

Example:

Proxy-Authorization: Digest username="Alice", realm="atlanta.com",
nonce="c60f3082ee1212b402a21831ae",
response="245f23415f11432b3434341c022"

User to User (notice the use of opaque=""
I am not registering to a user, I am registering to a proxy, a SIP proxy!

22.2 User-to-User Authentication

When a UAS receives a request from a UAC, the UAS MAY authenticate
the originator before the request is processed. If no credentials
(in the Authorization header field) are provided in the request, the
UAS can challenge the originator to provide credentials by rejecting
the request with a 401 (Unauthorized) status code.

The WWW-Authenticate response-header field MUST be included in 401
(Unauthorized) response messages. The field value consists of at
least one challenge that indicates the authentication scheme(s) and
parameters applicable to the realm.

An example of the WWW-Authenticate header field in a 401 challenge
is:

WWW-Authenticate: Digest
realm="biloxi.com",
qop="auth,auth-int",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
opaque="5ccc069c403ebaf9f0171e9517f40e41"

When the originating UAC receives the 401 (Unauthorized), it SHOULD,
if it is able, re-originate the request with the proper credentials.
The UAC may require input from the originating user before
proceeding. Once authentication credentials have been supplied
(either directly by the user, or discovered in an internal keyring),
UAs SHOULD cache the credentials for a given value of the To header
field and "realm" and attempt to re-use these values on the next
request for that destination. UAs MAY cache credentials in any way
they would like.
By: brads (brads) 2004-11-17 16:22:36.000-0600

Which chan_sip.c should I patch

/usr/src/asterisk/asterisk/channels/chan_sip.c
/usr/src/asterisk/channels/chan_sip.c
By: brads (brads) 2004-11-17 16:39:46.000-0600

# patch -l /usr/lib/asterisk/modules/chan_sip2.c /root/chan_sip.c.patch.txt
patching file /usr/lib/asterisk/modules/chan_sip2.c
Hunk #1 FAILED at 6354.
1 out of 1 hunk FAILED -- saving rejects to file /usr/lib/asterisk/modules/chan_sip2.c.rej

edited on: 11-17-04 17:06
By: brads (brads) 2004-11-17 17:10:03.000-0600

# patch -i /usr/lib/asterisk/modules/chan_sip2.c /root/chan_sip.c.patch.txt
patching file /root/chan_sip.c.patch.txt
Hunk #1 FAILED at 1.
Hunk #2 FAILED at 70.
Hunk #3 FAILED at 482.
Hunk #4 FAILED at 499.
Hunk ASTERISK-1 FAILED at 944.
Hunk ASTERISK-2 FAILED at 4839.
Hunk ASTERISK-3 FAILED at 5285.
Hunk ASTERISK-4 FAILED at 5860.
Hunk ASTERISK-5 FAILED at 5914.
Hunk ASTERISK-6 FAILED at 6008.
Hunk ASTERISK-7 FAILED at 9345.
Hunk ASTERISK-8 FAILED at 9380.
Hunk ASTERISK-9 FAILED at 9391.
Hunk ASTERISK-10 FAILED at 9419.
Hunk ASTERISK-11 FAILED at 9427.
Hunk ASTERISK-12 FAILED at 9456.
Hunk ASTERISK-13 FAILED at 9476.
Hunk ASTERISK-14 FAILED at 9506.
Hunk ASTERISK-15 FAILED at 9542.
Hunk ASTERISK-16 FAILED at 9556.
Hunk ASTERISK-17 FAILED at 9615.
Hunk ASTERISK-18 FAILED at 9642.
Hunk ASTERISK-19 FAILED at 9680.
Hunk ASTERISK-20 FAILED at 10037.
Hunk ASTERISK-21 FAILED at 10134.
Hunk ASTERISK-22 FAILED at 10487.
26 out of 26 hunks FAILED -- saving rejects to file /root/chan_sip.c.patch.txt.rej
By: brads (brads) 2004-11-17 17:19:06.000-0600

Primus request the Domain="/"
I do not have much controll over that, I have made the request though!
By: khb (khb) 2004-11-18 11:20:46.000-0600

You need to patch properly.

where ever your code resides:
cd /usr/src/asterisk/channels
patch chan_sip.c <chan_sip.c_digest_patch.txt

then recompile.
By: brads (brads) 2004-11-18 16:35:02.000-0600

It has to be that dang opaque=""

REGISTER sip:209.227.167.232 SIP/2.0
Via: SIP/2.0/UDP 67.94.247.42:5060;branch=z9hG4bK696952cf
From: <sip:xxxxxxxxx@209.227.167.232>;tag=as54e49eb4
To: <sip:xxxxxxxxx@209.227.167.232>
Call-ID: 2d1d5ae96763845e75a2a8d408edbdab@67.94.247.43
CSeq: 102 REGISTER
User-Agent: Asterisk PBX
Expires: 160
Contact: <sip:s@xxxxxxxxx>
Event: registration
Content-Length: 0

SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP xxxxxxxxxx:5060;received=67.94.247.42;rport=5060;branch=z9hG4bK696952cf
From: <sip:xxxxxxxxx@209.227.167.232:5060>;tag=as54e49eb4
To: <sip:xxxxxxxxxx@209.227.167.232:5060>;tag=5ecfeb73
Call-ID: 2d1d5ae96763845e75a2a8d408edbdab@xxxxxxxxxxx
CSeq: 102 REGISTER
WWW-Authenticate: Digest algorithm=MD5,domain="/",nonce="b47t8C/pAwA=f5b7f8b6563940f23bfc14e82e13bcc8dd7a7afb",realm="sipinfo.iprimus.net"
Content-Length: 0

REGISTER sip:209.227.167.232 SIP/2.0
Via: SIP/2.0/UDP 67.94.247.42:5060;branch=z9hG4bK69febba9
From: <sip:xxxxxxxxxx@209.227.167.232>;tag=as54e49eb4
To: <sip:xxxxxxxxxxx@209.227.167.232>;tag=5ecfeb73
Call-ID: 2d1d5ae96763845e75a2a8d408edbdab@67.94.247.43
CSeq: 103 REGISTER
User-Agent: Asterisk PBX
Authorization: Digest username="xxxxxxxxxxx", realm="sipinfo.iprimus.net", algorithm=MD5, uri="sip:209.227.167.232", nonce="b47t8C/pAwA=f5b7f8b6563940f23bfc14e82e13bcc8dd7a7afb", response="a78d0d84ee3ff84fec02c3c05fa8bfed", opaque=""
Expires: 160
Contact: <sip:s@xxxxxxxxxxxx>
Event: registration
Content-Length: 0

SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 67.94.247.42:5060;received=67.94.247.42;rport=5060;branch=z9hG4bK69febba9
From: <sip:xxxxxxxxx@209.227.167.232:5060>;tag=as54e49eb4
To: <sip:xxxxxxxxxx@209.227.167.232:5060>;tag=5ecfeb73
Call-ID: 2d1d5ae96763845e75a2a8d408edbdab@xxxxxxxxxxx
CSeq: 103 REGISTER
WWW-Authenticate: Digest algorithm=MD5,domain="/",nonce="Cenv8C/pAwA=a34a3834ecaaa927e6622277c614e0d9c2a88e64",realm="sipinfo.iprimus.net"
Content-Length: 0

edited on: 11-18-04 17:19
By: brads (brads) 2004-11-18 17:25:06.000-0600

opaque="" is a peer to peer registation usage field. This is a register to resgistrar method.

Can you please show me how to remove the opaque="" or provide a patch!
Pretty please!

edited on: 11-18-04 17:27
By: brads (brads) 2004-11-18 21:57:06.000-0600

Yes, your patch fixed the uri issue, but we were hesitent on that being our problem from the begining. I was 60% sure that the opaque issue was the cause before. Now WE ARE 97% SURE! Myself and the Primus senior dev. team! Thier response to our packet "is" RFC compliant. Asterisk returns a "non RFC compliant" "opaque field" for registeration to the registrar field. We beg of you, please help us eliminate the "opaque" field! If we are wrong, then we are wrong! The gut feeling is we are correct!
We are "not" software programers like yourself! We are admin techs, we are at your mercy! We only know the behavioral patterns of the software, and thier response. The proxy from what we can telll says "NO OPAQUE"
Can we please disable the opaque for registration?

edited on: 11-18-04 22:15
By: brads (brads) 2004-11-18 22:06:51.000-0600

just a test! please!
By: Mark Spencer (markster) 2004-11-19 00:25:22.000-0600

Why don't you just take it out and see if that fixes it?
By: khb (khb) 2004-11-19 08:01:27.000-0600

To be formally correct Asterisk shouldn't be sending the opaque parameter, since none was sent from the server, however (if I recall) the RFC also says that superfluous parameters should be ignored when parsing. On top, we are sending an empty parameter and the server should accept that as what it means. It can't use an opaque parameter when it doesn't have a value. The opaque parameter is not used for the authentication itself. If the server doesn't like the parameter, it should send back a 400 (Bad Request) not a 401 which means the authentication failed. I do believe this to be a parsing and exception handling error on part of the server, despite the fact that they are sending a compliant packet. They seem to be doing other strange stuff, such as sending a domain="/", can't recall seeing that before from a SIP server. Makes more sense for HTTP URLs.
Somehow I feel we are debugging someone elses SIP implementation here.
By: brads (brads) 2004-11-19 08:40:08.000-0600

I have to admit, you have a good point there!
By: khb (khb) 2004-11-19 09:46:03.000-0600

ok, I spliced into the current cvs version a new SIP auth module which parses more details.
And I added the domain="/" fix to my version as well.
It compiles, but hasn't been run with current cvs. Give it a try, you need to start the patch from a brand new copy of chan_sip.c. You know the procedure now.
I'll check back in later when I return.
By: Olle Johansson (oej) 2004-11-19 10:52:13.000-0600

khb: Is this patch disclaimed?
By: brads (brads) 2004-11-19 20:18:50.000-0600

It appears to have worked like a champ. First shot the sip show registry showed us as registered with Primus! The rest of the debug will continue on Monday!
By: Mark Spencer (markster) 2004-12-05 14:09:01.000-0600

What's the story here? Is there a patch to be applied and if so, which one and is it disclaimed? :)
By: Olle Johansson (oej) 2004-12-12 03:54:56.000-0600

Seems to be the other side that is buggy and no response from the reporter.