Subject: Re: [BEHAVE] STUN fingerprint and integrity tests

From: "Denis-Courmont Remi (Nokia-TP-MSW/Helsinki)" <[email-masked]>
Date: Tue, 7 Aug 2007 18:15:13 +0300

You must be right, the SHA1s were computed according to -06.

I will fix them tomorrow. thanks for the catch.

Remi Denis-Courmont

--- message original ---
De : "ext Marc Petit-Huguenin" <[email-masked]>
Objet : Re: [BEHAVE] STUN fingerprint and integrity tests
Date : 7 août 2007
Heure : 18:55:38

Rémi Denis-Courmont wrote:
> [ Please direct responses to BEHAVE mailing list, NOT MMUSIC! ]
> 
> 	Hello,
> 
> If anyone is implementing an ICE or something-using-STUN stack, I have put 
> sample FINGERPRINT and MESSAGE-INTEGRITY test vectors. I might have messed 
> them up, since I have not had the chance to test with third parties.

It seems that you did not adjust the header length before calculating
the MESSAGE-INTEGRITY for the request message (see last paragraph of
section 14.4 of rfc3489bis-08).

-- 
Marc Petit-Huguenin           [                                 ]
Home: [email-masked] [RFC1855-compliant space for rent ]
Work: [email-masked]            [                                 ]
[                                                               ]

_______________________________________________
Behave mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/behave

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Wed, 8 Aug 2007 12:03:19 +0300

> I will fix them tomorrow. thanks for the catch.

Alright, here are the hopefully fixed vectors:

static const char req[] =
"\x00\x01\x00\x44"
"\x21\x12\xa4\x42\xb7\xe7\xa7\x01\xbc\x34\xd6\x86\xfa\x87\xdf\xae"
"\x00\x24\x00\x04" "\x6e\x00\x01\xff"
"\x80\x29\x00\x08" "\x93\x2f\xf9\xb1\x51\x26\x3b\x36\x00\x06\x00"
 "\x09\x65\x76\x74\x6a\x3a\x68\x36\x76\x59\x20\x20\x20"
"\x00\x08\x00\x14" "\x62\x4e\xeb\xdc\x3c\xc9\x2d\xd8\x4b\x74\xbf\x85"
  "\xd1\xc0\xf5\xde\x36\x87\xbd\x33"
"\x80\x28\x00\x04" "\xad\x8a\x85\xff";

static const char resp[] =
"\x01\x01\x00\x3c"
"\x21\x12\xa4\x42\xb7\xe7\xa7\x01\xbc\x34\xd6\x86\xfa\x87\xdf\xae"
"\x80\x22\x00\x0b" "\x74\x65\x73\x74\x20\x76\x65\x63\x74\x6f\x72\x20"
"\x00\x20\x00\x08" "\x00\x01\xa1\x47\x5e\x12\xa4\x43"
"\x00\x08\x00\x14" "\xab\x4e\x53\x29\x61\x00\x08\x4c\x89\xf2\x7c\x69"
 "\x30\x33\x5c\xa3\x58\x14\xea\x90"
"\x80\x28\x00\x04" "\xae\x25\x8d\xf2";

Do they look OK to you?

-- 
Rémi Denis-Courmont

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 08 Aug 2007 09:16:50 -0700

> "\x80\x28\x00\x04" "\xae\x25\x8d\xf2";

Yes, I added them to my unit tests.

Thanks.

---

From: "Alfred E. Heggestad" <[email-masked]>
Date: Thu, 09 Aug 2007 00:23:36 +0200

> "\x80\x28\x00\x04" "\xae\x25\x8d\xf2";

Remi, many thanks for doing this. It looks ok after I fixed some bugs in my
code. Is the 64-bytes HMAC-SHA1 padding removed from rfc3489-bis, btw?

could I ask that the USERNAME padding is changed from 0x20 to 0x00 ?

/alfred

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Thu, 9 Aug 2007 09:18:13 +0300

> code. Is the 64-bytes HMAC-SHA1 padding removed from rfc3489-bis, btw?

Yes. That text has been removed a bunch of revisions ago. You'd have to ask 
the editors why, but it was simply a "bad" idea - HMAC-SHA1 already pads 
internally anyway.

> could I ask that the USERNAME padding is changed from 0x20 to 0x00 ?

rfc3489bis-08 says attribute padding can be anything. I am purposedly using 
white spaces instead of nuls to root out incorrect C implementations. I 
should perhaps have used 0x41 to make it more obvious :)

-- 
Rémi Denis-Courmont

---

From: "Alfred E. Heggestad" <[email-masked]>
Date: Thu, 09 Aug 2007 19:12:44 +0200

