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

I don't think OOB communication b/w the STUN and auth servers is a 
solution to the problem of wanting to provide additional details in the 
token. It defeats a large part of the purpose of moving to a token model 
in the first place, which was to avoid the need for these two servers to 
have to communicate directly with each other.

I agree with Martin that it would be useful to have the capability to 
communicate additional information in the token, and I don't recall that 
it was decided that the token wouldn't have this capability (unless by 
decided you mean there wasn't enough interest in the discussion). I 
don't agree that this would necessarily be bad for interoperability, 
provided that individual bits of additional information are never 
required to be present or required to be understood if they are present. 
A list of TLVs at the end of the data space would not be particularly 
difficult to support.

I don't feel strongly enough about providing such a mechanism to push 
for it, but I would be supportive if someone else does.

--Brandon

On 04/14/2015 02:02 AM, Tirumaleswar Reddy (tireddy) wrote:
>> -----Original Message-----
>> From: Oleg Moskalenko [mailto:mom040267@gmail.com]
>> Sent: Tuesday, April 14, 2015 10:57 AM
>> To: Martin Thomson
>> Cc: Tirumaleswar Reddy (tireddy); tram-chairs@ietf.org; tram@ietf.org;
>> Brandon Williams; rlb@ipv.sx; Salz, Rich; Stephen Farrell
>> (stephen.farrell@cs.tcd.ie)
>> Subject: Re: [tram] Stephen Farrell's Discuss on draft-ietf-tram-turn-third-
>> party-authz-13: (with DISCUSS and COMMENT)
>>
>> On Mon, Apr 13, 2015 at 11:17 AM, Martin Thomson
>> <martin.thomson@gmail.com> wrote:
>>>
>>> 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 was discussed in the WG and decision was not to carry any extra token information so as to keep the token size small. In future an out-of-band communication mechanism b/w STUN and authorization server to exchange the token related metadata can be defined similar to the OAuth 2.0 Token Introspection method defined in https://tools.ietf.org/html/draft-ietf-oauth-introspection-07.
>
> -Tiru
> _______________________________________________
> tram mailing list
> tram@ietf.org
> https://www.ietf.org/mailman/listinfo/tram
>

-- 
Brandon Williams; Senior Principal Software Engineer
Emerging Products Engineering; Akamai Technologies Inc.