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

[Jonathan Rosenberg <jdrosen at cisco.com>]

To be specific, let me propose the following:

rfc3489bis: says the username MUST be less than 513 bytes. It also says 
that the STUN message when sent over UDP MUST be less than the MTU.

ICE: says that the username fragment MUST be less than 256 bytes.


The desire for the ability to have larger usernames is not security 
(i.e., this doesn't mean endpoints compute username fragments with 256 
bytes of entropy), but that cases have been identified ala Dan's draft 
of stuffing useful identifiers in there. So we want to allow that to be 
possible in the future. Length limits always need to be carefully 
managed, since they are nice in terms of implementation but you can 
sometimes regret them in a really big way down the road (think SMS 
message sizes, 640k memory limit, etc.)

-Jonathan R.




Dan Wing wrote:
> (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

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

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