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

[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