Subject: [BEHAVE] message-integrity and the length field

From: Evgeniy Khramtsov <[email-masked]>
Date: Sun, 25 Mar 2007 01:39:42 +0900

It is not clear enough how to compute the MESSAGE-INTEGRITY attribute: 
should the length field of the STUN message be calculated before adding 
the MESSAGE-INTEGRITY attribute or should it be initialy calculated 
discluding the size of the MESSAGE-INTEGRITY attribute and update it 
after the MESSAGE-INTEGRITY is calculated?

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 26 Mar 2007 22:16:48 -0400

The M-I is of fixed length (20 bytes), so either way works.

-Jonathan R.

-- 
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: Philip Matthews <[email-masked]>
Date: Wed, 28 Mar 2007 12:37:58 -0400

Is this really true??   My answer would have been that neither way  
works.

As I understand it, the question is: What should be the value of the  
length field in the STUN header when the message integrity  
calculation is done?

Evgeniy's first option is to set it to the length of the STUN message  
minus 20 (= the size of the STUN header) minus the size of the  
Message-Integrity attribute itself.

Evgeniy's second option seems to be similar, but I don't really  
understand what he suggest here.

However, I think the correct answer is to set it to the actual length  
of the STUN message minus 20.  This can be done because the size of  
the MESSAGE-INTEGRITY and FINGERPRINT attributes can be known in  
advance, even if their values are not known..

- Philip

On 26-Mar-07, at 22:16 , Jonathan Rosenberg wrote:

>> It is not clear enough how to compute the MESSAGE-INTEGRITY  
>> attribute: should the length field of the STUN message be  
>> calculated before adding the MESSAGE-INTEGRITY attribute or should  
>> it be initialy calculated discluding the size of the MESSAGE- 
>> INTEGRITY attribute and update it after the MESSAGE-INTEGRITY is  
>> calculated?

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Wed, 28 Mar 2007 13:09:20 -0400

Agree that the draft isn't clear, but this is what I think it should
say, as well.

Bruce

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 28 Mar 2007 17:03:37 -0400

Philip Matthews wrote:

> Is this really true??   My answer would have been that neither way  works.

Why? Though the CONTENT of the message-integrity is not known, its 
length is. So you basically add M-I to the message with all-zero content 
(so now the length is correct), compute the check, and fill in the 
result into the attribute. What am I missing?

-Jonathan R.

---

From: Philip Matthews <[email-masked]>
Date: Wed, 28 Mar 2007 18:10:06 -0400

Jonathan:

I agree with what you said below. However, from my reading of Evgeniy  
Khramtsov's message, this is not what he though should happen.

Let me give an example. Say the STUN message has 4 attributes.
Three of the attributes have a combined length of 40 bytes, and the
last attribute is the MESSAGE-INTEGRITY attribute with a length of 20  
bytes.

Evgeniy Khramtsov's option 1:
Set the length field in the STUN header to 40,  compute the check,  
then append the M-I attribute (but do not update the length field)  
and send the message.

Evgeniy Khramtsov's option 2:
Set the length field in the STUN header to 40,  compute the check,  
then append the M-I attribute, add 20 to the length field in the  
header, and send the message.

What I think is the correct answer:
Set the length field in the STUN header to 60, compute the check,  
then append the M-I attribute (leaving the value of the length field  
at 60) and send the message.

Does this make things clear?

- Philip

On 28-Mar-07, at 17:03 , Jonathan Rosenberg wrote:

> length is. So you basically add M-I to the message with all-zero  
> content (so now the length is correct), compute the check, and fill  
> in the result into the attribute. What am I missing?
>
> -Jonathan R.
> --

---

From: Christian Huitema <[email-masked]>
Date: Wed, 28 Mar 2007 18:08:34 -0700

> at 60) and send the message.

The standard practice, in many other protocols, is to encode the
complete message with a dummy attribute value (in this case 20 null
bytes), compute the checksum, replace the dummy value by the check
result, and send the message. The advantage of that method is to not
make any assumption about the position of the checksum attribute in the
message.

For example, RFC 793 includes this text for the computation of the TCP
checksum:

  Checksum:  16 bits

    The checksum field is the 16 bit one's complement of the one's
    complement sum of all 16 bit words in the header and text.  If a
    segment contains an odd number of header and text octets to be
    checksummed, the last octet is padded on the right with zeros to
    form a 16 bit word for checksum purposes.  The pad is not
    transmitted as part of the segment.  While computing the checksum,
    the checksum field itself is replaced with zeros.

-- Christian Huitema

---

From: <[email-masked]>
Date: Thu, 29 Mar 2007 17:52:15 +0300

Hello,

On 29 March 2007,  Philip Matthews wrote:
>Set the length field in the STUN header to 60, compute the 
>check, then append the M-I attribute (leaving the value of the 
>length field at 60) and send the message.

yes, I've talked with a number of implementors about this (who all have
asked the same question btw ;)) and the above option is 
the one that seems like the right interpretation (considering what the 
code looks like on the receiving side), it's how most (?) current 
implementations do it, and was ack'ed at least once on this list (in 
January this year, subject "STUN FINGERPRINT").

-- 
[email-masked] (Kai Vehmanen)

---

From: Benny Prijono <[email-masked]>
Date: Thu, 29 Mar 2007 19:12:35 +0100

> January this year, subject "STUN FINGERPRINT").

Agreed (except that the message length should be 64, since M-I is 24 
bytes long ;-) ).

  -benny

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Thu, 29 Mar 2007 20:58:13 -0400

The TCP checksum is a special case because if you calculate it with
the field set to zero, then add it to the message and send it, the
calculation on the receiving side must produce zero.  CRC is similar
(it's a remainder).   That doesn't help with filling in a length
field.    I think it's only a question of whether it should include
the checksum or not (my vote is it does).

Bruce

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 30 Mar 2007 09:04:57 -0400

I concur that this is the correct algorithm. Sounds like we are all 
agreed. I will clarify this in the next stun revision.

-Jonathan R.

Benny Prijono wrote:

>> asked the same question btw ;)) and the above option is the one that 
>> seems like the right interpretation (considering what the code looks 
>> like on the receiving side), it's how most (?) current implementations 
>> do it, and was ack'ed at least once on this list (in January this 
>> year, subject "STUN FINGERPRINT").
> 
>

---

From: Jonathan Lennox <[email-masked]>
Date: Fri, 30 Mar 2007 10:40:36 -0400

Would it be correct to extend this as follows?

If a message has both the MESSAGE-INTEGRITY and FINGERPRINT attributes, the
value of the length field for the input to MESSAGE-INTEGRITY includes the
length of both attributes, i.e. 32 bytes more than the length of the STUN
message before MESSAGE-INTEGRITY is appended.

(Thus, you have to decide whether to include FINGERPRINT before computing
MESSAGE-INTEGRITY.)

Similarly, the length field over which FINGERPRINT is computed includes its
own contents, i.e. 8 bytes more than the message length before FINGERPRINT
is appended.

-- 
Jonathan Lennox
[email-masked]

---

From: Benny Prijono <[email-masked]>
Date: Fri, 30 Mar 2007 18:00:22 +0100

> message before MESSAGE-INTEGRITY is appended.

To be precise, the last sentence should be:

  .. before M-I *and* FINGERPRINT is appended.

Other than that, I agree.

> (Thus, you have to decide whether to include FINGERPRINT before computing

Yes.

> own contents, i.e. 8 bytes more than the message length before FINGERPRINT

I also agree with this too.

  -benny