Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DE031A052B for ; Mon, 17 Feb 2014 10:29:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VmEq0uEoM9vm for ; Mon, 17 Feb 2014 10:29:13 -0800 (PST) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 9103C1A0239 for ; Mon, 17 Feb 2014 10:29:13 -0800 (PST) Received: by mail-pd0-f173.google.com with SMTP id y10so15155073pdj.4 for ; Mon, 17 Feb 2014 10:29:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=d8rJqBMB6YIUs3oSY1UBSw1jsx6NYxQ6oICVTfszlk4=; b=DxUCqnc8S8lhjCw6nDSKoVLIevo+OjTTYEpMoU5Qq8NVJqqThTKHnZblYb2u0/2Xn3 YQwuxhNNodzNiXbj0Bxl8s+RmatMnIodWF/dlnVVHZAJjbuWoYwFhG+MaANjULdyH1MO nHtioyvWhLLRRAdZHHrziLQ1xsM+p9GS5j2joS0ua1Kbin1Z4uFmM278tFCxXsQZ2PSM zZs5bXvyF1Ozs4NDBYiEEWxUiKL5lvnQ7Ppu4fIsQ6JIn4ccogRDzBo6/KlDFgDHLdmY VO7CFjc/psMzxhUO5ew/+4mufDTRdLa3xACvB3YymL3O7Td4EY6LEoxZhwO67rvmzSOD audQ== MIME-Version: 1.0 X-Received: by 10.66.160.2 with SMTP id xg2mr27777209pab.23.1392661751061; Mon, 17 Feb 2014 10:29:11 -0800 (PST) Received: by 10.68.147.131 with HTTP; Mon, 17 Feb 2014 10:29:11 -0800 (PST) In-Reply-To: <913383AAA69FF945B8F946018B75898A242AF33F@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A242AF33F@xmb-rcd-x10.cisco.com> Date: Mon, 17 Feb 2014 10:29:11 -0800 Message-ID: From: Oleg Moskalenko To: "Tirumaleswar Reddy (tireddy)" Content-Type: multipart/alternative; boundary=047d7bacb47cf6e0a804f29e5421 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/CJt1EUCIkHX_EeR0EDmsJDB08_g Cc: "tram@ietf.org" Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-turn-third-party-authz-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 18:29:16 -0000 --047d7bacb47cf6e0a804f29e5421 Content-Type: text/plain; charset=ISO-8859-1 Hi Tiru please see below as [Oleg]: On Mon, Feb 17, 2014 at 3:10 AM, Tirumaleswar Reddy (tireddy) < tireddy@cisco.com> wrote: > Hi Oleg, > > Thanks for the review. Please see inline [TR] > > From: Oleg Moskalenko [mailto:mom040267@gmail.com] > Sent: Sunday, February 16, 2014 10:31 AM > To: Tirumaleswar Reddy (tireddy) > Cc: tram@ietf.org > Subject: Re: [tram] FW: New Version Notification for > draft-reddy-tram-turn-third-party-authz-00.txt > > Hi Tiru > I have some comments: > 1) Section 4. Obtaining a Token Using OAuth, figure 4 > > I believe that the sequence of messages is incorrect. The TURN server most > probably will contact the Authorization server AFTER it gets the Allocate > request. But on the figure 4, it looks like it somehow can predict the > incoming request. The correct sequence must be, in the general case: > Access Token Request (1) from client to Auth server > Access Token + Session Key (2) from Auth server to client > Allocate request from client to TURN server (3) > Get Token from TURN Server to Auth server (4) > Token metadata from Auth Server to TURN server (5) > Allocate response from TURN server to the client (6) > > [TR] Good catch, fixed it. It got messed when we were changing from > self-contained to handle token. > > The sequence shown on the figure 4 is possible only is the Auth Server and > TURN server are somehow closely integrated and that is unnecessary. > > [TR] Yes, the AS and TURN server have to be integrated. There may be ways > to standardize this, but this is not in the scope of this doc right away. > [Oleg]: I am afraid that if we require that AS and TURN to be provided by the same company, it may affect the adoption of this approach. > > 2) The document is saying that the client when communicating to the Auth > Server uses HTTP requests with JSON (REST API ?). May be it would be > helpful if the communication protocol between TURN server and Auth server > would be mentioned, too. > > [TR] Drafts in OAuth WG like > https://tools.ietf.org/html/draft-richer-oauth-introspection-04 discuss > the communication mechanism b/w Resource Server and Authorization server. > You may also want to look into > http://www.ietf.org/mail-archive/web/oauth/current/msg08607.html which > discusses such communication mechanism already implemented but for a > different purpose. I guess it all worked because Resource server and > Authorization server are developed by the same company but with this use > case we may have to discuss if standardization is required for the > communication mechanism. > [Oleg]: As I said, if the AS and TURN in practice will have to be provided by the same company, then that may be a problem - it will affect the standard adoption by the WebRTC community. I'll have to explore the current situation with the open-source OAuth servers - whether they provide a viable "introspection" protocol. I hope some protocol recommendations can be provided for third-party AS communications. > > 3) Section 7.2: > > OAuth does not impose any limitation on the length of the access token > but since > STUN messages cannot exceed 548 bytes (Section 7.1 of [RFC5389]), > access token length needs to be restricted to fit within the maximum > STUN message size. > > I am not sure that the STUN (Binding ?) max message size is relevant here > and worth mentioning at all - because this doc is about TURN, and the TURN > messages are often much larger than 548 bytes (especially when carrying the > video traffic). So I see no relevance of the 548 limit to the new > authentication standard. And that limitation of 548 bytes is applicable > only to the cases when we suspect that the path MTU is really really low > and that is an extremely rare case. > > [TR] Good point. But RFC 5766 recommends to restrict the size (Section 2.7 > Avoiding Fragmentation) > > > > As a guideline, sending a maximum of 500 bytes of application data in > a single TURN message (by the client on the client-to-server leg) or > a UDP datagram (by the peer on the peer-to-server leg) will generally > avoid IP fragmentation. > > > [Oleg]: We recently had a discussion about that in WebRTC forum, with Justin. He is saying that the WebRTC client tools (Chrome) assume the minimum practical MTU as 1280 and that limit is used for media traffic. And he is right that this MTU is a real modern practical limit. > > > 4) Are we sure that we want to limit the OAuth applicability only to the > long-term credentials mechanism ? I see no technical or philosophical > reasons why not to use it for short-term credentials mechanism, too. It > would be a more "symmetric" approach. > > [TR] what is the use case for short-term credential mechanism with TURN ? > [Oleg]: Currently WebRTC uses only the long-term credentials mechanism but still there is a TURN standard for the short-term mechanism. While I cannot provide any concrete example, I suppose there are some. And I believe that OAuth is orthogonal to the TURN auth mechanism used - they can be combined either way. So I see that coupling OAuth with the long-term mechanism is rather artificial. > > 5) I'd put more definite wording how TURN server handles the token > lifetime. What happens in the middle of the TURN session, is the auth token > expires while the session is still active ? There may be two possible cases: > - the token lifetime is applicable only to the session initiation > procedure. When the TURN session has been already established, it can go > indefinitely while the client is refreshing the session properly. > - in second case when the token expires, the server rejects new > requests from the client (in the same TURN session) until the client sends > the new token data in re-authentication exchange. > > I'd suggest the first case as an eisier case for the implementation. > > [TR] The client MUST obtain a new token after the previously used one > expires. As you point out an already established TURN session can continue, > the new token is applicable for new requests. [Oleg]: Tiru, I'd still like to hear a more definite language: what about "new requests" within the existing session ? They are allowed to use the old token - right ? When you are saying "new requests" you mean "new session allocation requests", right ? Regards, Oleg --047d7bacb47cf6e0a804f29e5421 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Tiru

