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

["Prashanth Patil (praspati)" <[e-mail]>]

Hi Stephen,

On 4/28/15, 2:22 PM, "Stephen Farrell" <[e-mail]> wrote:

>Stephen Farrell has entered the following ballot position for
>draft-ietf-tram-turn-third-party-authz-15: 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 https://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:
>https://datatracker.ietf.org/doc/draft-ietf-tram-turn-third-party-authz/
>
>
>
>----------------------------------------------------------------------
>DISCUSS:
>----------------------------------------------------------------------
>
>
>Edited discuss ballot after chats around Dallas.
>
>(1)  cleared
>
>(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. (I've sent a
>mail to the WG list, this will clear shortly once
>that is discussed.)
>
>(3)  cleared (but see now comments below this is
>still badly done IMO)
>
>
>----------------------------------------------------------------------
>COMMENT:
>----------------------------------------------------------------------
>
>
>NEW COMMENTS: 
>
>- As some others have said before, this is still not an easy
>read and though better, could still do with more editorial
>work.
>
>- Why are 4.1.1 and 4.1.2 still just examples. You need one
>to be MTI or you won't get interop. Indeed 4.1.2 says you
>SHOULD do 4.1.1! Please just bite the bullet and clearly say
>that 4.1.1 is MTI.

The WG consensus was for it to be SHOULD. We¹d have to get consensus for
it to be MTI, I suppose.

>
>- 4.1.1, "HTTPS MUST be used for mutual authentication" is
>not a very clear way to say it. You mean that HTTPS MUST be
>used and that TLS with mutual authentication based on client
>certificates MUST be used.

Sure, we¹ll reword to make this more obvious.

> How does the WebRTC server know
>what CA the TURN server is going to use? That's another point
>of pre-arrangement that will be needed.

Yes, there has to be pre-arrangement. Pre-arrangement is required
nonetheless because the WebRTC server needs to trust the TURN server to
establish symmetric keys.

>
>- 4.1.1, I thought the web folks frowned upon specifying URI
>parameters like that. Shouldn't you at least use a
>.well-known URL or something so as to not get on someone
>eles's lawn?

Yes, will update.

>
>- 6.2, PATH_MTU is not the correct term. There are
>two paths involved, from WebRTC to browser and from
>browser to TURN server and MTUs need not be the same
>on those paths.

Path MTU, in this context, refers to the one between the client and TURN
server.
Since the WebRTC server is never aware of the path MTU between the client
and TURN server, we¹ve tried to keep the token size as small as possible.


>
>OLD COMMENTS BELOW HERE, I DIDN'T CHECK
>THOSE.
>
>- I really think this would benefit from some wider review
>and I don't think it's ready as-is.

The draft was reviewed by the OAuth WG.


>
>- I agree with Richard's discuss points.

Richard¹s comments are addressed in the latest version
http://tools.ietf.org/html/draft-ietf-tram-turn-third-party-authz-15.


>
>- intro: "impossible in web applications" isn't really
>true in principle, but impossible in WebRTC as it uses JS
>is true.

> 
The latest revision reflects this change.
http://tools.ietf.org/html/draft-ietf-tram-turn-third-party-authz-15#sectio
n-1

>
>- 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; the session key is only used to compute
message integrity of STUN request and validate message integrity of 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?

DKSPP is removed in the latest version.


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

The STUN server and the AS. The latest revision reflects this change.


>
>- 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?

Already answered earlier.

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

4.1.3 has been removed.

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

Yes. The latest revision reflects this change.
  
>
>- 9: Why 5 seconds?

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


Thanks,
Prashanth

>
>
>_______________________________________________
>tram mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/tram