Subject: [tram] Review of draft-ietf-tram-auth-problems-00

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 18 Apr 2014 08:57:07 -0600

A1. 1. Title "Problems with STUN Authentication for TURN

I would suggest to change the title to "Problems with STUN long-term
Authentication for TURN", as the STUN short-term authentication is not
discussed in this draft.  TURN only uses long-term authentication, so
"Problems with TURN Authentication" is fine too.

A2. Section 1. Introduction, first paragraph.

I think that this paragraph puts too much emphasis on WebRTC.  WebRTC
is the reason people are finding issues with the authentication, but
it is not the reason for the issues.

A3. Section 2. Notational Conventions

This is an informational draft, so RFC 2119 key words (and the
reference) do not need to be defined.  besides, none of them are used
in the document.

A4. Section 4. Title

Replace with "Problems with usage of long-term STUN Authentication"

A5. Section 4, fourth bullet.

This is an man-in-the-middle attack, so the text should say so.

A6. Section 4, 5th bullet

Note that this applies only to the TCP and UDP transports, as SNI can
be used to select the tenant/realm when TLS or DTLS is used.

A7. Section 4, 6th bullet. "This exposes the user credential to the
Javascript which could be malicious".

It is only a problem if somehow the web server sends a user/password
that can be used to access something else than the TURN server
resources.  It is not a problem created by the long-term
authentication, but by bad code or misconfiguration on the server
side.  If you really insist on saying something about this, it should
about how long-term authentication creates the possibility that a web
server sends credentials that can be reused elsewhere.  I think that
the 3rd bullet as the same issue:  Privacy leakage is not a
consequence of using long-term authentication, but of using usernames
that can be matched with a real person or that can be reused to access
other resources.

A7. Section 8. References

I think that because this is an Informational document, all the
references must be Informative.

Nits
====

- - Section 1. 4th bullet "ICE connectivity checks using
server-reflexive candidate"

The exact terminology in RFC 5245 is "server reflexive".

- - Section 4, second paragraph "...is deployed in DMZ..."

Expand the initialism.

- - Section 4, sixth bullet

s/Javascript needs be know/JavaScript code needs to know/