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

[Oleg Moskalenko <[e-mail]>]

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.

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

> It doesn't
> explain why it's a server name, or how that name relates to the domain
> name of the server (i.e., the one that might have been passed to a DNS
> resolver).

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

>
> Section 4 doesn't permit any additional information to be carried in
> the token.  Therefore, the STUN/TURN server is unable to apply any
> additional policies that the authorization server might impose, such
> as limits on the length of the session, the number of ports allocated,
> or the bandwidth that is allocated.  (Or whatever we might later
> conceive of.)

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

>
> It's not clear what Section 4.1.1 is for.  If this is private
> communications, then it is far too specific.  If this is intended to
> be normative, then it isn't sufficient.

That is something that I agree with.

>  What is the base URI?  What
> prevents a random internet denizen from acquiring this symmetric key?

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

> Why these two specific parameters?  Why does the expiration
> information in the JWK replicate what HTTP provides?  I'd be far
> happier with hand-waving than with this section in place.
>
> 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).

>
> Why does this document use 'kid' rather than USERNAME?  Isn't the
> point to get a short term  username+password pair from the
> authorization server?
>
> 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.

Thanks
Oleg