Finding the USERNAME

According to the STUN protocol the USERNAME is defined by the bytes 0x0006 followed by a
two byte pad 0x00 and the length of the user name (0x11 or 17). Everything in STUN is in TLV format (type,
length, value). So the bytes of the USERNAME attribute in this STUN binding request are

The user name after the colon (8bc1dba4) is the user defined by the client when it made its initial SDP offer.
I’m not going to go into the offer/answer flow of SDP in this post but just know that this is a value that is
handed to you by the client.

Finding the MESSAGE-INTEGRITY

To verify no one has tampered with this STUN binding request we need to compute
the same MESSAGE-INTEGRITY hash that’s in the request. The MESSAGE-INTEGRITY attribute is
identified by the bytes 0x0008 followed by a two byte pad 0x00 and the length of the hash
(0x14 or 20). So the MESSAGE-INTEGRITY attribute of our request is

Unfortunately we can’t just throw that subset into the HMAC function and call it a day. We
need to alter the length byte of the subset so that it’s the subset’s length and not the length
of the full request. This length byte is at index 3 and, in our example, is 0x50 which is 80.

So we’ll calculate the subset length and, even though it’s not in our subset, we include the
length of the MESSAGE-INTEGRITY section header in our calculation. It will always have a length
of 4 bytes since everything is in TLV format.