IETF Logo Mail Archive

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

Brandon Williams <brandon.williams@akamai.com> Tue, 21 April 2015 18:35 UTC

Return-Path: <brandon.williams@akamai.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 56BAA1A88E6; Tue, 21 Apr 2015 11:35:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.611
X-Spam-Level:
X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 uOKUQvQg00eG; Tue, 21 Apr 2015 11:35:11 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 8BBAB1A88F3; Tue, 21 Apr 2015 11:35:03 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id B4E6747713; Tue, 21 Apr 2015 18:35:02 +0000 (GMT)
Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id A7BAD4770C; Tue, 21 Apr 2015 18:35:02 +0000 (GMT)
Received: from [172.28.115.172] (unknown [172.28.115.172]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id 99A7F8003C; Tue, 21 Apr 2015 18:35:02 +0000 (GMT)
Message-ID: <55369856.7050203@akamai.com>
Date: Tue, 21 Apr 2015 14:35:02 -0400
From: Brandon Williams <brandon.williams@akamai.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: "Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com>, Martin Thomson <martin.thomson@gmail.com>
References: <913383AAA69FF945B8F946018B75898A4120E0BD@xmb-rcd-x10.cisco.com>
In-Reply-To: <913383AAA69FF945B8F946018B75898A4120E0BD@xmb-rcd-x10.cisco.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/tram/c3guqzwv9j7OqxgDuB3e9hTK7LA>
Cc: "rlb@ipv.sx" <rlb@ipv.sx>, "tram-chairs@ietf.org" <tram-chairs@ietf.org>, "Stephen Farrell (stephen.farrell@cs.tcd.ie)" <stephen.farrell@cs.tcd.ie>, "tram@ietf.org" <tram@ietf.org>, "Salz, Rich" <rsalz@akamai.com>
Subject: Re: [tram] Stephen Farrell's Discuss on draft-ietf-tram-turn-third-party-authz-13: (with DISCUSS and COMMENT)
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, 21 Apr 2015 18:35:13 -0000

On 04/15/2015 05:47 AM, Tirumaleswar Reddy (tireddy) wrote:
>> -----Original Message-----
>> From: Martin Thomson [mailto:martin.thomson@gmail.com]
>> Sent: Monday, April 13, 2015 11:47 PM
>> To: Tirumaleswar Reddy (tireddy)
>> Cc: Brandon Williams; rlb@ipv.sx; Salz, Rich; Stephen Farrell
>> (stephen.farrell@cs.tcd.ie); tram@ietf.org; tram-chairs@ietf.org
>> Subject: Re: [tram] Stephen Farrell's Discuss on draft-ietf-tram-turn-third-
>> party-authz-13: (with DISCUSS and COMMENT)
>>
>>
>> It does need to deal with algorithm agility and it currently does not.
>
> It supports algorithm agility. Please refer to http://tools.ietf.org/html/draft-ietf-tram-turn-third-party-authz-13#appendix-B  for the interaction b/w the client and authorization server where the client signals the algorithms it supports and server selects an HMAC algorithm from the list of algorithms the  client provided and determines length of the mac_key based on the selected HMAC algorithm.
>

I'm not sure that key length alone is enough to facilitate the current 
hash agility plan, which is to require a client to send both SHA256 and 
SHA1 HMACs. IMO, either this draft should require 256 bit keys minimum 
and describe what to do to generate a SHA1 key (probably run SHA1 on the 
SHA256 key) or the stunbis editors should commit to providing this 
information in stunbis. I just want to be certain that we will be 
telling implementors what to do somewhere.

--Brandon

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

v2.23.0 | Report a Bug | By Email