Re: [OPSAWG] Start of WGLC for TACACS+ document.

Alan DeKok <aland@deployingradius.com> Thu, 06 October 2016 13:57 UTC

Return-Path: <aland@deployingradius.com>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B99FB12965A for <opsawg@ietfa.amsl.com>; Thu, 6 Oct 2016 06:57:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 kfq6rbvTaTIu for <opsawg@ietfa.amsl.com>; Thu, 6 Oct 2016 06:57:09 -0700 (PDT)
Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 11BD3129685 for <OpsAWG@ietf.org>; Thu, 6 Oct 2016 06:56:48 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 465AF1F02; Thu, 6 Oct 2016 13:56:48 +0000 (UTC)
Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dP8vabv6shDd; Thu, 6 Oct 2016 13:56:48 +0000 (UTC)
Received: from [192.168.120.42] (unknown [23.233.24.114]) by mail.networkradius.com (Postfix) with ESMTPSA id 7F01E131C; Thu, 6 Oct 2016 13:56:47 +0000 (UTC)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: text/plain; charset="iso-8859-1"
From: Alan DeKok <aland@deployingradius.com>
X-Priority: 3
In-Reply-To: <025401d21fb8$71906e20$4001a8c0@gateway.2wire.net>
Date: Thu, 06 Oct 2016 09:56:46 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <2769B0A9-00DE-41F8-9971-9C0AABDC8109@deployingradius.com>
References: <CAHw9_iK-1=Epr5CLAtFayd0Bss6oZrsDTfyox6y2SfPJAav78Q@mail.gmail.com> <5019ABA9-BB74-4C69-A455-12C17A2958CE@deployingradius.com> <E6C64895-F0C6-40B8-A687-4DC56590B22E@deployingradius.com> <025401d21fb8$71906e20$4001a8c0@gateway.2wire.net>
To: "t.petch" <ietfc@btconnect.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/Fr7ZJsGVI6USn3V9QYKQC86sT6I>
Cc: "opsawg@ietf.org" <OpsAWG@ietf.org>, draft-ietf-opsawg-tacacs-05@tools.ietf.org, "opsawg-chairs@tools.ietf.org" <OpsAWG-chairs@tools.ietf.org>
Subject: Re: [OPSAWG] Start of WGLC for TACACS+ document.
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Oct 2016 13:57:14 -0000

On Oct 6, 2016, at 6:00 AM, t.petch <ietfc@btconnect.com> wrote:
> Alan is right to pick up on the style - philosophical - and the
> security - lack of.
> 
> But do we want to change it all at this time?

  Please show where I'm trying to change the protocol.

> This is an Informational document describing the state of play as of
> some time past, perhaps not as far back as 1997 but not for 2016.  It
> would require many changes to make it a 2016 Standards Track document
> but that is not what I see us doing except that is how I take Alan's
> comments.

  Then you're not reading my comments.

  I would like to implement historical TACACS+.  I have *NO IDEA* what to do for huge swaths of the protocol.

  I would like to deploy historical TACACS+. I have *NO IDEA* what the security implications are of using it.

> The analogy I have in mind is when SSL v3 was published, long after it
> had been superseded by anyone who took security seriously, but was
> needed as an RFC to refer to, although it would not pass muster because
> the security thereof was too weak.  It would not have met the standards
> of the day but was published  despite that.

  I'm not asking that the protocol be *fixed* in this document.  I'm asking that it be *documented*.  That shouldn't be hard to understand.  I've been saying it for about a year now, for anyone who bothers to read my messages.

  I'll note that RFC 6101 is "Category: Historic", and has substantial text about the security (or lack thereof) of the protocol.  It has substantial text about how the historical protocol works. I'm suggesting we do the same here.

  I'm suggesting the the TACACS+ protocol be documented as designed, in sufficient detail that someone can read the document and create an inter-operable implementation.  I'm suggesting that the  TACACS+ protocols security (or lack thereof) be documented.

  Which is (so far as I'm aware) still IETF practice for informational specifications.

  If the goal for the document is something else, fine.  Update the document to say that.   Something like:

  "This document attempts to specify the historical TACACS+ protocol.  However, there are many portions of the protocol which are under-specified or unspecified.  We cannot second-guess twenty years of practice here.  As a result, this specification is incomplete, under-specified, insecure, and should not be used by anyone to implement anything.  Please wait for the Standards track document to get the actual TACACS+ specification that people can implement".

  If the document can be updated with such text, I'll withdraw all of my review comments.  But I predict that the document won't pass security area review.  And they'll make all of the same comments as I've made here, with a recommendation that the document not be published until it's fixed.

  Alan DeKok.