Re: [pntaw] FW: New Version Notification for draft-reddy-behave-turn-auth-03.txt

Harald Alvestrand <harald@alvestrand.no> Wed, 04 September 2013 09:40 UTC

Return-Path: <harald@alvestrand.no>
X-Original-To: pntaw@ietfa.amsl.com
Delivered-To: pntaw@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50A1C11E81A6 for <pntaw@ietfa.amsl.com>; Wed, 4 Sep 2013 02:40:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.538
X-Spam-Level:
X-Spam-Status: No, score=-110.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TlENb07JpQQb for <pntaw@ietfa.amsl.com>; Wed, 4 Sep 2013 02:40:45 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 0B82E11E819C for <pntaw@ietf.org>; Wed, 4 Sep 2013 02:40:45 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 90EB339E4B0; Wed, 4 Sep 2013 11:40:42 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QjsPMDa8yFcA; Wed, 4 Sep 2013 11:40:41 +0200 (CEST)
Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id CBF8139E4A6; Wed, 4 Sep 2013 11:40:41 +0200 (CEST)
Message-ID: <52270019.8010309@alvestrand.no>
Date: Wed, 04 Sep 2013 11:40:41 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8
MIME-Version: 1.0
To: "Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com>
References: <913383AAA69FF945B8F946018B75898A1904E373@xmb-rcd-x10.cisco.com> <5225EC94.7000601@alvestrand.no> <913383AAA69FF945B8F946018B75898A1905AEF1@xmb-rcd-x10.cisco.com>
In-Reply-To: <913383AAA69FF945B8F946018B75898A1905AEF1@xmb-rcd-x10.cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "pntaw@ietf.org" <pntaw@ietf.org>
Subject: Re: [pntaw] FW: New Version Notification for draft-reddy-behave-turn-auth-03.txt
X-BeenThere: pntaw@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion list for practices related to proxies, NATs, TURN, and WebRTC" <pntaw.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pntaw>, <mailto:pntaw-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pntaw>
List-Post: <mailto:pntaw@ietf.org>
List-Help: <mailto:pntaw-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pntaw>, <mailto:pntaw-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Sep 2013 09:40:50 -0000

On 09/04/2013 10:41 AM, Tirumaleswar Reddy (tireddy) wrote:
> Hi Harald,
>
> Thanks for the comments. Please see inline

Thanks for the rapid turnaround!
>> 4) section 4 bullet 2 assumes that one needs a credentials database at
>> the TURN server to verify the credentials. This is incorrect, as
>> draft-uberti shows; all that is required is that the credentials are
>> verifiable.
> TURN server needs access to a credential database with username, realm and MD5 hash computed over the username, realm, and password. TURN server needs key derived from username and password (key = MD5(username ":" realm ":" SASLprep(password))) to validate message integrity for TURN request and also to calculate message-integrity for TURN response.

For the case where the "password" is machine-generated, not user-chosen, 
there are more options (this was a surprise for me the first time I 
encountered it, too!)

For instance, if

username = <string, maybe chosen by user>
password = base64(HMAC(site-wide secret key + username))

the server that only knows the site-wide secret key can compute what the 
password should have been for any given <string chosen by user>, and 
thereby complete the verification.

(this particular scheme probably has cryptographic weaknesses; most 
schemes not designed by cryptographers are breakable)

You don't need a database, you just need to be able to validate the MAC 
- a database is one implementation.