Subject: [BEHAVE] Comments on draft-ietf-behave-rfc3489bis-05.txt

From: EKR <[email-masked]>
Date: Mon, 04 Dec 2006 20:17:32 -0800

$Id: draft-ietf-behave-rfc3489bis-05-rev.txt,v 1.1 2006/12/05 04:21:16 ekr Exp $

GENERAL COMMENTS
The short-term/long-term username/password thing strikes me as
weird. As I understand it, there are three cases:

1. You have a long-term credential which you use all the time.
2. You have a long-term credential which you bootstrap up to 
   a short-term one.
3. You have no credentials and you get a short-term credential.

It's clear what the first case is for, but I don't think I understand
the second two. It looks to me like in case (2) you're using a
short-term credential as a type of replay detection and in case (3)
you're using it as a way to provide message integrity for an
anonymous client. Am I right about this?

So:
1. Is there any reason why short-term credentials should 
actually be short-term? Why not let them last indefinitely
long, given that we understand techniques for issuing them
statelessly. 

2. If the short-term credential is purely for a-r, why not
just use the nonce?

Having two different "this is STUN" indicators, the cookie and
the fingerprint, plus the cookie, is kind of complicated. Why
not merge them into one long indicator. Is this just historical?

DETAILED COMMENTS
S 5.
   binding.  Rather than use expensive application layer messages, a
   STUN binding request is sent by the client to the server, and is sent

What's expensive about application-layer messages

   These two usages all utilize the same Binding Request message, and
   all require the same basic processing on the server.  They differ
   only in where the server is (a standalone server in the network, or
   embedded in an application layer server), when the Binding Request is
   used and what the client does with the mapped address that is
   returned.

It's worth noting that the keepalive usage overloads the binding
request. As is observed later, the actual address returned
isn't really used (see 12.2.9)

S 6.
   The message type field is decomposed further into the following
   structure:

                          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                          |M|M|M|M|M|C|M|M|M|C|M|M|M|M|
                          |1|1|9|8|7|1|6|5|4|0|3|2|2|0|
                          |1|0| | | | | | | | | | | | |
                          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 3: Format of STUN Message Type Field

   M11 through M0 represent a 12-bit encoding of the method.  C1 through
   C0 represent a 2 bit encoding of the class.  A class of 0 is a
   Request, a class of 1 is an indication, a class of 2 is a success
   response, and a class of 3 is an error response.  This specification
   defines two methods, Binding and Shared Secret.  Their method values
   are enumerated in Section 15.

This bit-splitting (M and C intermixed) is kind of wonky. As I
understand it, it's because the "class" thing was noted after the
fact. Anyway, this weird format needs some explanation. Also,
it looks like the next-to-rightmost bit should be M1, not 
M2.

   The transaction ID is a 96 bit identifier.  STUN transactions are
   identified by their unique 96-bit transaction ID. 

The first sentence is redundant.

Insert two paragraph breaks, one before "Indications are" and one before 
"As with requests"

S 7.1.
   When running STUN over UDP it is possible that the STUN request or
   its response might be dropped by the network.  Reliability of STUN
   request message types is accomplished through client retransmissions.
   Clients SHOULD retransmit the request starting with an interval of
   RTO, doubling after each retransmission.  RTO is an estimate of the
   round-trip-time, and is computed as described in RFC 2988 [8], with
   two exceptions. 

I'd have to study my RFC 2988, but my memory is that RTO isn't
strictly an RTT estimate. Rather, it's based on an RTT estimate
but it's designed to provide neighborly retransmit behavior rather
than be the best estimate.

S 7.2.
   The default port for STUN requests is 3478, for both TCP and UDP.
   There is no default port for STUN over TLS.  Administrators SHOULD
   use this port in their SRV records for UDP and TCP, but MAY use
   others. 

I would swap the 2nd and 3rd sentences.

S 9.1.1.

   If the request is a retransmission of a request for which the server
   has already generated a response within the last 10 seconds, the
   server MUST retransmit the response.  A server can do this either by
   remembering the response it transmitted, or by re-processing the
   request and computing the response.  The latter technique can only be

The latter technique MUST only be...

   Based on the usage, the server determines whether the request
   requires any authentication and message integrity checks.  It can
   require none, short-term credential based authentication, or long-
   term credential authentication.

s/none/no authentication/

S 9.1.2.
   When STUN is being multiplexed on the same transport address as
   application data, and there are valid application layer data packets
   which could be confused with STUN packets (because, for example, bits
   32 through 63 can contain an arbitrary binary value which might be
   equal to 0x2112A442), the FINGERPRINT attribute MUST be present in
   the response.  Otherwise, its inclusion is RECOMMENDED.

So, from the receiver's perspective, does it unambiguously know
when a fingerprint will be present for STUN? Maybe it's worth
walking through the demux logic.

S 11.
   To allow future revisions of this specification to add new attributes
   if needed, the attribute space is divided into optional and mandatory
   ones.  Attributes with values greater than 0x7fff are optional, which
   means that the message can be processed by the client or server even
   though the attribute is not understood.  Attributes with values less
   than or equal to 0x7fff are mandatory to understand, which means that
   the client or server cannot successfully process the message unless
   it understands the attribute.

   The values of the message attributes are enumerated in Section 15.

   The following figure indicates which attributes are present in which
   messages.  An M indicates that inclusion of the attribute in the
   message is mandatory, O means its optional, C means it's conditional
   based on some other aspect of the message, and - means that the
   attribute is not applicable to that message type.

Mandatory seems to be being used in two different ways here:

1. You must be able to parse it to process this message.
2. It must be in the message.

At least in the security area, the term for the first meaning
is "critical".

S 11.3.
Why re-explain the padding convention here?

S 11.4.
It's kind of unusual to use MD5(password) and then feed it into
HMAC-SHA-1. I realize you're doing it to be compatible with old
password files, but how important is that really?

I notice there's no hash agility here. That will probably
give you trouble with the SEC ADs, at least unless you explain
why.

Why are you padding the message out to 64 bytes? SHA has its
own padding.

S 11.8.
Some more clarity about how NONCEs are used would probably be
a good thing. I understand that the idea is you get a 438
and then re-transmit, but that's sort of implict, not stated.

S 11.11.
   of four bytes, it is padded for encoding into the STUN message, in
   which case the attribute length represents the length of the USERNAME

s/USERNAME/SERVER/.

I'd remove this sentence anyway.

S 12.1.8.
   It is RECOMMENDED that servers utilize short term credentials,
   obtained by the client from a Shared Secret request, for
   authentication and message integrity.  Consequently, if a Binding
   Request is generated without a short term credential, the server
   SHOULD challenge for one.

Why is it RECOMMENDED?

S 12.2.8.
   The server SHOULD NOT authenticate the client or look for a MESSAGE-
   INTEGRITY attribute.  Since the keepalives come with some regularity,
   and will come for each client that is connected to the server, the
   processing cost associated with authenticating each request is very
   high. 

It is? On most platforms, the cost of running HMAC of a message
is pretty small. I think some computations would be in order
here.

S 12.3.9.

         password = <hmac(USERNAME,anotherprivatekey)>

HMAC takes the key first....

S 13.3.
"Secondly", "Thirdly", should be "Second", and "Third"

-Ekr

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