Re: [tram] Stephen Farrell's Discuss on draft-ietf-tram-turn-third-party-authz-13: (with DISCUSS and COMMENT)

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

> -----Original Message-----
> From: Stephen Farrell [mailto:[e-mail]]
> Sent: Saturday, April 11, 2015 1:08 AM
> To: The IESG
> Cc: [e-mail]; [e-mail]; draft-ietf-tram-turn-third-party-
> [e-mail]; [e-mail]; draft-ietf-tram-turn-third-
> [e-mail]; draft-ietf-tram-turn-third-party-
> [e-mail]
> Subject: Stephen Farrell's Discuss on draft-ietf-tram-turn-third-party-authz-
> 13: (with DISCUSS and COMMENT)
> 
> Stephen Farrell has entered the following ballot position for
> draft-ietf-tram-turn-third-party-authz-13: Discuss
> 
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
> 
> 
> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> http://datatracker.ietf.org/doc/draft-ietf-tram-turn-third-party-authz/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> 
> Edited discuss ballot after chats around Dallas.
> 
> (1) Please fix the crypto as per Richard's discuss. (I think the plan here is for
> Rich Salz to help with that, which I'm confident will work out ok.)

Yes, comments from Richard are addressed.

> 
> (2) Please consider whether a signature based scheme that does not require
> pre-shared keys between the TURN and (in particular) WebRTC server could
> be useful to support. (Either in this document or
> elsewhere.) There should be use cases where that offers sufficient
> accountability for use of TURN and it ought allow some deployments that
> are less easy with this kind of pre-shared keys approach. The DISCUSS here is
> to check if the WG want to take that approach, either now or later.

Passive attacks could occur in TURN due to lack of integrity protection. For example, a passive attacker could monitor Allocate request/response between the client and TURN server and make a Refresh request with a requested lifetime of 0 to delete the allocation. Message integrity of TURN messages ensures that passive attacker cannot spoof subsequent TURN messages.

> 
> (3) I think the plan is to take out some of the options that are not needed so
> as make interop more likely.
> Please do so. (I think we discussed taking out the DKSPP stuff at least, but
> the more options we can get rid of, the better).

Yes, DKSPP is removed from the draft.

> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> 
> - COMMENTS below are unchanged since before Dallas.
> We can look over then as we go.
> 
> - I really think this would benefit from some wider review and I don't think
> it's ready as-is.

This draft is also reviewed in OAuth WG.

> 
> - I agree with Richard's discuss points.
> 
> - intro: "impossible in web applications" isn't really true in principle, but
> impossible in WebRTC as it uses JS is true.

NEW:
   However, in web applications
   like WebRTC [I-D.ietf-rtcweb-overview] where JavaScript uses the
   browser functionality to make real-time audio and/or video calls, Web
   conferencing, and direct data transfer, ensuring this secrecy is
   typically not possible.

> 
> - Assuming the AS that can authorize the user shares a secret with the STUN
> server chosen by the WebRTC server seems very brittle. Why would that be
> true in general?

The AS and WebRTC server are in the same administrative domain of the application provider. The user never sends the session key learned  from the AS to the STUN server it only uses the session key to compute  message integrity of STUN request and to validate the  message integrity of  the STUN response. The STUN server will only know the session key if it can decrypt the token.

> 
> - 4.1.1: Hmmm. How many people use KeyProv I wonder?

Already removed DKSPP.
 
> 
> - 4.1.2 - which "two servers"? WebRTC can have more servers than that.

The STUN server and the AS. As far as the STUN server is concerned, it only deals with the AS of interest for key establishment. The AS could be the application server itself or could be a Key management  function syncing the keying material to the WebRTC servers.

NEW:
   The STUN and AS servers could choose to use REST API over HTTPS to
   establish a symmetric key.

> 
> - 4.1.2 - now we're using TLS mutual auth? And how does the TLS client know
> which CA to use that'll work with the TLS server here? I don't think that'll
> scale will it?

We presume the two parties involved know what CA to consider when using the REST APIs ­ they would have to do this to trust each other. Please note that the AS is allocating symmetric keys meant exclusively for  that STUN Server, so some level of co-ordination is already involved.

> 
> - 4.1.3 - this looks like what the WG/authors really want, would that be a fair
> statement?

As per our discussion we have changed the specification to recommend REST 

NEW:

   Note : The mechanism specified in Section 4.1.2 compared to REST
   lacks encryption and HMAC algorithm agility.  Hence a STUN server and
   authorization server implementation SHOULD support REST explained in
   Section 4.1.1.


> 
> - 9: Figure 2 should be way up at the top of the document and not here

In the previous versions it was in the top of the document but moved down after comments received from the WG that WebRTC is only an  example usage of third party authorization.

> 
> - 9: Why 5 seconds ?

STUN messages can be sent over UDP, 5 seconds is to accommodate packet loss and RTO interval.

-Tiru

>