Re: [OPSAWG] I-D Action: draft-ietf-opsawg-tacacs-tls13-03.txt

Alan DeKok <aland@deployingradius.com> Tue, 11 July 2023 19:17 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 8B176C169502 for <opsawg@ietfa.amsl.com>; Tue, 11 Jul 2023 12:17:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ELDb-ENbijl0 for <opsawg@ietfa.amsl.com>; Tue, 11 Jul 2023 12:16:58 -0700 (PDT)
Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1469FC131809 for <opsawg@ietf.org>; Tue, 11 Jul 2023 12:16:57 -0700 (PDT)
Received: from smtpclient.apple (135-23-95-173.cpe.pppoe.ca [135.23.95.173]) by mail.networkradius.com (Postfix) with ESMTPSA id E3E06368; Tue, 11 Jul 2023 19:16:55 +0000 (UTC)
Authentication-Results: NetworkRADIUS; dmarc=none (p=none dis=none) header.from=deployingradius.com
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
From: Alan DeKok <aland@deployingradius.com>
In-Reply-To: <ae412ed1-e92c-2fd2-9906-43bbd3e53b69@web.de>
Date: Tue, 11 Jul 2023 15:16:54 -0400
Cc: opsawg@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <B714BE27-5551-4526-B971-C03578577BB5@deployingradius.com>
References: <168805050611.46147.7135705558590726585@ietfa.amsl.com> <BN9PR11MB537112089669BC32EF2C0772B82FA@BN9PR11MB5371.namprd11.prod.outlook.com> <ae412ed1-e92c-2fd2-9906-43bbd3e53b69@web.de>
To: Marc Huber <Marc.Huber@web.de>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/AUgEV6Sr8ejBaPLgAmM3dyVuvUQ>
Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-tacacs-tls13-03.txt
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.39
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: Tue, 11 Jul 2023 19:17:02 -0000

On Jul 5, 2023, at 3:25 PM, Marc Huber <Marc.Huber@web.de> wrote:
> I still unsure whether the
> 
>   Obsolescence of TACACS+ Obfuscation
> 
> section could hinder implementations and migrations using TLS wrappers (load balancers, e.g.). I'd still suggest to change the "MUST" clauses regarding obufuscation to "SHALL". There's no gain to change the protocol at this point, it's sufficient to wrap it in TLS. If a client insists in using obfuscation-over-TLS, that should be fine, even if it's of no use. 

  We did that for RADIUS. i.e. leave in MD5-based "crypto" when we did RADIUS/TLS 10 years ago.  We're now ripping it out.

  I would suggest that using obfuscation over TLS is a bad idea.  While it's tempting to just say "wrap it in TLS", leaving MD5 in has other costs.  Most notably FIPS, where insecure digests like MD5 are banned.

  Reading the fine print of FIPS suggests that using MD5 in this way is allowed for a protocol like TACACS+TLS.  But few people read the fine print, and taking out the MD5-based captor is likely best.

> Regarding a dedicated TCP port: Is there really a need for that, or would this rather be an convenience option? A specific port number limits the attack surface to a single port, and I don't see any need for that.

  I think a dedicated port for TACACS+TLS would be good.

  Alan DeKok.