please see below as [Oleg]:=



On Mon, Feb 17, 2014 at 3:10 AM, Tirumaleswar Reddy (tireddy) <tired= dy@cisco.com> wrote:
Hi Oleg,

Thanks for the review. Please see inline [TR]

From: Oleg Moskalenko [mailto:mom040= 267@gmail.com]
Sent: Sunday, February 16, 2014 10:31 AM
To: Tirumaleswar Reddy (tireddy)
Cc: tram@ietf.org
Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-turn-= third-party-authz-00.txt

Hi Tiru
I have some comments:
1) Section 4. Obtaining a Token Using OAuth, figure 4

I believe that the sequence of messages is incorrect. The TURN server most = probably will contact the Authorization server AFTER it gets the Allocate r= equest. But on the figure 4, it looks like it somehow can predict the incom= ing request. The correct sequence must be, in the general case:
=A0=A0 Access Token Request (1) from client to Auth server
=A0=A0 Access Token + Session Key (2) from Auth server to client
=A0=A0 Allocate request from client to TURN server (3)
=A0=A0 Get Token from TURN Server to Auth server (4)
=A0=A0 Token metadata from Auth Server to TURN server (5)
=A0=A0 Allocate response from TURN server to the client (6)

[TR] Good catch, fixed it. It got messed when we were changing from s= elf-contained to handle token.

