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

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Fri, 1 May 2015 04:43:17 +0000

> -----Original Message-----
> From: Stephen Farrell [mailto:[email-masked]]
> Sent: Thursday, April 30, 2015 2:06 PM
> To: Oleg Moskalenko
> Cc: Prashanth Patil (praspati); The IESG; [email-masked]; [email-masked];
> [email-masked];
> [email-masked]; draft-ietf-tram-turn-third-party-
> [email-masked]; [email-masked]
> Subject: Re: [tram] Stephen Farrell's Discuss on draft-ietf-tram-turn-third-
> party-authz-15: (with DISCUSS and COMMENT)
> 
> 
> 
> On 30/04/15 09:22, Oleg Moskalenko wrote:
> > On Thu, Apr 30, 2015 at 12:47 AM, Stephen Farrell
> > <[email-masked]> wrote:
> >>
> >>
> >> On 30/04/15 02:02, Oleg Moskalenko wrote:
> >
> > Yes, we disagree. With your proposal, you will achieve exactly
> > opposite from what you are declaring.
> >
> > WebRTC server and TURN server are modular servers. They have different
> > semi-independent parts. The essential parts functionality is dictated
> > by the corresponding standards. There is absolutely no necessity to
> > mandate one way or another in the key exchange parts. In reality, as
> > it is usually deployed, the same people are controlling both servers.

Yes, even for the use case where TURN server and WebRTC server are in different administrative domains (e.g. Akamai only providing the relay service) the feedback is that MTI is not required for key exchange. I got  similar response even from OAuth WG http://www.ietf.org/mail-archive/web/oauth/current/msg14321.html using long-term secret b/w AS and RS for OAuth 2.0 self-contained token.

-Tiru

---

From: Oleg Moskalenko <[email-masked]>
Date: Thu, 30 Apr 2015 23:25:24 -0700

On Thu, Apr 30, 2015 at 9:43 PM, Tirumaleswar Reddy (tireddy)
<[email-masked]> wrote:
> Yes, even for the use case where TURN server and WebRTC server are in different administrative domains (e.g. Akamai only providing the relay service) the feedback is that MTI is not required for key exchange.

Yes, this is a good example.

> I got  similar response even from OAuth WG http://www.ietf.org/mail-archive/web/oauth/current/msg14321.html using long-term secret b/w AS and RS for OAuth 2.0 self-contained token.

Yes, that group is very cautious.

---

From: Brandon Williams <[email-masked]>
Date: Tue, 12 May 2015 13:31:01 -0400

Resending with a condensed recipient list that will hopefully still get 
to the same set of people and be accepted by the tram list. Sorry for 
the duplicate message to those who got it already.

---

I can see the value of a MTI for interop. It would be good for any relay 
service to be able to on-board new customers without requiring 
development effort on the part of either the relay service provider or 
the customers, and a MTI would make that more likely to be the case.

That said, I'm not convinced that we've identified a suitable MTI 
method, and no one has yet been able to point me at a suitable method in 
use in a similar context. Also, as Tiru notes, I'm not convinced that an 
MTI is required for initial adoption of the method.

In short, I think a MTI key exchange method is a good goal, but I don't 
think we're in a position to declare one at this time and I don't think 
it's necessary to declare one in order to begin seeing adoption of the 
3rd party auth method.

--Brandon

On 05/01/2015 12:43 AM, Tirumaleswar Reddy (tireddy) wrote:
> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram
>

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

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