Re: [tram] Comments on draft-ietf-tram-stun-bis-01

[Marc Petit-Huguenin <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Thank for the comments.  See my answers inline.

On 03/17/2015 08:11 AM, Alan Johnston wrote:
> All,
> 
> Here are some comments on STUNbis.  Minor comments are listed below, but
> the most important one is listed here:
> 
> Does the use of salted SHA256 for passwords match up with what is planned
> for SIP?  See:
> 
>     https://tools.ietf.org/html/draft-yusef-sipcore-digest-scheme
> 
> Does H(A1) match up?  Also, I'm not aware if this draft is moving forward:
> 
>     https://tools.ietf.org/html/draft-veltri-sip-alt-auth

It is not, which is sad because I find it better than draft-yusef-sipcore-digest-scheme.  It also fits better with STUN where the hash algorithm (SHA-1 and now SHA256) has been split off the password hash algorithm (MD5) from the beginning.  draft-yusef-sipcore-digest-scheme does not even talk about the password algorithm, continuing the (I think) rather bad idea of linking the two together.

I put salted SHA256 as an example of the kind of password hash algorithm we could use, but I'll let the WG decide on what they prefer.

> 
> while the other one is under active discussion in SIPCORE and HTTPAUTH -
> see https://tools.ietf.org/html/draft-ietf-httpauth-digest-update
> 
> I think it is important that STUNbis is aligned with the changes to digest
> being worked on in SIP and HTTP.
> 
> - Alan -
> 
> Shouldn't STUNbis reference ICEbis instead of ICE?

It's an informational reference, so I have no problem in referencing ICEbis.  Will fix in -03.

> 
> I presume "obMatJos2" is just a random string used to indicate support for
> STUNbis - it might be worth stating this in 9.2.3.

Generated with apg.  I'll add some text.

> 
> Section 11 Backwards Compatibility with RFC 3489: do we really need to
> still be backwards compatible?  Is anyone still using RFC 3489 that hasn't
> upgraded?  Do we leave ourselves open to any downgrade attacks by doing so?

This has already be changed in -02 to "backwards compatibility with RFC 5389".

> 
> Section 14 says only first of multiple attributes are processed. (“Any
> attribute type MAY appear more than once in a STUN message. Unless
> specified otherwise, the order of appearance is significant: only the first
> occurrence needs to be processed by a receiver, and any duplicates MAY be
> ignored by a receiver.”)  I guess this rules out multiple ORIGIN
> attributes, which is fine since we had chosen that path forward.  However,
> this means that no future STUN attributes can really appear more than
> once.  Do we need to emphasize this more?

I think that the intent was that a future attribute may be defined as supporting to be inserted multiple times, and this rule just makes parsing a STUN packet more resilient (i.e. do not reject a STUN packet because there is more than one instance of a specific attribute).

I would leave the text as it is.

> 
> In Section 14.2 what are the x's in   |x x x x x x x x|?

That's a good question.  I supposed that should all 0's.  Will change it in -03.

> 
> The text in Section 15.3. Hash Agility Plan seems to be out of date now.

Why?

> 
> Section 17.5 says “The UDP port is not currently defined; however, it is
> reserved for future use.”  What port?

The port is in fact allocated now.  I will fix the text in -03.

> 
> The change log says that STUNbis normatively references
> draft-ietf-tram-stun-origin, but I don't see it listed in the references.
> Perhaps a mention of ORIGIN in section 9.2 or 9.2.3 would be good, too.
> 

Section 6.1 of -02.

- -- 
Marc Petit-Huguenin
Email: [e-mail]
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCAAGBQJVCq+JAAoJECnERZXWan7EjecQAL3y56oBKz88Ac34tPyG3VG3
jrsiCkzy5V8uAiK6/4xYM1SFSz7w7P0DkmVL0JexMroOhD44BeDIPmsXZQdbnwpI
Uf7IFwrLUd2fF4OD9hgMEC8sXM50Uvs2JZp6XvJoT9tCbjlB7vQGF3h/l9R+29Rz
y1UibiVHfTLs7X6uyKLHJdWqCItkkDJG5qNlRx6sRfofP9a/AkeRZ1KhXr0EqauG
ZNOQ/U19ufKppp5QXWPS98UrpeIyAXrTY8M1Ar65Sm4Qpqo2BTgMZrN1jwyW1MiE
rHU1gQ1tyQ1dXDsPbPJBINQC7IKq77aKO33qqd9QIYB/Fu7qj3pFuhwcpug7EqGF
q7r4lc8H7jfmbmuFghnmTrfIpza/3uD1TW24gExTonUPzyYTVwYrxgJ7AkzgKcT8
W60kDpaYqKE9GK5To9BRG9iC6S2TzEGp98G5TDcudX4t2Cw0+YjgWr1vNEyOrN0g
eYegQTusc5qqDoXgov2QKLmBM2huaqrOE3RSNtIJEN6fupyM2xSS+4m22F8cBzv4
hW1yZNhPvqGrlXMfxi6U1e3g3umkEw34nggQzBxkhpah3aTeEmlkqJo35RJt9jrf
jFdRYWz4PbWyPnT+7quPMMsaNjVoOmsy8khcaVtsYaWk3rN+YuI8AK/70zJFGoFY
8IVBW1QuZIEVj38XX0Mn
=93pO
-----END PGP SIGNATURE-----