The sequence shown on the figure 4 is possible only is the Auth Server and = TURN server are somehow closely integrated and that is unnecessary.

[TR] Yes, the AS and TURN server have to be integrated. There may be = ways to standardize this, but this is not in the scope of this doc right aw= ay.

[Oleg]: I am afraid that if we requ= ire that AS and TURN to be provided by the same company, it may affect the = adoption of this approach.
=A0

2) The document is saying that the client when communicating to the Auth Se= rver uses HTTP requests with JSON (REST API ?). May be it would be helpful = if the communication protocol between TURN server and Auth server would be = mentioned, too.

[TR] Drafts in OAuth WG like https://tools.ietf.or= g/html/draft-richer-oauth-introspection-04 discuss the communication me= chanism b/w Resource Server and Authorization server. =A0You may also want = to look into http://www.ietf.org/mail-archive/web/oauth= /current/msg08607.html which discusses such communication mechanism alr= eady implemented but for a different purpose. I guess it all worked because= Resource server and Authorization server are developed by the same company= but with this use case we may have to discuss if standardization is requir= ed for the communication mechanism.

[Oleg]: As I said, if the AS and TURN in p= ractice will have to be provided by the same company, then that may be a pr= oblem - it will affect the standard adoption by the WebRTC community. I'= ;ll have to explore the current situation with the open-source OAuth server= s - whether they provide a viable "introspection" protocol. I hop= e some protocol recommendations can be provided for third-party AS communic= ations.=A0
=A0

3) Section 7.2:

=A0 =A0OAuth does not impose any limitation on the length of the access tok= en but since
=A0 =A0STUN messages cannot exceed 548 bytes (Section 7.1 of [RFC5389]), =A0 =A0access token length needs to be restricted to fit within the maximum=
=A0 =A0STUN message size.

I am not sure that the STUN (Binding ?) max message size is relevant here a= nd worth mentioning at all - because this doc is about TURN, and the TURN m= essages are often much larger than 548 bytes (especially when carrying the = video traffic). So I see no relevance of the 548 limit to the new authentic= ation standard. And that limitation of 548 bytes is applicable only to the = cases when we suspect that the path MTU is really really low and that is an= extremely rare case.

[TR] Good point. But RFC 5766 recommends to restrict the size (Sectio= n 2.7 Avoiding Fragmentation)

<snip>

=A0 =A0As a guideline, sending a maximum of 500 bytes of application data i= n
=A0 =A0a single TURN message (by the client on the client-to-server leg) or=
=A0 =A0a UDP datagram (by the peer on the peer-to-server leg) will generall= y
=A0 =A0avoid IP fragmentation.

</snip>

[Oleg]: We recently had a= discussion about that in WebRTC forum, with Justin. He is saying that the = WebRTC client tools (Chrome) assume the minimum practical MTU as 1280 and t= hat limit is used for media traffic. And he is right that this MTU is a rea= l modern practical limit.
=A0


4) Are we sure that we want to limit the OAuth applicability only to the lo= ng-term credentials mechanism ? I see no technical or philosophical reasons= why not to use it for short-term credentials mechanism, too. It would be a= more "symmetric" approach.

[TR] what is the use case for short-term credential mechanism with TU= RN ?

[Oleg]: Currently WebRTC uses only= the long-term credentials mechanism but still there is a TURN standard for= the short-term mechanism. While I cannot provide any concrete example, I s= uppose there are some. And I believe that OAuth is orthogonal to the TURN a= uth mechanism used - they can be combined either way. So I see that couplin= g OAuth with the long-term mechanism is rather artificial.
=A0

5) I'd put more definite wording how TURN server handles the token life= time. What happens in the middle of the TURN session, is the auth token exp= ires while the session is still active ? There may be two possible cases: =A0=A0 - the token lifetime is applicable only to the session initiation pr= ocedure. When the TURN session has been already established, it can go inde= finitely while the client is refreshing the session properly.
=A0=A0 - in second case when the token expires, the server rejects new requ= ests from the client (in the same TURN session) until the client sends the = new token data in re-authentication exchange.

I'd suggest the first case as an eisier case for the implementation.
[TR] The client MUST obtain a new token after the previously used one= expires. As you point out an already established TURN session can continue= , the new token is applicable for new requests. =A0

[Oleg]: Tiru, I'd still like to hear a more definite languag= e: what about "new requests" within the existing session ? They a= re allowed to use the old token - right ? When you are saying "new req= uests" you mean "new session allocation requests", right ?
=A0
Regards,
Oleg

--047d7bacb47cf6e0a804f29e5421--