Re: [secdir] Secdir review of draft-ietf-behave-turn-13

Philip Matthews <philip_matthews@magma.ca> Thu, 12 March 2009 23:18 UTC

Return-Path: <philip_matthews@magma.ca>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EC2C3A6B09 for <secdir@core3.amsl.com>; Thu, 12 Mar 2009 16:18:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3j6UaZcCXZ4k for <secdir@core3.amsl.com>; Thu, 12 Mar 2009 16:18:05 -0700 (PDT)
Received: from mail-08.primus.ca (mail11.primus.ca [216.254.141.178]) by core3.amsl.com (Postfix) with ESMTP id 649E13A696F for <secdir@ietf.org>; Thu, 12 Mar 2009 16:18:05 -0700 (PDT)
Received: from [24.139.16.154] (helo=[10.0.1.2]) by mail-08.primus.ca with esmtpa (Exim 4.63) (envelope-from <philip_matthews@magma.ca>) id 1LhuAk-0005BX-1Z; Thu, 12 Mar 2009 19:18:42 -0400
Message-Id: <5B811D30-3006-43BE-803B-6379BFCD54CE@magma.ca>
From: Philip Matthews <philip_matthews@magma.ca>
To: Paul Hoffman <paul.hoffman@vpnc.org>, Russ Housley <housley@vigilsec.com>
In-Reply-To: <p06240808c5dd84c7fbc4@[10.20.30.158]>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v929.2)
Date: Thu, 12 Mar 2009 19:18:36 -0400
References: <p06240803c5dd708c3db4@[10.20.30.158]> <20090311142053.0F97D78839E@smtpout.capalon.com> <p06240808c5dd84c7fbc4@[10.20.30.158]>
X-Mailer: Apple Mail (2.929.2)
X-Authenticated: philip_matthews@magma.ca - ([10.0.1.2]) [24.139.16.154]
X-Mailman-Approved-At: Fri, 13 Mar 2009 11:34:06 -0700
Cc: Rohan Mahy <rohan@ekabal.com>, Jonathan Rosenberg <jdrosen@cisco.com>, secdir@ietf.org
Subject: Re: [secdir] Secdir review of draft-ietf-behave-turn-13
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Mar 2009 23:18:06 -0000

On Wed, 11-Mar-09, at 11:11 , Paul Hoffman wrote:

> At 10:16 AM -0400 3/11/09, Russ Housley wrote:
>> Does this mean MUST implement and SHOULD use?
>
> Good question, and I think the answer is that the document does not  
> *require* that authentication be implemented. That is, I couldn't  
> find a place where it said one way or another. I will defer to the  
> document authors to answer that one.


Section 4 (General Behavior) says:

    In addition, the server SHOULD demand that all requests from the
    client be authenticated, using the Long-Term Credential mechanism
    described in [RFC5389], and the client MUST be prepared to
    authenticate requests if required.

Thus clients will interoperate with a server, regardless of whether it  
requires authentication or not. There is no statement about what  
servers must implement, just what they should do. However, I think  
that most people recognize that the security of TURN is pretty poor  
without authentication, unless TLS transport is used.

- Philip