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

[Alan Johnston <[e-mail]>]

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

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?

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

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?

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?

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

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

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

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.