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: Brandon Williams [mailto:[e-mail]]
> Sent: Tuesday, April 14, 2015 6:36 PM
> To: Tirumaleswar Reddy (tireddy); Stephen Farrell; 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: 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:[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)
> >>
> >>
> >> (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.