Re: [tram] FW: New Version Notification for draft-reddy-tram-turn-third-party-authz-00.txt

Oleg Moskalenko <> Tue, 18 February 2014 06:10 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C02851A0358 for <>; Mon, 17 Feb 2014 22:10:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id chVjJ0I-P2vc for <>; Mon, 17 Feb 2014 22:10:04 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c03::230]) by (Postfix) with ESMTP id 84C601A05EB for <>; Mon, 17 Feb 2014 22:09:50 -0800 (PST)
Received: by with SMTP id kx10so16163940pab.21 for <>; Mon, 17 Feb 2014 22:09:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=36zZ0ONyKFmGxkc8Ecs7yQTErqq7g1WCpWsSR9ClBp0=; b=L8tOyE5aA56kbWjBjQpkl9f4SMod+lqWpv2pMvMHXWTA+/mr3D70jxIJ4RLAxsvHU4 yupPQGlzCpb8Yu+1wlBWpEayDvY89DvbD4wGrA5kuihZ+lq/911Z/GEvd+poaC2oczRl 4xNeb5GJP40v9Ac1qv/EbTKZYtIKEtD8gk/NJE4+Dd7R2hJbUUYacwSqPD4vvKUBuUjK UoOSFL2V00DYGGeBaUC+XJSaWfauMxCCVcmhDniKP6rUI2w35qPCcuFHjPAkVSE79UMt /hSQGRY3vC80GqtEnypNY8n22dn2uiZxtXYeghN2WUZFAH74eDRTNgxJddX3ED8JeI2j pefw==
MIME-Version: 1.0
X-Received: by with SMTP id sp3mr31276867pab.100.1392703787797; Mon, 17 Feb 2014 22:09:47 -0800 (PST)
Received: by with HTTP; Mon, 17 Feb 2014 22:09:47 -0800 (PST)
In-Reply-To: <>
References: <>
Date: Mon, 17 Feb 2014 22:09:47 -0800
Message-ID: <>
From: Oleg Moskalenko <>
To: "Tirumaleswar Reddy (tireddy)" <>
Content-Type: multipart/alternative; boundary="047d7b6d82708c913504f2a81ebd"
Cc: "" <>
Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-turn-third-party-authz-00.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 18 Feb 2014 06:10:06 -0000

Hi Tiru

regarding the authentication mechanisms: yes, I am talking about section
10.1 of STUN RFC 5389:

STUN defines both short-term mechanism and long-term mechanism. They differ
in the ways how the INTEGRITY field is calculated, and in some other minor
details. The names are somewhat unfortunate and confusing; the "short-term
mechanism" is NOT about short-lived ephemeral identities. The proposed
token-based authorization is equally applicable to both short-term and
long-term mechanisms - taking into account different INTEGRITY calculation

>From the pure technical point of view, I think that the token authorization
is equally applicable to the short-term mechanism than to the long-term

Of course the short-term mechanism is not very important in this context
because this proposed standard is mostly about WebRTC. But it would be
"cleaner" if the token authorization will be applied to the whole STUN/TURN
specs, not to a particular case of WebRTC. And may be some day WebRTC will
decide to adopt the short-term mechanism...