Subject: Re: [tram] Possible inconsistency with RFC-7635

From: Mészáros Mihály <[email-masked]>
Date: Fri, 1 Dec 2017 10:45:46 +0100

Hi Kevin,

2017-11-30 17:30 keltezéssel, Kevin Wooten írta:
> All,
>
> 	We have just implemented a STUN/TURN server in Java/Kotlin using Netty. It was originally done after examining “coturn” as a possible solution and deciding we would roll our own for a number of reasons and have completed a working version.
/I am little bit sorry about that you didn't considered to invest the
time in coTURN or similar public efforts instead of opened a new own
private development.
My belief that open joint efforts are always more beneficial. :-) /
>  One of the biggest reasons for rolling our own server was to be able to implement proper accounting, traffic shaping and statistics.  During the implementation we realized that we might have an issue with OAuth authentication.
>
> 	As we implemented RFC-7635 there seems to be an inconsistency we cannot reconcile with the way credentials are required to be handled throughout the spec and those provided by the OAuth spec. Specifically that OAuth POP never provides the server an actual username (and possibly realm) to the server.  This has shown us what appears to be an inconsistency with the original TURN spec (RFC-5766) and it happens to be very limiting when implementing our accounting, shaping and statistics.
>
> -- Inconsistency between RFC-7635 and RFC-5766 —
>
> 	First I’ll inquire about the possible inconsistency... In RFC-5766 section 17.3.3 titled ("Manipulating Other Allocations”) it details an insider attack that is prevented by “requiring that the credentials used in CreatePermission, Refresh, and ChannelBind messages match those used to create the initial allocation”. The requirements for storing and comparing the credentials are mentioned throughout 5766 spec and does not appear to be an “optional” part of the spec as Section 4 paragraph 5 details this as a requirement.
I also think that this is an inconsistency,
but because mac_keys have short lifetime /are ephemeral/, and mac_key is
unique /generated/ value ,
so it may narrow down very much the attack window.
Comparing to LTC, may it could be enough to address this issue.

IMHO the to check this is requirement is meaningless in case of oauth,
and you should skip it.

All in all I think You ought to open an errata on 7635 side..
>
> 	For long term credentials this is fairly easy as the USERNAME uniquely identifies a specific user.  When implementing OAuth we cannot figure out how to do this reliably. The OAuth POP token, provided in ACCESS-TOKEN, only provides the session/mac key, lifetime and timestamp; it doesn’t identify a specific user. The USERNAME only identifies the key id required to decrypt the ACCESS-TOKEN.  We tried using the session/mac key as the “credentials” but since each call to the OAuth AS will produce a difference session/mac key (and possibly even use a different key id) it causes subsequent requests (e.g. REFRESH) to fail; this was proven when we ran interoperation tests with coturn’s test client.  This is especially prevalent when the ACCESS-TOKEN expires and needs to be refreshed because it will definitely generate a new session/mac key. Essentially, this means anybody who was issued a token with the same key id (kid) is considered to be the same user and therefore _could_ manipulate another’s allocation; although the attack seems remote and requires spoofing it nonetheless is detailed as a requirement.
>
> 	I’d like to know if our interpretation is wrong, if we’re missing something or if this is a valid inconsistency in specs. In any case, it does seem a proper username and possibly realm should be retrievable _somewhere_ in an OAuth authenticated request; whether in a new attribute, the original attribute (and key id moved someplace else), in the ACCESS-TOKEN, or maybe it’s there and we’ve missed exactly how to derive it.
>
> -- Impediment related to accounting and statistics —
I see the same way...
You are right RFC7635 does not signal any additional data in
access_token just what you have mentioned..
This allows only a grant/deny service classification.
To add more information may in other hand adds some possibility for
servers to log and fingerprint the user. IMHO we should not stick it to
user ID directly.

I agree that there is no fine grained classification, and so there is no
possibility for traffic shaping/limiting based on username or similar id..
> 	This is basically a follow on to the previous.. One of our stated goals was proper accounting, shaping, and statistics. This is not easily done in the current form of RFC-7635 as we only have the key id (in USERNAME) to identify clients. As you might imagine this is not useful for out stated purposes. For example, trying to traffic shape (e.g. bandwidth throttling) per user is pretty hard when the user isn’t known. 
>
> 	The only work arounds we seem to have are using a unique long term key per user or some form of communication between the TURN server and the AS server to exchange a session/mac key for proper user identification; we’d really love to avoid either of those as they corrupt many of the advantages of using the OAuth mechanism. If we are able to resolve the inconsistency stated in the previous section, this issue resolves itself because we would have a proper username/userid in the request.
I think it is needed to update RFC7635 anyhow (e.g. to support CWT
tokens. , many erratas etc.)
To work on an update may solve all of your issues.

Just my 2 cents..
Misi

Ps. I am pretty sure I am not as well informed and smart and precise
etc., as the most people on this list,
      so take my opinions with care.. !!!