How can we help you today?
Start a new topic
Answered

Asterisk nonce length less than 128 bits

 

Hi,


I'm using snom phones 300 and 320 with firmare 8.7.5.35 or 8.7.5.44 and asterisk 13.12.1. (freepbx 13.0.190.12)

During each subscribe, the phone complains about the nonce length used by asterisk:

process_registrar_packet: 401 needs 128 bit nonce


Is it possible to force that nonce length ?


Thanks.

Best Answer

This looks like normal phone behavior. Is there a problem? Is the phone not working?


Catalina may pass on your concerns to her Product Management team but they will not fix this on their EOL devices. You're correct though, this should have been fixed well before those devices went EOL!

Do you have a SIP trace of the REGISTER and 401 Unauthorized packets?

Please find the requested info.


The log is containing a lot of this message:
Nb: extract at the end of today log, not corresponding with the SIP trace

Feb 8 20:12:04.182 [WARN ] SIP: process_registrar_packet: 401 needs 128 bit nonce

Feb 8 20:13:13.842 [WARN ] SIP: process_registrar_packet: 401 needs 128 bit nonce

Feb 8 20:14:01.773 [WARN ] SIP: process_registrar_packet: 401 needs 128 bit nonce

Feb 8 20:18:43.702 [WARN ] SIP: process_registrar_packet: 401 needs 128 bit nonce

Feb 8 20:19:52.013 [WARN ] SIP: process_registrar_packet: 401 needs 128 bit nonce

Feb 8 20:24:21.643 [WARN ] SIP: process_registrar_packet: 401 needs 128 bit nonce

Feb 8 20:29:02.942 [WARN ] SIP: process_registrar_packet: 401 needs 128 bit nonce

Feb 8 20:30:05.993 [WARN ] SIP: process_registrar_packet: 401 needs 128 bit nonce

Feb 8 20:31:50.503 [WARN ] SIP: process_registrar_packet: 401 needs 128 bit nonce

Feb 8 20:32:44.719 [WARN ] SIP: process_registrar_packet: 401 needs 128 bit nonce

Feb 8 20:36:32.339 [WARN ] SIP: process_registrar_packet: 401 needs 128 bit nonce


SIP Trace (captured yesterday):


Received from udp:192.168.6.3:5060 at Feb 7 10:14:03.499 (547 bytes):

SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.6.105:2048;branch=z9hG4bK-mfu0o6xcknyl;received=192.168.6.105;rport=2048
From: <sip:005@192.168.6.3>;tag=pe1n3ept6r
To: <sip:014@192.168.6.3;user=phone>;tag=as3b804590
Call-ID: 313438363435363736393233373336-ihr2bcmo25p5
CSeq: 3 SUBSCRIBE
Server: FPBX-13.0.190.12(13.12.1)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="3b71d7e5"
Content-Length: 0



--------------------------------------------------------------------------------

Sent to udp:192.168.6.3:5060 at Feb 7 10:14:03.518 (630 bytes):

SUBSCRIBE sip:014@192.168.6.3:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.6.105:2048;branch=z9hG4bK-t3pd2rz0lco4;rport
From: <sip:005@192.168.6.3>;tag=pe1n3ept6r
To: <sip:014@192.168.6.3;user=phone>;tag=as3b804590
Call-ID: 313438363435363736393233373336-ihr2bcmo25p5
CSeq: 4 SUBSCRIBE
Max-Forwards: 70
User-Agent: snom320/8.7.5.44
Contact: <sip:005@192.168.6.105:2048>;reg-id=1
Event: dialog
Accept: application/dialog-info+xml
Authorization: Digest username="005",realm="asterisk",nonce="3b71d7e5",uri="sip:014@192.168.6.3:5060",response="3ad171296d58faea3d5201ee19345d3b",algorithm=MD5
Expires: 3600
Content-Length: 0



--------------------------------------------------------------------------------

Received from udp:192.168.6.3:5060 at Feb 7 10:14:03.528 (526 bytes):

SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.6.105:2048;branch=z9hG4bK-t3pd2rz0lco4;received=192.168.6.105;rport=2048
From: <sip:005@192.168.6.3>;tag=pe1n3ept6r
To: <sip:014@192.168.6.3;user=phone>;tag=as3b804590
Call-ID: 313438363435363736393233373336-ihr2bcmo25p5
CSeq: 4 SUBSCRIBE
Server: FPBX-13.0.190.12(13.12.1)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Expires: 3600
Contact: <sip:014@192.168.6.3:5060>;expires=3600
Content-Length: 0



--------------------------------------------------------------------------------

Received from udp:192.168.6.3:5060 at Feb 7 10:14:03.538 (681 bytes):

NOTIFY sip:005@192.168.6.105:2048 SIP/2.0
Via: SIP/2.0/UDP 192.168.6.3:5060;branch=z9hG4bK7ac8e8e4;rport
Max-Forwards: 70
From: <sip:014@192.168.6.3;user=phone>;tag=as3b804590
To: <sip:005@192.168.6.3>;tag=pe1n3ept6r
Contact: <sip:014@192.168.6.3:5060>
Call-ID: 313438363435363736393233373336-ihr2bcmo25p5
CSeq: 104 NOTIFY
User-Agent: FPBX-13.0.190.12(13.12.1)
Subscription-State: active
Event: dialog
Content-Type: application/dialog-info+xml
Content-Length: 202

<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="2" state="full" entity="sip:014@192.168.6.3">
<dialog id="014">
<state>terminated</state>
</dialog>
</dialog-info>


--------------------------------------------------------------------------------

Sent to udp:192.168.6.3:5060 at Feb 7 10:14:03.552 (305 bytes):

