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

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 15 Apr 2015 16:09:00 +0000

> -----Original Message-----
> From: tram [mailto:[email-masked]] On Behalf Of Brandon Williams
> Sent: Tuesday, April 14, 2015 6:07 PM
> To: [email-masked]
> Subject: 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.

The size of the metadata will determine if in-band or OOB is required.

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

Yes, there was not enough interest in the discussion.

-Tiru

> 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:[email-masked]]
> >> Sent: Tuesday, April 14, 2015 10:57 AM
> >> To: Martin Thomson
> >> Cc: Tirumaleswar Reddy (tireddy); [email-masked];
> >> [email-masked]; Brandon Williams; [email-masked]; Salz, Rich; Stephen
> >> Farrell
> >> ([email-masked])
> >> 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
> >> <[email-masked]> 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
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/tram
> >
> 
> --
> Brandon Williams; Senior Principal Software Engineer Emerging Products
> Engineering; Akamai Technologies Inc.
> 
> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram

---

From: Brandon Williams <[email-masked]>
Date: Tue, 21 Apr 2015 14:46:19 -0400

> The size of the metadata will determine if in-band or OOB is required.

The point is that OOB direct communication between the STUN and auth 
servers is not even an option for many 3rd party auth use cases. Also, 
if we don't provide a mechanism now then I think it may hurt interop to 
do so later, since servers that don't understand the extra information 
won't know how to handle it.

--Brandon

-- 
Brandon Williams; Chief Architect
Cloud Networking; Akamai Technologies Inc.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 22 Apr 2015 02:25:46 +0000

> Sent: Wednesday, April 22, 2015 12:16 AM
> To: [email-masked]
> >> 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.
> >
> servers is not even an option for many 3rd party auth use cases. 

We have to first identify the metadata, the problems it solves, it's format, if we want to support both proprietary and standard TLV, how to handle cases if metadata is large and could cause fragmentation of request, OOB verses in-band communication etc. All the above work requires a separate draft.

> Also, if we
> don't provide a mechanism now then I think it may hurt interop to do so
> later, since servers that don't understand the extra information won't know
> how to handle it.

One possible way could be add an opaque field at the end of the encrypted_block for future enhancements.

-Tiru