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

[Martin Thomson <[e-mail]>]

On 10 April 2015 at 18:58, Tirumaleswar Reddy (tireddy)
<[e-mail]> wrote:
> Richard and we have already have discussed the comments further and resolved them, attached updated draft with diff.
> Main changes
>
> [1] Removed DKSPP
> [2] Removed non-AEAD algorithms; using AEAD modes AES-GCM and aead-aes-cbc
> [3] Updated the token format


I read this just now for the first time in a while.  Either I'm a lot
stupider this morning than I normally am, or this draft is very
confused.  There are some serious problems in here.

If you intend to use RFC 5116, please clearly specify the inputs, as
described in Section 2.1:
https://tools.ietf.org/html/rfc5116#section-2.1 Currently, the draft
uses N for the name of the server.  That conflicts with the label that
RFC 5116 uses for the nonce.  Also, the draft is very vague about the
construction of the nonce.  The draft certainly doesn't need to refer
to the CBC AEAD draft.

It does need to deal with algorithm agility and it currently does not.


I apologize for not reviewing this earlier.  Here are more comments.

Section 1 doesn't really explain what the draft provides.

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

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

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.  What is the base URI?  What
prevents a random internet denizen from acquiring this symmetric key?
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.

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.

The replay protection in Section 7 is not sufficient.  If the intent
is to prevent replay, then the server needs to maintain a
globally-consistent register of the requests that it has seen so that
it can correctly reject replays.  However, I think that the intent is
to permit replay, so perhaps it is the case that casting this as
anti-replay is counter-intuitive.  That said, I believe that this is a
serious DoS vector and we should be recommending that servers at least
account for what has been replayed and limit the number of times a
particular token can be used.

If the intent of the lifetime in the token is to prevent replay, then
this is bad:

  o  The lifetime provided by the TURN server in the Allocate and
      Refresh responses MUST be less than or equal to the lifetime of
      the token.

Tying the two lifetimes together means that you need to have a long
token lifetime in order to support long sessions.  But long token
lifetimes means long periods of exposure to replay and lots of
maintained state.  See earlier point about policies being carried in
the token.

Section 8 seems completely unnecessary.  What resource is being
conserved here?  It's more work to maintain all this state and
validate all those tokens than it is to respond in the affirmative to
STUN request.  (Also, why doesn't STUN usage get a fancy OAuth mapping
table like Section 9?  Is it somehow different?)

In summary, I'm surprised that a document in this state was put before the IESG.