Subject: [BEHAVE] draft-ietf-behave-rfc3489bis-05 comments

From: <[email-masked]>
Date: Fri, 5 Jan 2007 13:17:46 +0200

Hi,

A bit late for the rfc3489bis-05 WGLC, but better late than never.
This is a great spec, but there's still some issues to discuss.
I tried not to repeat the already commented issues.

Here's the comments:

-6. (page 13): Requirement about selecting a new TID value is a bit
iffy.
 It requires that the transaction ID's should be uniformly and randomly
 selected on the 0 to 2**96 - 1 scale, but then again, a client should
not
 repeat previous TID's.
 These two requirements are conflicting with each other. A client really
 can not remember all of its used old TID's forever. Neither can it use
an
 incrementing counter as a part of the TID to achieve the non-repeating
 characteristic due to the random selection requirement. AFAIK for basic
 STUN the requirement of uniform & random value selection is enough. If
we
 really do need the "not repeating" part for something specific, it
should
 be clearly stated here.

-7.1 (page 14): The retry timeout value calculation with this new style
 might be a bit of an overkill. Is it really reasonable to specify such
 an adaptive algorithm just for retransmissions? Would't it just be
enough
 that the implementations would be allowed to configure and/or the retry
 starting time value, and then double it (and so on like in previous
 rfc3489(-bis) versions)?
 I do understand that this mechanism is just a SHOULD level requirement,
 but still, do we have a need to make it so "dynamic and wise"?

-8.1 (page 16): Service discovery (DNS SRV & port) specifications in
 rfc3489bis-05 are not backwards compatible with RFC3489 (as I stated
earlier).
 Rohan Mahy had a nice solution to this (I'll second this):
 "I think we want to switch to _tls-tcp going forward and allow
 _tls for backwards compatibility."

-8.1 (page 16): There is (still) no default port for the STUN over
 TLS (shared secret usage). I'd really like this specification to
include
 one. I havent heard of any (good) reasons why not to do so.
 Here's a few reasons why to specify this default port definition also
 for STUN over (TCP) TLS:
 a) This enables (minimal) implementations not to include the DNS SRV
query
 part in the implementation. Also, disabling the DNS SRV query part with
 settings (like by having just a direct STUN server address in settings)
 would be enabled.
 b) The TLS STUN services (if implemented) will be in some port anyway.
 Why not specify a default port so that the service providers could use
 a specific port by default, and not scatter the port selections to
 random ports?
 c) I'm not much of a security specialist, but would't this
specification ...
 "For usages that
  require TLS, such as the short term password usage, lack of SRV
  records is equivalent to a failure of the transaction, since the
  request or indication MUST NOT be sent unless SRV records provided a
  transport address specifically for TLS."
 ... enable a potential down-negotiation weakness if the attacker can
somehow
 block the DNS SRV queries the client makes? By this I mean of course
possible
 fall-back to not using short term passwords, and continuing by assuming
 that the server supports STUN binding query without any shared secrets.

-8.3.2 (page 19): Acceptance of response messages that unexpectedly
include a
 MESSAGE-INTEGRITY attribute. How can a server include a
MESSAGE-INTEGRITY
 attribute in a response if the client did not use one in the request?
 What's the point of accepting such response?

-11.2 & 11.3 (pages 30 & 31): The attributes USERNAME & PASSWORD are not
 backwards compatible with RFC3489 due to the changed length and padding
 requirements. The new way is IMHO better, but shouldn't this be
mentioned
 somewhere in the spec?

-11.6: The error code 300 and usage of an alternate server attribute
 ALTERNATE-SERVER. There are already ways to select alternate servers
 (e.g. trying the next DNS SRV result).
 As stated earlier, this also causes a security threat.
 Also, since this is not much usable for plain STUN use cases, I'd not
 include this at least in this STUN RFC.

-General mumble: TLS implementation: this short term secret usage
requiring
 TLS implementation has obviously been seen as a cumbersome feature, and
thus
 it is AFAIK not (at least yet) generally adopted in STUN
implementations.
 Should we still reconcider options which would be lighter to implement,
 and thus would be easier to get widely adopted?
 The long term credentials is one option, but it has it's own
weaknesses,
 like the two-part message sequence due to the challenges.
 I'm just concerned about the risk that this feature won't be
implemented
 later on either due to the too high benefit/cost ratio.
 I do however like the general idea of having a secure way to do STUN
 without much of settings in either the client nor the server.

--
Tomi Kohonen
Nokia Corporation

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