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

["Tirumaleswar Reddy (tireddy)" <[e-mail]>]

Hi Marc,

Thanks for the review. Please see inline

> -----Original Message-----
> From: tram [mailto:[e-mail]] On Behalf Of Marc Petit-Huguenin
> Sent: Friday, April 18, 2014 8:27 PM
> To: [e-mail]
> Subject: [tram] Review of draft-ietf-tram-auth-problems-00
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 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.

Changed the title to "Problems with STUN long-term Authentication for TURN".  (The 00 version of the draft had the title "Problems with TURN Authentication" (https://tools.ietf.org/html/draft-reddy-behave-turn-auth-00) but based on the comments received in BEHAVE WG that TURN is only using the long-term authentication mechanism provided by STUN, the title of the draft was changed in 01 version.)

> 
> 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.

Yes, updated the draft.

> 
> 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.

Ok, removed.

> 
> A4. Section 4. Title
> 
> Replace with "Problems with usage of long-term STUN Authentication"

Ok.

> 
> A5. Section 4, fourth bullet.
> 
> This is an man-in-the-middle attack, so the text should say so.

Updated.

> 
> 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.

The need for ORIGIN attribute even if D{TLS} is used is discussed in http://tools.ietf.org/html/draft-johnston-tram-stun-origin-02

> 
> 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.  

The problem is that long-term credentials (username/password) must be exposed to the java script code which could be malicious. For example refer to the sample java script code in slide 2 of http://www.ietf.org/proceedings/87/slides/slides-87-behave-10.pdf where RTCPeerConnection API needs the client username/password.  The credentials could be leaked by a malicious java script, thus resulting in TURN server access to be misused. 

> 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.

Agreed.

NEW:

   3.  The long-term credential mechanism in [RFC5389] requires that the
       TURN client must include username value in the USERNAME STUN
       attribute.  An adversary snooping the TURN messages between the
       TURN client and server can identify the users involved in the
       call resulting in privacy leakage.  If TURN usernames are linked
       to real usernames then it will result in privacy leakage, but in
       certain scenarios TURN usernames need not be linked to any real
       usernames given to users as they are just provisioned on a per
       company basis.

....
....


   7.  In WebRTC the Javascript code needs to know the username and
       password to use in W3C RTCPeerConnection API to access the TURN
       server.  This exposes the user credentials to the Javascript
       which could be malicious.  The malicious java script could misuse
       or leak the credentials.  If the credentials happen to be used
       for accessing services other than TURN then the security
       implications are much larger.
> 
> A7. Section 8. References
> 
> I think that because this is an Informational document, all the
> references must be Informative.

I think informational document can have normative references. For example check RFC7152, RFC 6819.

> 
> 
> Nits
> ====
> 
> - - Section 1. 4th bullet "ICE connectivity checks using
> server-reflexive candidate"
> 
> The exact terminology in RFC 5245 is "server reflexive".

Updated.

> 
> - - Section 4, second paragraph "...is deployed in DMZ..."
> 
> Expand the initialism.

Ok.

> 
> - - Section 4, sixth bullet
> 
> s/Javascript needs be know/JavaScript code needs to know/

Fixed.

Thanks and Regards,
-Tiru

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> 
> iQEcBAEBAgAGBQJTUT1DAAoJEMUNRP98lsiX2j8IAI887pQ2p5EpzjjjHXHykUe1
> mDfUX1wjs5YO7067sWV0s7gHev5G9h6NIo4fjQ8JNNmng3WkBn6hPT1k3HXz4KE
> d
> CpHFiihPMvjstjUv6AUtAF4igiRO2V4rkCbiHzxXt268+QTnW3Whzsjlq01pD6Pj
> RZcCBE/ASHy+8wUdV+CpF6ZHFU6+165pajiaEusMfrCLAqlin/Rj3aRBBe+s7/s7
> yrHTlsQzEYPKdAvi6qD0MlZ6+/jtari0VJhQA5/fvHsa+3GA6/z9h5nACfXI+yh2
> j9So3/qD90njHQFtxQXvspKasYagZjwO93RxLzIYKVy2BDMHlmsGL7wJ62Vo55o=
> =YfrU
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> tram mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tram