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

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 15 Apr 2015 16:06:24 +0000

> -----Original Message-----
> From: Brandon Williams [mailto:[email-masked]]
> Sent: Tuesday, April 14, 2015 6:36 PM
> To: Tirumaleswar Reddy (tireddy); Stephen Farrell; The IESG
> Cc: [email-masked]; [email-masked]; draft-ietf-tram-turn-third-party-
> [email-masked]; [email-masked]; draft-ietf-tram-turn-third-
> [email-masked]; draft-ietf-tram-turn-third-party-
> [email-masked]
> Subject: Re: [tram] Stephen Farrell's Discuss on draft-ietf-tram-turn-third-
> party-authz-13: (with DISCUSS and COMMENT)
> 
> On 04/10/2015 11:07 PM, Tirumaleswar Reddy (tireddy) wrote:
> >> -----Original Message-----
> >> From: Stephen Farrell [mailto:[email-masked]]
> >> Sent: Saturday, April 11, 2015 1:08 AM
> >> To: The IESG
> >> Cc: [email-masked]; [email-masked];
> >> draft-ietf-tram-turn-third-party- [email-masked];
> >> [email-masked]; draft-ietf-tram-turn-third-
> >> [email-masked]; draft-ietf-tram-turn-third-party-
> >> [email-masked]
> >> Subject: Stephen Farrell's Discuss on
> >> draft-ietf-tram-turn-third-party-authz-
> >> 13: (with DISCUSS and COMMENT)
> >>
> >>
> >> (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.
> >
> 
> I think Stephen was thinking primarily about cases with (D)TLS involved
> between the UA and the STUN server. If there's already a security layer then
> perhaps it's enough to prove that the auth server approved the
> communication and it's OK to skip STUN integrity protection altogether.
> My experience suggests that even in a case where (D)TLS isn't involved some
> application providers will not consider the risk of skipping STUN HMACs big
> enough to justify doing it.

Got it, thanks.

> 
> 
> >> - 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.
> 
> A few people from outside the WG have commented on having trouble
> following the flow of the document on their first read, primarily due to the
> lack of a high-level picture early in the document. Moving section 9 back up
> toward the top of the document would help by giving readers such a high-
> level overview early on. The discussion might need to be generalized a bit in
> order to serve this purpose, but comments we've received on the
> document's usability indicate that this change would be helpful.

Section 9 is specific to TURN and the ask from the WG is to discuss it in a separate section after third party authorization with STUN protocol is explained.

-Tiru

> 
> --Brandon
> 
> --
> Brandon Williams; Senior Principal Software Engineer Emerging Products
> Engineering; Akamai Technologies Inc.

---

From: Brandon Williams <[email-masked]>
Date: Tue, 21 Apr 2015 14:39:28 -0400

> Section 9 is specific to TURN and the ask from the WG is to discuss it in a separate section after third party authorization with STUN protocol is explained.

Enough people who were not actively involved in formulation of the draft 
have commented on understandability issues that I think it would be good 
to make some effort in that area. If section 9 cannot be generalized and 
moved earlier in the document as a way to help readers from outside the 
WG understand the context, then I think something else probably still 
needs to be done.

--Brandon

-- 
Brandon Williams; Chief Architect
Cloud Networking; Akamai Technologies Inc.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 23 Apr 2015 12:22:18 +0000

> Sent: Wednesday, April 22, 2015 12:09 AM
> >> following the flow of the document on their first read, primarily due
> >> to the lack of a high-level picture early in the document. Moving
> >> section 9 back up toward the top of the document would help by giving
> >> readers such a high- level overview early on. The discussion might
> >> need to be generalized a bit in order to serve this purpose, but
> >> comments we've received on the document's usability indicate that this
> change would be helpful.
> >
> > Section 9 is specific to TURN and the ask from the WG is to discuss it in a
> separate section after third party authorization with STUN protocol is
> explained.
> 
> to make some effort in that area. 

I have re-arranged sections 9 and 3. Attached updated draft with diff, Please have a look.

-Tiru

> If section 9 cannot be generalized and
> WG understand the context, then I think something else probably still needs
> to be done.
> 
> --Brandon
> 
> --