TURN/STUN Interoperability Issues

In trying to implement TURN and STUN, our engineers have
discovered a
couple of places in the current set of drafts that could be
clearer.
Below, I describe the ambiguities and propose clarifying
text.

1. USERNAME AND PASSWORD LENGTHS
--------------------------------

RFC 3489 rather clearly constrained usernames and passwords
to be
multiples of 4 [sections 11.2.6 and 11.2.7]. This was a
perfectly
sensible constraint when they were temporary. 3489bis has
removed the
sentences that specifically constrain usernames and
passwords; however,
section 11 clearly states that the length of
"attributes values MUST be
0 or a multiple of 4 bytes."

We assume that the removal of the constraint on username and
password
lengths is to accommodate the fact that long-term,
user-selected
usernames and passwords can't be reasonably constrained to
multiples of
4 bytes. However, this removal creates an ambiguity in the
specification. There is similar ambiguity around REALM.

Specifically: If I want to encode a 5-byte username (e.g.
"test1"), what
is this supposed to look like? With the current
specification, there are
at least four incompatible encodings that reasonable
designers could
implement after reading the specification:

  1. 00 06 00 08 74 65 73 74 31 00 00 00
  2. 00 06 00 08 74 65 73 74 31 20 20 20
  3. 00 06 00 05 74 65 73 74 31
  4. 00 06 00 05 74 65 73 74 31 00 00 00

Number 1 is based on null-padding of the name to fit into a
multiple of
4. This kind of makes sense because C strings are null
terminated, and
null padding just kind of "feels right."

Number 2 is based on the fact that reason phrases are padded
with spaces
to be a multiple of 4. This is the only mechanism described
in the
document that talks about *how* to pad fields to be a
multiple of 4. It
is almost certainly not what we intend.

Number 3 kind of misses the point that attributes need to be
a multiple
of 4; however, it is the encoding that TWO DIFFERENT,
INDEPENDENT
implementation teams at two different companies implemented,
based on
the current document.

Number 4 takes the BFCP approach of encoding the actual
attribute
length, but padding out to an even multiple of 4 bytes.

I think all of these can work, but we need to pick one and
make sure the
encoding is described in a clear way that cannot be
misconstrued. My
personal vote is for method 1. An example would be useful
here.

I would propose adding text to section 11, at the end of the
paragraph
starting "In order to align attributes on word
boundaries...", to the
effect of:

    In order to align attributes on word boundaries, the
length of the
    all message attributes values MUST be 0 or a multiple of
4 bytes.
    Extensions to this specification MUST also follow this
requirement.
    Variable-length fields, such as USERNAME and PASSWORD,
MUST be
    padded with ASCII NUL (0x00) characters so as to be a
multiple of
    four bytes in length. For example, a USERNAME of
"test1" would be
    encoded as 00 06 00 08 74 65 73 74 31 00 00 00.

I would also put reminder text in the USERNAME, PASSWORD,
and REALM
entries along the lines of:

    The value of USERNAME is a variable length opaque value.
Like all
    variable-length fields, USERNAME must be padded with
ASCII NUL
    (0x00) characters so as to be a multiple of four bytes
in length.

2. FORMAL DEFINITION OF HMAC KEY CALCULATION
--------------------------------------------

Section 8.1.2 of the stun draft starts talking about HMAC
key
calculation without first defining the syntax being used to
define
things. While implementors familiar with RFC 2617 will
probably
recognize the operations and tend to do something sensible,
others are
likely to be confused.

In particular, the operation unq() isn't defined in the
STUN draft, and
there's no explicit statement that implementors should look
to RFC 2617
for its definition. Similarly, the use of quotes around the
colons and
the implied string concatenation isn't particularly well
defined in STUN.

Finally -- and this is causing *severe* headaches in our
attempts to
interop with other implementations -- it is unclear whether
the result
of hashing this string (to be fed into the HMAC as a key) is
the raw
16-byte result of the MD5 hash, or whether it is the 32-byte
text hex
representation of this hash. The former is a somewhat more
obvious
implementation choice for people unfamiliar with RFC 2617,
while the
latter is more consistent with RFC 2617 encoding (from which
the TURN
draft obviously borrows the mechanism).

I would propose removing the final sentence of the first
item #3 in
section 8.1.2, and replacing it with:

    The 16-byte key for the MESSAGE-INTEGRITY HMAC is formed
by taking
    the MD5 hash of the result of concatenating the
following five fields:

        - The username, with any trailing nulls removed
        - A single colon
        - The realm, with any quotes and trailing nulls
removed
        - A single colon
        - The password, with any trailing nulls removed

    For example, if the USERNAME field were 'user', the
REALM field were
    '"realm"', and the PASSWORD field were
'pass', then the 16-byte HMAC
    key would be the result of performing an MD5 hash on the
string
    'user:realm:pass', or
0x8493fbc53ba582fb4c044c456bdc40eb.

I would also strike the text in section 9.1.1 that
re-specifies how to
perform the hash, and instead refer to the earlier
description:

    If the USERNAME attribute was present, the server
computes the HMAC
    over the request as described in Section 11.8. The HMAC
key is
    computed as described in section 8.1.2. If the server
does not have
    a record for that username within that realm, the server
generates
    an error response.  That error response MUST include an
ERROR-CODE
    attribute with a response code of 436.  That error
response MUST
    include a NONCE attribute and a REALM attribute.

/a
_______________________________________________
Ietf-behave mailing list
Ietf-behavelist.sipfoundry.org
https://list.sipfoundry.org/mailman/listinfo/ietf-behave

TURN/STUN Interoperability Issues

Thread: TURN/STUN Interoperability Issues