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?


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.

Dear Leonard,

I recognized same problem. The phones of the 7-Series have even in actual fw 8.9.3.80 this problem with digest authentification. The nonce-key is accidentally shorted by the phone, when it is sending it back to the server.


As I was investigating with Wireshark the HTTP-Stream, I found that this problem affects also the minibrowser when it would like to access HTTP password protected realm by digest authentification.


Example:


GET /xyzapi/image.jpeg HTTP/1.1

Host: 10.0.10.1

Content-Length: 0

Accept: */*

Accept-Language: en

Connection: Keep-Alive

Keep-Alive: 5

X-snom-Vpn: not-supported

X-snom-Individual-SHA256: unavailable

User-Agent: Mozilla/4.0 (compatible; snom760-SIP 8.9.3.80 2010.06 000413717133 SXM:0 UXM:0)

HTTP/1.1 401 Unauthorized

WWW-Authenticate: Digest realm="Protected", charset="UTF-8", nonce="5b3a492f:2ad56a41f6d8af5c8a5b7fd569939eae", qop="auth"

Content-Type: text/html

Content-Length: 351

Date: Mon, 02 Jul 2018 15:47:59 GMT

Server: lighttpd/1.4.45

<?xml version="1.0" encoding="iso-8859-1"?>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">

<head>

<title>401 - Unauthorized</title>

</head>

<body>

<h1>401 - Unauthorized</h1>

</body>

</html>

GET /xyzapi/image.jpeg HTTP/1.1

Host: 10.0.10.1

Content-Length: 0

Authorization: Digest username="user01",realm="Protected",nonce="5b3a492f",uri="/xyzapi/image.jpeg",response="e1ba81205c85d1aac0f4b8d1545b2fd4"

Accept-Language: en

Connection: Keep-Alive

Keep-Alive: 5

X-snom-Vpn: not-supported

X-snom-Individual-SHA256: unavailable

User-Agent: Mozilla/4.0 (compatible; snom760-SIP 8.9.3.80 2010.06 000413717133 SXM:0 UXM:0)

HTTP/1.1 401 Unauthorized

WWW-Authenticate: Digest realm="Protected", charset="UTF-8", nonce="5b3a492f:f0aba5a878545e51bc073c8ea1bd4c10", qop="auth", stale=true

Content-Type: text/html



The nonce in the response from the phone is cut off after the ' : ' (Double point).

This is a bug. Definitive as I traced in Wireshark diverse browsers and see that it handled correctly the digest authentification.

Johannes

Johannes,


You have encountered a different issue for which we do have an open bug report for (SAP-2688 RFC 7616 Snom phones do not support character ":" in challenge nonce)



Regards,


Sean Collins

Snom Support



Login or Signup to post a comment