Re: [tram] Two new authentication mechanisms

Hi Oleg,

Good question. 

1) Don't we still need realm in the third-party authorization ?
Reply> No
2) Am I missing something ? I was under impression that we still have realms, together with the tokens.
Reply> The kid (unique key identifier) used in the draft solves the problem of TURN server (resource server) to interact with different authorization servers (from different domains); At high-level it works as follows, kid is returned by the authorization server which is signaled by the client to the TURN server, TURN server uses kid to pick the appropriate keying material. 

Thanks and Regards,
-Tiru

From: Oleg Moskalenko [mailto:mom040267@gmail.com] 
Sent: Tuesday, July 01, 2014 1:13 AM
To: Tirumaleswar Reddy (tireddy)
Cc: Simon Perreault; tram@ietf.org
Subject: Re: [tram] Two new authentication mechanisms

I agree that two drafts can be kept independently.
As for the ORIGIN attribute in the third-party authorization environment - don't we still need realm in the third-party authorization ? Am I missing something ? I was under impression that we still have realms, together with the tokens.
Thanks
Oleg

On Mon, Jun 30, 2014 at 10:53 AM, Tirumaleswar Reddy (tireddy) <tireddy@cisco.com> wrote:
I support adoption of both drafts. I think there is no interaction required between these two drafts. For example If third party authorization is used then ORIGIN attribute could be used by the TURN server for logging purpose.

-Tiru

> -----Original Message-----
> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Simon Perreault
> Sent: Friday, June 27, 2014 6:51 PM
> To: tram@ietf.org
> Subject: [tram] Two new authentication mechanisms
>
> TRAMsters,
>
> We are soliciting discussion on the potential adoption as working-group
> documents of these two drafts:
>
> http://tools.ietf.org/html/draft-johnston-tram-stun-origin
> http://tools.ietf.org/html/draft-reddy-tram-turn-third-party-authz
>
> They would be targeted at fulfilling milestone 4 ("Nov 2014 - Send new
> authentication mechanism(s) to IESG for publication as Proposed Standard").
>
> If you would like to see one or both of the drafts adopted, or if you are opposed,
> please explain why. Authors, we will assume you are for adoption of your own
> drafts.
>
> Please consider the interactions between the two drafts. Is there anything
> interesting or problematic? What about overlap in function? Is there any? If so,
> is it necessary or problematic?
>
> Let's take two weeks to discuss this.
>
> Thanks,
> Simon & Gonzalo
>
> _______________________________________________
> tram mailing list
> tram@ietf.org
> https://www.ietf.org/mailman/listinfo/tram

_______________________________________________
tram mailing list
tram@ietf.org
https://www.ietf.org/mailman/listinfo/tram