Can't verify STUN package

347 views
Skip to first unread message

Gio Gio

unread,
Oct 21, 2013, 7:47:11 AM10/21/13
to discuss...@googlegroups.com
When I get STUN packages from peer(peer is google-chrome v-30) can't correctly verify package. 
attribute MESSAGE-INTEGRITY contain hmac-sha1. when i try to calculate(python script) hash not equal.
I use short-term(I i know browser support short-term auth form). Hash = HMAC-SHA1(Key, Text) where key is Key = SASLprep(password).
password took from SDP ice-pwd attribute. I think I use correct algorithm but still fail verification.
Can anyone recommend correct algorithm or documentation where declared hash for webrtc?

Oleg Moskalenko

unread,
Oct 21, 2013, 1:02:29 PM10/21/13
to discuss...@googlegroups.com
WebRTC uses long-term credentials mechanism of TURN.

Gio Gio

unread,
Oct 22, 2013, 2:03:29 AM10/22/13
to discuss...@googlegroups.com
Thank you.

And another question. can you recommend any RFC where declared how to obtain Realm for long-term credentials.
For peer connections I not use TURN server(only STUN). and wireshark also not fix any TURN package send/receive.
Anyway can't obtain realm for long-term key generation.

Oleg Moskalenko

unread,
Oct 22, 2013, 2:39:24 AM10/22/13
to discuss...@googlegroups.com
If you are not using TURN server then you do not need any credentials whether long-term or short-term, neither you need any realm. STUN Binding requests are usually anonymous.

If you do use TURN then the realm is an arbitrary well-formed string, usually your company domain name, for example "north.gov". You have to configure that realm on the TURN server and it will send the realm to the clients in the 401 responses.

Oleg

Gio Gio

unread,
Oct 22, 2013, 2:54:31 AM10/22/13
to discuss...@googlegroups.com
mmm. when I build stun package(bind user) and send I have got answer 401 unauthorized. as I see in cromium source there maybe 2 reason.
or username is invalid or message-integrity hash not verified. I have doubts that problem is correct hmac-sha1 hash building. because I can't 
correctly verify incoming user bind request from another peer. also I think another problem when I send xor-mapped-address to another peer.
it ignored entirely not any answer. I trying to find hmac-sha1 build correct form. btw. I use only stun-server(mozilla stun stun:23.21.150.121),
but chromiums as webrtc peers.

Gio Gio

unread,
Oct 22, 2013, 7:00:20 AM10/22/13
to discuss...@googlegroups.com
I trying to checking chromium sources and try to understand how work bool StunMessage::AddMessageIntegrity.
seems it take previous data and calculate hmac-sha1 using key(which is password). but it's strange that it not check 
stun message header, and header length is previous data not increased by message-integrity and fingerprint attributes size.

Oleg Moskalenko

unread,
Oct 22, 2013, 2:40:01 PM10/22/13
to discuss...@googlegroups.com
There is no "bind user" request in STUN. There is "Binding" request. And it usually does not require any authorization. The STUN server MAY require authorization of the "Binding" request - this is not prohibited by the specs - but I have not heard of any server doing that by default. Our rfc5766-turn-server needs special settings (--secure-stun option) to ask for Binding authorization.

The requests which require authorization are TURN requests - like "Allocate", "Bind channel", "Create permission", etc. You must be using a TURN server to see those requests.

Gio Gio

unread,
Oct 23, 2013, 1:15:06 AM10/23/13
to discuss...@googlegroups.com
yes, right. there is only binding request. I have meant binding request with user-name attribute.

Oleg Moskalenko

unread,
Oct 23, 2013, 2:53:37 AM10/23/13
to discuss...@googlegroups.com
Try to send it without the user-name attribute.

Gio Gio

unread,
Oct 24, 2013, 8:07:55 AM10/24/13
to discuss...@googlegroups.com
if I send without user attribute to stun server I have MAPPED-ADDRESS response, if I send it to peer(chromium) it ignore, no answer.


Gio Gio

unread,
Oct 24, 2013, 8:10:11 AM10/24/13
to discuss...@googlegroups.com
I found this strange answer reason. seems I have not correctly calculated hmac_sha1. I not changed stun message length to length without fingerprint.


On Monday, October 21, 2013 3:47:11 PM UTC+4, Gio Gio wrote:
Reply all
Reply to author
Forward
0 new messages