SIP/2.0 200 Ok
Via: SIP/2.0/UDP 192.168.6.3:5060;branch=z9hG4bK7ac8e8e4;rport=5060
From: <sip:014@192.168.6.3;user=phone>;tag=as3b804590
To: <sip:005@192.168.6.3>;tag=pe1n3ept6r
Call-ID: 313438363435363736393233373336-ihr2bcmo25p5
CSeq: 104 NOTIFY
User-Agent: snom320/8.7.5.44
Content-Length: 0



--------------------------------------------------------------------------------

Received from udp:192.168.6.3:5060 at Feb 7 10:14:32.924 (699 bytes):

NOTIFY sip:005@192.168.6.105:2048 SIP/2.0
Via: SIP/2.0/UDP 192.168.6.3:5060;branch=z9hG4bK44bc5f0f;rport
Max-Forwards: 70
From: <sip:001@192.168.6.3;user=phone>;tag=as5f6ebdf0
To: <sip:005@192.168.6.3>;tag=a8smxeh2z4
Contact: <sip:001@192.168.6.3:5060>
Call-ID: 313438363435363736393234383833-w855853k9vgv
CSeq: 113 NOTIFY
User-Agent: FPBX-13.0.190.12(13.12.1)
Subscription-State: active
Event: dialog
Content-Type: application/dialog-info+xml
Content-Length: 220

<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="11" state="full" entity="sip:001@192.168.6.3">
<dialog id="001" direction="recipient">
<state>early</state>
</dialog>
</dialog-info>


Answer

This looks like normal phone behavior. Is there a problem? Is the phone not working?

Phone is globally working.
Some error messages and dropped communications:


Feb 8 17:42:47.937 [WARN ] SIP: transaction_timeout udp: 1006531 (32000)

Feb 8 17:42:47.938 [FATAL ] SIP: final transport error: invalid id 1006531

 

But the log complete fill-up by those "nonce" messages.


Thanks for your support.

"(SAP-2688 RFC 7616 Snom phones do not support character ":" in challenge nonce)"


But, how to fix that Bug for MP and SNOM 320/360?

Some are already EOL.. 


EOL or not EOL - It is and stays a BUG and I think it produces unnecessarily Network-traffic, stresses Asterisk and maybe also is the Reason for some Interruptions. :-(


Thanks for fixing it - also for the older devices - in advance.

Hello,


SAP-2688 has been solved in our latest release 10.1.33.33.


Unfortunately, for the EOS phones we can provide only security-related fixes. See https://helpdesk.snom.com/support/solutions/articles/6000183016-snom-products-lifecycle . I am sorry that I don't have better news.


Thanks

Catalina


Just to commet the discussion. The D715 and 715 have been fixed in the meanwhile in the new firmware (> 10.1.33.33).

I have to agree with "IT" - that he says it generates a lot of uncessary network traffic.

On other hand, Catalina, you are writing that there phones are only provided with Security relevant fixes - but the bug is a security problem for me.

We have had to downgrade to unprotected Basic Authentication instead of the more secure Digest Authentification.


As the fix has been already provided for the 715 series, it would be a glance to bring it  at least to the other 7xx series which are quite similar from the firmware.

Hello,


Just to note, it is important to understand the difference between EOL and EOS devices. Please have a look here: https://helpdesk.snom.com/support/solutions/articles/6000183016-snom-products-lifecycle -> please scroll down.


For EOS devices - Development of new features and bugfix: Only security-related bugfixing is provided

For EOL devices - Development of new features and bugfix: Not Provided


Regarding the bug: I understand your point however is the ":" character a general requirement for digest authentication? From my understanding of rfc7616, the nonce can be any string (rfc7616: "It is advised that this string be Base64 or hexadecimal data."), so a server can implement the RFC without necessarily using the ":" character.


Thanks

Catalina


"so a server can implement the RFC without necessarily using the ":" character."

So great idea, and now please go to Telekom, Sipgate, Dus.net... and let them do so!!! :-(


That's also a kind of strange, so lets say you offer a Product not working, you simply set it EOL and all your problems are gone?

Is ist such a great deal, do fix a simple  :  in the firmware?

All other devices - we use - are able to handle the doublepoint!


I also see it as great security problem, to use unsafe or none encryption!!


Also the 320 has that bug and as starting that Bug-Ticket 2 years ago,

 and also 3 month ago, it was NOT EOL!!!

By the way the SNOM meeting Point is NOT on your list of EOL-Devices

but has that Bug also since over 2 years!! Please fix that device and as you do so it would be a small step to fix 320 and 360 also. As likely is sell new devices the environment is more important to me to keep working devices running as long as possible!! 


And the new firmware is also not usable yet,

because of the new Bugs, you build in last year.

Hello,


Thank you for the feedback. I am sorry for the inconvenience this is causing you.


I have forwarded your concerns to our Product Management and we will post here as soon as we have a solution.


Thanks

Catalina


Thank you, would be grat. Maybe it is possible in one run to fix the old phones as well.

#GretaThunbergwillLOVEsonom

"SAP-2688 has been solved in our latest release 10.1.33.33."

   So please have a look at that part withe the ":" 

   Problem of fix and do it also for 320 and the SNOM MeetingPoint MP (wo is NOT EOL!!!)


"From my understanding of rfc7616, the nonce can be any string (rfc7616: "It is advised that this string be Base64 or hexadecimal data.")"

   There is no word of "without :" so maybe your understanding is a little stange? ;-)


"should have been fixed well before those devices went EOL!"

   So hurry up please! :-D


Thank you in advance!

Login or Signup to post a comment