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

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

On 4/29/14, 8:15 PM, Tirumaleswar Reddy (tireddy) wrote:
> 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
>> 

[...]

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

Right.  I did a review (yet to be published) of stun-origin after this one.

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

That looks fine.

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

OK.

Thanks.

-- 
Marc Petit-Huguenin
Developer  |  Jive Communications, Inc.
Jive.com  |  [e-mail]