> the editors why, but it was simply a "bad" idea - HMAC-SHA1 already pads 

ok thanks, that makes the implementation much simpler.

with the current MESSAGE-INTEGRITY calculation, it means that the receiver must
modify the incoming data before calculating HMAC-SHA1, in case the FINGERPRINT
attribute is present after M-I. it also means that the STUN receiver must parse
the whole message first, to check if the FINGERPRINT attribute is present, and
the subtract 8 from the STUN Header length field.

rfc3489bis-08 says that before calculating the M-I, a dummy M-I must be inserted
into the message (to get the correct length). would it not be better to include
the FINGERPRINT as a "dummy" attribute also? If that was the case, the length
fields needs not modification at all.

> should perhaps have used 0x41 to make it more obvious :)

okay. btw, could you add that the mapped address is 127.0.0.1:32853 in your
response vector?

/alfred

---

From: Brian Korver <[email-masked]>
Date: Wed, 8 Aug 2007 12:12:20 -0700

These look good.

-briank
[email-masked]

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Fri, 10 Aug 2007 08:54:09 +0300

On Thursday 09 August 2007 20:12:44 you wrote:
> with the current MESSAGE-INTEGRITY calculation, it means that the receiver
> must modify the incoming data before calculating HMAC-SHA1, in case the
> FINGERPRINT attribute is present after M-I. it also means that the STUN
> receiver must parse the whole message first, to check if the FINGERPRINT
> attribute is present, and the subtract 8 from the STUN Header length field.
>
> rfc3489bis-08 says that before calculating the M-I, a dummy M-I must be
> inserted into the message (to get the correct length). would it not be
> better to include the FINGERPRINT as a "dummy" attribute also? If that was
> the case, the length fields needs not modification at all.

Yes. The current -07/-08 text is optimized for sending, while the -06 was 
implicitly optimized for receiving. In practice, -07/-08 makes sending barely 
easier, and receiving much more intricate.

-- 
Rémi Denis-Courmont

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 13 Aug 2007 09:53:51 +0300

> okay. btw, could you add that the mapped address is 127.0.0.1:32853 in your

Hmm, yes... but... whoops, I SHOULD have used example IP addresses range... 
Looks like I'll have to update the vectors yet again :-(

-- 
Rémi Denis-Courmont

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 14 Aug 2007 09:24:03 -0400

An important point of clarification here.

Though FINGERPRINT is currently the only attribute beyond the MI, there 
could potentially be others in the future so you can't depend on it 
being the only one. So inserting a dummy FINGERPRINT won't help.

A different idea which might help is that the hash is computed by 
*starting* with the attributes, going through all of the attributes up 
to but not including M-I, and then including the STUN message header as 
the *last* attribute, with the length instead set as equal to the length 
of the data that the hash is computed over.

This would mean that, you could do the parse and integrity computation 
simultaneously.

-Jonathan R.

Alfred E. Heggestad wrote:
>> Yes. That text has been removed a bunch of revisions ago. You'd have 
>> to ask the editors why, but it was simply a "bad" idea - HMAC-SHA1 
>> already pads internally anyway.
>>
> 
> inserted
>> rfc3489bis-08 says attribute padding can be anything. I am purposedly 
>> using white spaces instead of nuls to root out incorrect C 
>> implementations. I should perhaps have used 0x41 to make it more 
>> obvious :)
>>
> 

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Wed, 15 Aug 2007 09:46:15 +0300

> being the only one. So inserting a dummy FINGERPRINT won't help.

Ok, that's right.

With this in mind, I think the same considerations need to be made for the 
FINGERPRINT attribute: if we ever had something past it, it will need to hash 
the message length the way M-I does.

Otherwise, anything that adds optional attributes after FINGERPRINT will be 
undeployable for not being backward compatible (-> Uho, STUN NAT control...).

Regards,

-- 
Rémi Denis-Courmont

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 16 Aug 2007 12:10:07 -0400

Remi - any comment on the other part of my mail, on the alternative hash 
computation?

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 16 Aug 2007 12:28:43 -0400

Actually, forget it. I withdraw this idea. Its a big change with 
questionable value, late in the game.

-Jonathan R.

Jonathan Rosenberg wrote:
>> With this in mind, I think the same considerations need to be made for 
>> the FINGERPRINT attribute: if we ever had something past it, it will 
>> need to hash the message length the way M-I does.
>>
>> Otherwise, anything that adds optional attributes after FINGERPRINT 
>> will be undeployable for not being backward compatible (-> Uho, STUN 
>> NAT control...).
>>
>> Regards,
>>
>