[MMUSIC] RE: [BEHAVE] Re: STUN/ICE: Username length inconstency

["Dan Wing" <dwing at cisco.com>]

(Sorry for the delay, I just returned from vacation.)

It's useful to have a long username (for things like the now-expired
draft-wing-session-auth-00), but I agree we don't want to exceed the MTU with
the ICE connectivity checks.  ICE should probably mention that somewhere (it
doesn't contain the string "MTU", but I didn't search elsewhere).

-d


> -----Original Message-----
> From: Rémi Denis-Courmont [mailto:remi.denis-courmont at nokia.com] 
> Sent: Monday, August 20, 2007 11:27 PM
> To: ext Jonathan Rosenberg
> Cc: behave at ietf.org; mmusic at ietf.org
> Subject: [BEHAVE] Re: STUN/ICE: Username length inconstency
> 
> On Tuesday 21 August 2007 01:16:39 ext Jonathan Rosenberg wrote:
> > 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.
> 
> 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
> 
> 
> _______________________________________________
> Behave mailing list
> Behave at ietf.org
> https://www1.ietf.org/mailman/listinfo/behave

_______________________________________________
mmusic mailing list
mmusic at ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic