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

[Oleg Moskalenko <[e-mail]>]

On Tue, Apr 14, 2015 at 9:45 AM, Martin Thomson
<[e-mail]> wrote:
>
>
> I've read it again.  It's clearer on second reading, but still confused.

It requires some time to sink in, I admit. But after some time, you
will see that it correctly describes the procedures needed to get a
third-party authorization for the STUN operations. I agree that this
is not an easiest of the readings.

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

Not true. It also describes how to organize new secure communications
between STUN client and 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.

In the STUN terminology, there is a very big difference between
"short-lived" and "short-term" credentials. You were formerly used the
second term, now you are using the first one. So it is not clear what
exactly you are talking about.

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

I was working on implementation of this thing, and somehow I had no
difficulty understanding that (and I am not an author of the
document).

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

It has a value in security procedures. But the STUN server
administrator is free to set whatever value to the server name, and it
may be not related to DNS or anything. You can set the server name to
"Martin Thomson" and it will be perfectly OK.

>
>> 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 disagree with the "free-style" extra information in the token. If
that extra information is strictly formalized (a formal meta-data with
definite structure) then I am OK with that.

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

>From the system and software architecture and design point of view,
the communications between a standard AS and a standard STUN server
are not very relevant - a simple utility can transfer information
between them, and that utility must not be an integral  part of AS or
STUN server. We can take various STUN and AS servers off-the-shelf and
make the communications work between them. The token structure, on the
other hand, affects the core internal functionality of the STUN
server, and this is why it must be strictly specified.

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

I am not talking about the client authentication.
HTTPS servers can authorize the clients with the client's certificate
- the same way as the clients can authorize the servers. A dedicated
AS HTTPS server will allow only TLS (HTTPS) connections from a few
authorized STUN servers with known certificates. This is an optional
feature of the TLS protocol (that is used by HTTPS) that can be used
here to secure AS-STUN communications.

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

give it more time...

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

more clarifications in the text are always welcome.