Subject: [MMUSIC] STUN/ICE: Username length inconstency

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 20 Aug 2007 14:37:55 +0300

Hello,

It seems there is a minor error in the maximum username length between ICE-17 
and RFC3489bis-09.

STUN says USERNAME are at most 127 Unicode code points. There is no way a ICE 
user fragment of 1024 bytes could fit in there. I would assume the ICE ufrag 
should be limited to (127-1)/2 = 63 characters, so that the resulting STUN 
username is always within the 127 code points limits, including one code 
point for the semi-colon.

In any case, an ICE implemention that fails to obey this limit would fail to 
interoperate with another instance of itself, which is pretty lame :)
Also, it ensures the ICE connectivity check packets size remain within the 
minimum IPv4 MTU.

I hope, that I either misunderstood something, or that this is a minor enough 
change that it can still be done this late in the process.

-- 
Rémi Denis-Courmont

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 20 Aug 2007 18:16:39 -0400

This is a good catch. I recently introduced the limit in STUN based on 
last call comments, forgetting that we had ICE use cases that could 
result in values longer than 127. I had picked 127 thinking about human 
readable usernames. My bad. I think the limit in STUN should be 
increased to match ICE, not the other way around.

-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: Rémi Denis-Courmont <[email-masked]>
Date: Tue, 21 Aug 2007 09:26:44 +0300

> increased to match ICE, not the other way around.

Hmm, I am not sure 1023 character long username are that great really. For a 
start, after concatenation (2047 characters), you'll get connectivity checks 
that exceed the typical Internet MTU. That brings either problem:
- NATs will not handle fragmented packets, or
- ICE implementation will refuse to send at all (packet too big).

Second, I wonder if if makes sense to have a higher entropy for the username 
(12,000 bits here!) than we have for the message integrity (160 bits 
currently) or the shared secret password. But that's something for security 
gurus to judge. Even if we switched to SHA512, we'd still have more than 
enough username entropy with just 63 characters from each sides (756 bits).

Third, we do not want to drain the entropy pool of ICE-capable device too 
badly. There are better stuff to dedicate entropy to that ICE connectivity 
checks, such as generating TLS parameters.

-- 
Rémi Denis-Courmont