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

[Martin Thomson <[e-mail]>]

On 13 April 2015 at 22:26, Oleg Moskalenko <[e-mail]> wrote:
> On Mon, Apr 13, 2015 at 11:17 AM, Martin Thomson
> <[e-mail]> wrote:
>>
>> Section 1 doesn't really explain what the draft provides.
>
> I disagree. It is pretty clear on general description what this draft
> is about. At least, it was obvious to me from the very first reading.

I've read it again.  It's clearer on second reading, but still confused.

The abstract says:

   This document proposes the use of OAuth 2.0 to obtain and validate
   ephemeral tokens that can be used for Session Traversal Utilities for
   NAT (STUN) authentication.

But the document doesn't do that at all.  It describes the
communications between the authorization server and the STUN server.
Sort of.

Here's what I'd say:

1. Long-term secrets can't be sent to untrusted TURN clients, such as
a browser using WebRTC. These clients need to be given short-lived
credentials.

2. This document describes how the OAuth framework can be applied to
this problem.
   - A client is directed to an authorization server to retrieve an
access token.  Clients are configured with the authorization server
and the method of retrieval.
   - Clients retrieve a token from the authorization server (using
whatever proprietary method they choose).
   - Clients sends the token in a TURN server in Allocate or Refresh requests.
   - TURN servers use information in the token in authorizing these requests.

3. This document defines the ACCESS-TOKEN STUN attribute that is used
to carry the authorization token provided by an authorization server.

I see no value in standardizing protocol interactions (4.1.1) or the
access token format.  I can't work out how to make the
THIRD-PARTY-AUTHORIZATION work at all.

>> Section 3 claims to be an overview, but it doesn't actually describe
>> what happens.  It leaves the token acquisition part out of scope.
>> That's fine, but it doesn't describe how the THIRD-PARTY-AUTHORIZATION
>> attribute might be used, even in the broadest sense.
>
> It describes it in section 6.1.

Not really.

6.1 says that the presence of the attribute indicates that third party
authorization is needed.  It doesn't describe what the value is *for*.
Given that it's not actually possible to act on the information that
it does provide without some external information, I fail to see the
value of the attribute.

> "Server name" is just a logical whatever name. It is not related to
> anything that you mentioned; that is just a well-known name, set by
> the STUN server administrator. I believe that this is pretty clear
> from the text.

Are you saying that the value has no protocol value?

> I believe that extra token information is a very very bad idea - it
> kills the whole interoperability thing in the draft. If we are adding
> "extra" information to the token, we can as well just kill the draft
> and tell the STUN server developers "do whatever you want, secure the
> stuff somehow, we do not care".

Well, we can disagree about this.

I also disagree with the idea that this interface between STUN server
and authorization server can be standardized in such a half-hearted
fashion.  If the HTTP interaction is out of scope, then why isn't the
token construction also out of scope?

> I suppose that's pretty clear that the AS and STUN server mutual
> communications are protected by TLS certificates that they trust.

I suppose that you mean this: "HTTPS MUST be used for mutual
authentication and confidentiality."  HTTPS doesn't provide client
authentication natively, so I attributed this to a misunderstanding
about what HTTPS could provide.  If you say that this is important,
authorizing access to the long-term key is not given proper treatment.

There's nothing in the security considerations; there should be.

>> Section 5 fails to explicitly state whether the MAC key is used as
>> input to short term or long term credentials.  It needs to say short
>> term, I think.
>
> No. The whole document is about the LONG-TERM credentials. That's
> pretty clear for everybody who followed the STUN security, and it is
> getting mentioned in the text many times (just search for "long-term"
> on the page).

"long-term" is used in the introduction as part of an explanation that
essentially says that long-term credentials are broken for the WebRTC
use case.  That much is true.

Elsewhere it is used exclusively to describe the long-term credentials
shared between the authorization server and the STUN server.

Nothing is said at all regarding what method to use for STUN MESSAGE-INTEGRITY.

>> Section 7 seems to imply two layers of authentication: the AEAD and
>> some HMAC.  I can't work out what is being authenticated.  I'm not
>> sure that anyone else could either.
>
> I am afraid that you simply need more time to read that document.

I did spend more time.  I now understand why I was so confused by the
text.  Why would this document repeat text from a document that it
doesn't even need to cite?

Also, I just noticed that this uses base64.  That's arbitrary.  Does
the client remove that encoding before including the token in the STUN
message?  There's no MUST there, but it seems like it's part of the
process somehow.