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

heasley <heas@shrubbery.net> Thu, 01 December 2022 05:32 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 E071BC13A073 for <opsawg@ietfa.amsl.com>; Wed, 30 Nov 2022 21:32:00 -0800 (PST)
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 tb-zkOn3Qsjm for <opsawg@ietfa.amsl.com>; Wed, 30 Nov 2022 21:31:56 -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 RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5678AC13A06E for <opsawg@ietf.org>; Wed, 30 Nov 2022 21:31:56 -0800 (PST)
Received: by sea.shrubbery.net (Postfix, from userid 7053) id 77E4B3A88AA; Thu, 1 Dec 2022 05:31:55 +0000 (UTC)
Date: Thu, 01 Dec 2022 05:31:55 +0000
From: heasley <heas@shrubbery.net>
To: opsawg@ietf.org
Cc: andrej@ota.si, dcmgash@cisco.com, heas@shrubbery.net, thorsten.dahm@gmail.com
Message-ID: <Y4g8SzupPkBSLotd@shrubbery.net>
References: <166987104468.50685.985158519755735069@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <166987104468.50685.985158519755735069@ietfa.amsl.com>
X-PGPkey: http://www.shrubbery.net/~heas/public-key.asc
X-note: live free, or die!
X-homer: i just want to have a beer while i am caring.
X-Claimation: an engineer needs a manager like a fish needs a bicycle
X-reality: only YOU can put an end to the embarrassment that is Tom Cruise
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/iehc1oH8dTkMZkKBnJisU38YCZs>
Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-tacacs-tls13-01.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: Thu, 01 Dec 2022 05:32:01 -0000

Wed, Nov 30, 2022 at 09:04:04PM -0800, internet-drafts@ietf.org:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Operations and Management Area Working Group WG of the IETF.
> 
>         Title           : TACACS+ TLS 1.3
>         Authors         : Thorsten Dahm
>                           Douglas Gash
>                           Andrej Ota
>                           John Heasley
>   Filename        : draft-ietf-opsawg-tacacs-tls13-01.txt
>   Pages           : 11
>   Date            : 2022-11-30
> 
> Abstract:
>    The TACACS+ Protocol [RFC8907] provides device administration for
>    routers, network access servers and other networked computing devices
>    via one or more centralized servers.  This document, a companion to
>    the TACACS+ protocol [RFC8907], adds Transport Layer Security
>    (currently defined by TLS 1.3 [RFC8446]) support and obsoletes former
>    inferior security mechanisms.
> 

This addresses two of the comments made by Joe Clarke.  Among which,
Joe asked that mishandling of the TAC_PLUS_UNENCRYPTED_FLAG in a TLS
connection be treated as FAIL, which means that the authen or author
failed and the client would stop and not proceed to other servers or
methods.

Upon reviewing to make this change, we concluded that this was not
quite the correct behavior, based on the current behavior of similar
errors in RFC8907 (S4.5 specifically), it should proceed to other servers
or methods.

So, the draft, in S4, now specifies returning ERROR rather than FAIL or
ignoring the deprecated flag.  Hopefully, this change agrees with
everyone.

We still have some operators/security considerations to address and the
issues raised by Alan.