Re: [tram] draft-ietf-tram-stunbis

[Noriyuki Torii <[e-mail]>]

Hi, Marc

Thank you for your consideration and response.

> I gave you an answer to that last time, but you did not responded to it.  Again, here's the email that justify these values:
>
> https://www.ietf.org/mail-archive/web/behave/current/msg02535.html
>
> Please give arguments why that answer is wrong.

Unfortunately I haven't received your previous "answer" email at this point yet.
(maybe delivery problem?)
Therefore I'm sorry to say but the following comment is not taken into account
your "answer".

Anyway, the email you cited says

> UTF-8 encoded sequence of less than 128 characters is up to
> (128-1)*6+1=763 bytes, counting the terminating nul

here +1 is intended as a extra room for the terminating nul.

But such a nul is just a implementation requirement for some programming
languages.
As far as my understandings, both UTF-8 and PRECIS OpaqueString specification
don't require that the nul termination of the string.
(If my understanding is wrong, please can anyone correct abobe)

Each STUN attributes have its own length field therefore the implementation
can detect the end of the string without the terminating nul. So IMHO, such a
consideration on an extra room for the terminating nul is not necessarily
needed as the STUN specification.
This is why the comment I submitted prevously.

---

Additionally, I found one more point in section 9.2.4.

>       *  If the request contains neither PASSWORD-ALGORITHMS nor
>          PASSWORD- ALGORITHM, then the request is processed as though
>          PASSWORD- ALGORITHM were MD5 (Note that if the original
>          PASSWORD-ALGORITHMS attribute did not contain MD5, this will
>          result in a 400 Bad Request in a later step below).
>
>       *  Otherwise, unless (1) PASSWORD-ALGORITHM and PASSWORD-
>          ALGORITHMS are both present, (2) PASSWORD-ALGORITHMS matches
>          the value sent in the response that sent this NONCE, and (3)
>          PASSWORD-ALGORITHM matches one of the entries in PASSWORD-
>          ALGORITHMS, the server MUST generate an error response with an
>          error code of 400 (Bad Request).

The first '*' paragraph says

> (Note that if the original
>          PASSWORD-ALGORITHMS attribute did not contain MD5, this will
>          result in a 400 Bad Request in a later step below).
>

But the second '*' paragraph starts with "Otherwise".

So if really "the request contains neither PASSWORD-ALGORITHMS nor PASSWORD-
ALGORITHM", then the second '*' check will be skipped as a whole and the
400 Bad Request will be never generated, whether or not "the original
PASSWORD-ALGORITHMS attribute did not contain MD5".

I guess it would be preferable something like below.

      *  If the request contains neither PASSWORD-ALGORITHMS nor
         PASSWORD-ALGORITHM, then the request is processed as though
         PASSWORD-ALGORITHMS was identical to the value sent in the
         response that was sent this NONCE and PASSWORD-ALGORITHM was MD5.
         Otherwise, unless PASSWORD-ALGORITHM and PASSWORD-ALGORITHMS are
         both present, the server MUST generate an error response with
         an error code of 400 (Bad Request).
         (Note that if the original PASSWORD-ALGORITHMS attribute did not
         contain MD5, this will result in a 400 Bad Request in a later
         step below).

      *  Unless (1) PASSWORD-ALGORITHMS matches the value sent in the
         response that sent this NONCE, and (2)PASSWORD-ALGORITHM matches
         one of the entries in PASSWORD-ALGORITHMS, the server MUST
         generate an error response with an error code of 400 (Bad Request).

Best regards,
Noriyuki Torii

2018-03-11 22:26 GMT+09:00 Marc Petit-Huguenin <[e-mail]>:
> Hi,
>
> Thanks for the review, please see inline.
>
> Note that the draft submission tool will reopen on 2018-03-18, so no new version of this draft will be published before that.
>
> On 03/07/2018 04:10 AM, Noriyuki Torii wrote:
>> To whom it may concern.
>>
>> I'm Noriyuki Torii. I have red the updated I-D of STUNbis-16 and found
>> some issues would like to be shared.
>>
>> Hope this may help for improvement.
>>
>> - Section 9.1.1 and 9.2.2 defines the HMAC key calculation based on some
>>   elements such that the password, username and realm.
>>   Sections say those elements should be proccessed using OpaqueString
>> profile
>>   defined in RFC8265.
>>
>>   On the other hand, RFC8265 says in its "Changes from RFC 7613" that
>>      "Removed UTF-8 as a mandatory encoding, because that is a matter
>>       for the application."
>>
>>   So, the specification of applied encoding for those elements on
>> calculating
>>   HMAC key is up to STUNbis document.
>>
>>   Please note that username and realm have the applied encoding
>> specification
>>   as UTF-8 in its corresponding STUN attribute description.
>>   (please see section 14.3 and 14.9)
>>   But the password doesn't have such a description, therefore some care need
>>   to be taken.
>
> Section 9.1.1 and 9.2.2 now have the following text:
>
>    For short-term credentials the HMAC key is defined as follow:
>
>                        key = OpaqueString(password)
>
>    where the OpaqueString profile is defined in [RFC8265].  The encoding
>    used is UTF-8 [RFC3629].
>
> [...]
>
>    For long-term credentials that do not use a different algorithm, as
>    specified by the PASSWORD-ALGORITHM attribute, the key is 16 bytes:
>
>   key = MD5(username ":" OpaqueString(realm) ":" OpaqueString(password))
>
>    Where MD5 is defined in [RFC1321] and the OpaqueString profile is
>    defined in [RFC8265].  The encoding used is UTF-8 [RFC3629].
>
>>
>> - Section 14.6 mentions to the HMAC truncation, but as far as I read, I
>>   couldn't precisely find out the minimum byte of length of the HMAC.
>>
>>   From my understandings, minimum length
>>   maybe 16 because
>>   > The HMAC MUST NOT be truncated below a minimum size of 16 bytes.
>>
>>   OR
>>   maybe 8 because
>>   > The value (snip) MUST be a positive multiple of 4 bytes
>>     AND
>>   > STUN Usages may specify a minimum length longer than 4 bytes.
>>
>>   Here above I conceived "longer than (but not equal to) 4 bytes".
>>   IMHO, some clarification will be preferable.
>
> I removed the last sentence of the paragraph, which did not make sense.
>
>>
>> - There are some occurence such like
>>    > a UTF-8 [RFC3629] encoded
>>    > sequence of less than 128 characters (which can be as long as 509
>>    > bytes when encoding them or 763 bytes when decoding them).
>>
>>    The sentence inside parenthesis have off-by-one error.
>>    To be exact,
>>
>>    (which can be less than 509 bytes when encoding them or 763 bytes
>>    when decoding them)
>>
>>    or alternatively
>>
>>    (which can be as long as 508 bytes when encoding them or 762 bytes
>>    when decoding them)
>
> I gave you an answer to that last time, but you did not responded to it.  Again, here's the email that justify these values:
>
> https://www.ietf.org/mail-archive/web/behave/current/msg02535.html
>
> Please give arguments why that answer is wrong.
>
>>
>> - In Section 9.2.4, there are some typoes.
>>   Unnecessary extra white space such that "PASSWORD- ALGORITHM".
>
> Fixed.
>
>>
>> - At page 40, bizzare (perhaps unintended) page break occurs.
>
> Fixed.
>
> --
> Marc Petit-Huguenin
> Email: [e-mail]
> Blog: https://marc.petit-huguenin.org
> Profile: https://www.linkedin.com/in/petithug
>