[OPSAWG]Re: TACACS+ TLS Resumption and PSK.

Alan DeKok <aland@deployingradius.com> Tue, 29 October 2024 21:35 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 9F7E3C169411 for <opsawg@ietfa.amsl.com>; Tue, 29 Oct 2024 14:35:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 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, T_SCC_BODY_TEXT_LINE=-0.01] 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 NhZBjvw93IMO for <opsawg@ietfa.amsl.com>; Tue, 29 Oct 2024 14:35:07 -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 ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4ED61C151092 for <opsawg@ietf.org>; Tue, 29 Oct 2024 14:35:06 -0700 (PDT)
Received: from smtpclient.apple (135-23-95-232.cpe.pppoe.ca [135.23.95.232]) by mail.networkradius.com (Postfix) with ESMTPSA id B7399295; Tue, 29 Oct 2024 21:34:58 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
From: Alan DeKok <aland@deployingradius.com>
In-Reply-To: <DM4PR11MB63847CDF57DDB71FA34B1A64B74A2@DM4PR11MB6384.namprd11.prod.outlook.com>
Date: Tue, 29 Oct 2024 17:34:57 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <24BDEED6-4712-4657-8A2F-71126276E38E@deployingradius.com>
References: <171958741031.6614.6192371628253402915@ietfa.amsl.com> <BL3PR11MB636498065CA94698B937E5CCB7DF2@BL3PR11MB6364.namprd11.prod.outlook.com> <BL3PR11MB63647995AABAED8113F9DDBFB7DA2@BL3PR11MB6364.namprd11.prod.outlook.com> <DM4PR11MB63847CDF57DDB71FA34B1A64B74A2@DM4PR11MB6384.namprd11.prod.outlook.com>
To: "Douglas Gash (dcmgash)" <dcmgash@cisco.com>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
Message-ID-Hash: 4ET2QKUZDOUQQK5U3JEDTKN5OGOT2BX4
X-Message-ID-Hash: 4ET2QKUZDOUQQK5U3JEDTKN5OGOT2BX4
X-MailFrom: aland@deployingradius.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-opsawg.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: "opsawg@ietf.org" <opsawg@ietf.org>, John Heasly <heas@shrubbery.net>, Andrej Ota <andrej@ota.si>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [OPSAWG]Re: TACACS+ TLS Resumption and PSK.
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/D_L1bDm7nfEhg1zSobp9iOwLg8Y>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Owner: <mailto:opsawg-owner@ietf.org>
List-Post: <mailto:opsawg@ietf.org>
List-Subscribe: <mailto:opsawg-join@ietf.org>
List-Unsubscribe: <mailto:opsawg-leave@ietf.org>

On Oct 28, 2024, at 7:51 AM, Douglas Gash (dcmgash) <dcmgash@cisco.com> wrote:
> Rev 11 of the T+ TLS doc had new sections for PSK and resumption, with a slight restructure to accommodate PKI and PSK in regular hierarchy in the contents.
>  
> We are currently preparing another rev of the doc, so would be very grateful for any feedback to ensure the previous paucity of coverage of these subjects was sufficiently remedied. If not, now would be ideal time for us to address any remaining concerns in this (or any other) area.

  From the -14 version:

2.1 nits: 

... The algorithm is categorized as Obfuscation in Section 10.5.2 of [RFC8907]. The term should be interpreted to mean "plaintext", it is used to ensure that the algorithm is not mistaken for encryption.

  The obfuscation method is not "plaintext".  Perhaps "while there are no known attacks on this method, it is not known to be secure."

  Similarly in Section 3:

... Confidentiality and Integrity: The MD5 obfuscation specified in [RFC8907] has been shown to be insecure [RFC6151].

  MD5 has been cracked.  But there are no known attacks on the obfuscation method used.

3 item (2):

...	• Peer authentication: The authentication capabilities of TLS replace the pre-shared keys of obfuscation for mutual authentication.

  Perhaps use "shared secret' for consistency with RFC 8907.  "Pre-shared keys" sounds like PSKs used for TLS.

5

  Perhaps add a note that TACACS+ TLS servers and clients SHOUD NOT use well-known CAs.  i.e. CAs from the web PKI.  Doing so would allow clients to connect to any server, and would allow anyone to issue client certs.

5.1.1

... Non-TLS connections should not be used for new TACACS+ deployments.

  Perhaps make this normative: SHOULD NOT be used

... Further, TLS TACACS+ servers and Non-TLS TACACS+ servers SHOULD NOT be deployed on the same host. 

  Why?  There's no justification here.  I'm not sure why this would be an issue.

5.1.4

... Operators should be cognizant of the potential of TLS TACACS+ server and/or client isolation from their peer's CA by network failures. Isolation from a public key certificate's CA will cause the verification of the certificate to fail and thus TLS authentication of the peer to fail.

  I'm not sure why it's an issue if the CA is unreachable.  The TACACS+ TLS server has to be configured with the CA cert, and all intermediate certs.  The client should ideally also be configured with the CA cert.  There's no need to contact the CA, the CA cert is just a file on disk.

  Why does the CA have to be online?


  Overall the changes look reasonable, thanks.

  Alan DeKok.