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

From: "Stephen Farrell" <[email-masked]>
Date: Tue, 28 Apr 2015 14:22:04 -0700

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.

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

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

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

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.

- I agree with Richard's discuss points.

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

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

- 4.1.1: Hmmm. How many people use KeyProv I wonder?

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

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

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

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

- 9: Why 5 seconds?

---

From: "Prashanth Patil (praspati)" <[email-masked]>
Date: Wed, 29 Apr 2015 19:18:11 +0000

Hi Stephen,

>https://datatracker.ietf.org/doc/draft-ietf-tram-turn-third-party-authz/

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

>certificates MUST be used.

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

> How does the WebRTC server know

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.

>.well-known URL or something so as to not get on someone

Yes, will update.

>browser to TURN server and MTUs need not be the same

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.

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

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

>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

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

>TLS server here? I don't think that'll scale will it?

Already answered earlier.

>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

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
>[email-masked]
>https://www.ietf.org/mailman/listinfo/tram

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 29 Apr 2015 21:44:53 +0100

> The WG consensus was for it to be SHOULD. We¹d have to get consensus for

I'd encourage you to really try hard on that. As you have it,
different implementations just might not work with one another
at all if developers make varying choices about 4.1.1 vs. 4.1.2
vs. something else entirely. That seems to me to be an interop
failure by the WG.

S

---

From: Oleg Moskalenko <[email-masked]>
Date: Wed, 29 Apr 2015 18:02:25 -0700

> vs. something else entirely. That seems to me to be an interop

different implementations of what ? TURN Servers do not have to
interact with each other. The interactions are between WebRTC server
and TURN servers. I see it as perfectly OK if different TURN servers
access different WebRTC servers in a different manner. This WG is
about STUN and TURN; I do not think that we have to deal with WebRTC
servers standardization. I believe that the document addresses the
TURN server operations standard in a proper way, and leaves the
question of WebRTC to their WG.

How the TURN server stores the credentials, amd how those credentials
are getting filled in the database, is not the topic of this WG, I
believe.

Thanks
Oleg

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 30 Apr 2015 08:47:02 +0100

On 30/04/15 02:02, Oleg Moskalenko wrote:
> and TURN servers. 

Clearly.

> I see it as perfectly OK if different TURN servers
> access different WebRTC servers in a different manner. 

That is not the same as picking a mandatory to implement method,
which is what I'm arguing for.

> This WG is

We disagree then. ISTM that either everyone will implement 4.1.1 or
else this specification will produce interop failures or go unused
when the probability that a WebRTC server and TURN server share a key
is not sufficiently high for people to bother turning this on. (And
yes, that's as fallible prediction as most people's:-)

S.

---

From: Oleg Moskalenko <[email-masked]>
Date: Thu, 30 Apr 2015 01:22:47 -0700

> which is what I'm arguing for.

I am against a mandatory method - because that topic has nothing to do
with STUN and TURN functionality. The implementation method sections
must be just an examples. There may be million different ways to
exchange the keys between WebRTC and the TURN server.

> yes, that's as fallible prediction as most people's:-)

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.
They may decide how they want to implement the key exchange. Today,
they can take off-the-shelf parts for WebRTC and TURN servers, and
then they can write a set of simple scripts for the key
replication/exchange/etc. If there will be a mandatory method, I
predict that there will be less available parts and less supply of the
necessary parts for the deployment.

Overall, I do not think that any TURN standard has to be containing
the exact HTTP/HTTPS details, protocols and APIs. Those are just
foreign particles and they can be easily left out of scope.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 30 Apr 2015 09:35:50 +0100

> it is usually deployed, the same people are controlling both servers.

I don't believe that assumption was stated as being the basis for
tram was it? It is certainly not what I assume when reading the
description for a 3 party protocol as in this draft. And nor does
this draft make any such statement that I recall. If that is to
be an assumption for this work, then I'd suggest that be affirmed
by the WG and documented in the draft.

> foreign particles and they can be easily left out of scope.

That seems to me like a really odd way to consider interoperability.

But, we have sufficient clarity in our disagreement I think:-)

S.