IETF Logo Mail Archive

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

"Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com> Tue, 18 February 2014 12:27 UTC

Return-Path: <tireddy@cisco.com>
X-Original-To: tram@ietfa.amsl.com
Delivered-To: tram@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB2A61A04B1 for <tram@ietfa.amsl.com>; Tue, 18 Feb 2014 04:27:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.048
X-Spam-Level:
X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7IH8JUfGBFRi for <tram@ietfa.amsl.com>; Tue, 18 Feb 2014 04:27:05 -0800 (PST)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 3DA721A04A0 for <tram@ietf.org>; Tue, 18 Feb 2014 04:27:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9706; q=dns/txt; s=iport; t=1392726422; x=1393936022; h=from:to:cc:subject:date:message-id:mime-version; bh=P+kZPVNSp9DP9nnt2BScAz3vFVbKqaR6mwm6/3mt+p4=; b=CLTA36QV205//rZyqE+fqxpZja861lgEsNxu1uRBgEQkaTUYmdf7LTDU L4ZKV975YK/utJ1T/6oe5eA4OH4N35VfF2kfj8jomVSXcIMcdfg4XLKA0 R4NphKBgsfdMiM8UIY0zw8Lu/NbiliHM7lmMiX9R2E0jMmVlN7nsWWE7P M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AnwGACVRA1OtJXG8/2dsb2JhbABZgkJEOFe2d4hZgRUWdIIlAQEBBC1KAhIBCA4DBAEBCwsDDygRFAgBCQEEDgUIh2kDEQ3DKw2IDxeMZ4FpMQYLDoMMgRQElkCDHosshUWBb4E+gio
X-IronPort-AV: E=Sophos; i="4.97,501,1389744000"; d="scan'208,217"; a="304815168"
Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-3.cisco.com with ESMTP; 18 Feb 2014 12:27:02 +0000
Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1ICR1KH003922 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Feb 2014 12:27:01 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.67]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Tue, 18 Feb 2014 06:27:01 -0600
From: "Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com>
To: Oleg Moskalenko <mom040267@gmail.com>
Thread-Topic: [tram] FW: New Version Notification for draft-reddy-tram-turn-third-party-authz-00.txt
Thread-Index: Ac8spLbVrMRo14D/Q1CjsUPyTnakbw==
Date: Tue, 18 Feb 2014 12:27:01 +0000
Message-ID: <913383AAA69FF945B8F946018B75898A242C05A3@xmb-rcd-x10.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [173.39.66.212]
Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A242C05A3xmbrcdx10ciscoc_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tram/10y6stNqARC6ztvXZ1OmA4n9KpA
Cc: "tram@ietf.org" <tram@ietf.org>
Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-turn-third-party-authz-00.txt
X-BeenThere: tram@ietf.org
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." <tram.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tram>, <mailto:tram-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tram/>
List-Post: <mailto:tram@ietf.org>
List-Help: <mailto:tram-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tram>, <mailto:tram-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Feb 2014 12:27:08 -0000

Hi Oleg,

"short-term mechanism" is currently only used for ICE connectivity checks and not used for TURN. I don't see any difference how the INTEGRITY field is calculated with both the short-term and long-term credential mechanisms
key = MD5(username ":" realm ":" SASLprep(password))
The only exception is "realm" would always be missing for short-term mechanism.

Anyways like you have mentioned with third party authorization the session key (password), kid (username) would change frequently and has similarities with short-term mechanism.

-Tiru
From: Oleg Moskalenko [mailto:mom040267@gmail.com]
Sent: Tuesday, February 18, 2014 11:40 AM
To: Tirumaleswar Reddy (tireddy)
Cc: tram@ietf.org<mailto:tram@ietf.org>
Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-turn-third-party-authz-00.txt

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

http://tools.ietf.org/search/rfc5389#section-10.1

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 algorithms.
>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 mechanism.
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...

Regards,
Oleg

v2.23.0 | Report a Bug | By Email