[OPSAWG]Re: TACACS+ TLS Resumption and PSK.
heasley <heas@shrubbery.net> Wed, 06 November 2024 22:59 UTC
Return-Path: <heas@shrubbery.net>
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 BCAE2C1D4A93 for <opsawg@ietfa.amsl.com>; Wed, 6 Nov 2024 14:59:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 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, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_PERMERROR=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 WIeQ0z_REs_V for <opsawg@ietfa.amsl.com>; Wed, 6 Nov 2024 14:59:42 -0800 (PST)
Received: from sea.shrubbery.net (sea.shrubbery.net [129.250.47.99]) (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 53E9BC1CAF42 for <opsawg@ietf.org>; Wed, 6 Nov 2024 14:59:41 -0800 (PST)
Received: by sea.shrubbery.net (Postfix, from userid 7053) id 2D23F173427; Wed, 06 Nov 2024 23:00:33 +0000 (UTC)
Date: Wed, 06 Nov 2024 23:00:33 +0000
From: heasley <heas@shrubbery.net>
To: Alan DeKok <aland@deployingradius.com>
Message-ID: <Zyv1EfNCgUvBipAF@shrubbery.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <24BDEED6-4712-4657-8A2F-71126276E38E@deployingradius.com>
Message-ID-Hash: ZE7MLWLFZ362RQFSGRFW23RWVNMNQA5R
X-Message-ID-Hash: ZE7MLWLFZ362RQFSGRFW23RWVNMNQA5R
X-MailFrom: heas@shrubbery.net
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>, "Douglas Gash (dcmgash)" <dcmgash@cisco.com>, 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/O47q91P5RR3F8rL_NpAwESnB6tw>
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>
> 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. I think that you mean something like, SHOULD NOT, unless the client also authenticates the server, which it should. Correct? > 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? Unless the client (or server) has a complete cache of its peer's issuer path, the certificate can not be verified following rfc5280 methods. It is reasonable to expect that a network device might not have this, whether the CA is well-known or private. If it can not be verified, and the client (or server) strictly requires it, which it should, then the connection should be abandoned. No? Therefore, if the operators wishes it to always work, this must be considered. > Alan DeKok.
- [OPSAWG]Re: OPSAWG Digest, Vol 205, Issue 20 Douglas Gash (dcmgash)
- [OPSAWG]Re: OPSAWG Digest, Vol 205, Issue 20 Joe Clarke (jclarke)
- [OPSAWG]Re: OPSAWG Digest, Vol 205, Issue 20 Marc Huber
- [OPSAWG]TACACS+ TLS Resumption and PSK. Douglas Gash (dcmgash)
- [OPSAWG]Re: TACACS+ TLS Resumption and PSK. Alan DeKok
- [OPSAWG]Re: TACACS+ TLS Resumption and PSK. mohamed.boucadair
- [OPSAWG]Re: TACACS+ TLS Resumption and PSK; secti… Douglas Gash (dcmgash)
- [OPSAWG]Re: TACACS+ TLS Resumption and PSK. heasley
- [OPSAWG]Re: TACACS+ TLS Resumption and PSK. Alan DeKok
- [OPSAWG]Re: TACACS+ TLS Resumption and PSK. Douglas Gash (dcmgash)
- [OPSAWG]Re: TACACS+ TLS Resumption and PSK. Douglas Gash (dcmgash)