[OPSAWG] Adam Roach's Discuss on draft-ietf-opsawg-tacacs-13: (with DISCUSS and COMMENT)
Adam Roach via Datatracker <noreply@ietf.org> Thu, 16 May 2019 06:04 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: opsawg@ietf.org
Delivered-To: opsawg@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 830B3120092; Wed, 15 May 2019 23:04:45 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Adam Roach via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-opsawg-tacacs@ietf.org, Joe Clarke <jclarke@cisco.com>, opsawg-chairs@ietf.org, opsawg-chairs@ietf.org, jclarke@cisco.com, opsawg@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.96.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Adam Roach <adam@nostrum.com>
Message-ID: <155798668553.30465.3681431548982215622.idtracker@ietfa.amsl.com>
Date: Wed, 15 May 2019 23:04:45 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/cB8Q-RtwDLjOL5o5mNi9eqjE5zo>
Subject: [OPSAWG] Adam Roach's Discuss on draft-ietf-opsawg-tacacs-13: (with DISCUSS and COMMENT)
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.29
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, 16 May 2019 06:04:46 -0000
Adam Roach has entered the following ballot position for draft-ietf-opsawg-tacacs-13: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-tacacs/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks to everyone who has worked on documenting the TACACS+ protocol as it is used today. I understand the desire to publish this document as a status other than Historic, as the protocol remains in use today. However, the shortcomings cited in the "Security Considerations" section are quite profound, and really bear highlighting in the document way before we get into what is fundamentally end material. I have serious misgivings about publishing this document as anything other than Historic without some prominent text early in the document (e.g., in the Introduction section) that warns implementors of the several caveats detailed in section 10 and its subsections. They don't need to be explained here, but some language along the lines of the following really needs to be present in order to scope the document: Note that the original TACACS+ implementations did not address all of the baseline security concerns which are considered when designing modern protocols. This document does not change this situation, and implementors should use caution when evaluating the suitability of TACACS+ for any given use. Please see section 10 for additional details. --------------------------------------------------------------------------- §4.6: > To ensure interoperability of current deployments, the TACACS+ client > and server MUST handle user fields and those data fields used for > passwords as 8-bit octet strings. The deployment operator MUST > ensure that consistent character encoding is applied from the end > client to the server. The encoding SHOULD be UTF-8, and other > encodings outside printable US-ASCII SHOULD be deprecated. Without specification of preparation profiles for usernames and passwords, this is an incomplete specification of how to transmit non-ASCII usernames and passwords. While there are other solutions, the easy way to address this is to normatively reference RFC 7613, and select one of its username preparation profiles, and indicate its password preparation profile. The most basic problem here is that I might create a username and/or password on a machine that uses one mapping for a non-ASCII character, and later try to log in on a machine that uses a different, but semantically equivalent, mapping for that same character. This is a clear interop issue. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- ID Nits reports: ** Obsolete normative reference: RFC 1334 (Obsoleted by RFC 1994) --------------------------------------------------------------------------- §2: > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in RFC 2119 RFC2119 > [RFC2119]. Please use the boilerplate from RFC 8174. --------------------------------------------------------------------------- §4.3: > The packet header contains the TAC_PLUS_SINGLE_CONNECT_FLAG used by > the client and server to negotiate the use of Single Connect Mode. This is a bit jarring, as the document hasn't yet established the existence of a packet header, or of flag in that header. It might be better to pull section 4.8 earlier in the document -- at least before this sentence -- so that readers have some context for understanding what's going on. --------------------------------------------------------------------------- §4.7: > Server implementations MUST allow a unique secret key to be > associated with every client. Nit: "...with each client." --------------------------------------------------------------------------- §5.1: > network address if the user is connected via a network, a caller ID > is the user is connected via ISDN or a POTS Nit: "...if the user..." --------------------------------------------------------------------------- §5.4.2.1: Is the intention here to limit the characters in the user name and the password to be only those in the ASCII range? Section 4.6 would seem to indicate that this isn't the case, but the title of this section throws that into doubt. If the text in 4.6 is the guiding text here, perhaps section 5.4.2.1 should indicate that the term "ASCII" is used only for historical reasons, and that both usernames and passwords can contain UTF-8-encoded character strings. --------------------------------------------------------------------------- §5.4.2.2: > the data > field MUST contain the PAP ASCII password. Same comment as for section 5.4.2.1, above. --------------------------------------------------------------------------- §5.4.2.3: > defined in the PPP Authentication RFC RFC 1334 [RFC1334] and then > compare that value with the response. Nit: "...and then compares..." --------------------------------------------------------------------------- §5.4.2.7. ASCII change password request Same comment as for section 5.4.2.1. --------------------------------------------------------------------------- §5.4.3: > If this > flag is set, the data portion of the message may contain an ASCII > message explaining the reason for the abort. Does this mean "ASCII" or does it mean "UTF-8"? If it actually means "ASCII," then localization -- especially to localities that use non-latin-based alphabets -- will be incredibly challenging. --------------------------------------------------------------------------- §6.2 and §7.2: > server_msg, server_msg_len > > This is a printable US-ASCII string that may be presented to the > user. > > data, data_len > > This is a printable US-ASCII string that may be presented on an > administrative display, console or log Same comment as for section 5.4.3. --------------------------------------------------------------------------- §8.1: > All attribute values are encoded as printable US-ASCII strings. The > following type representations SHOULD be followed ... > String > > Many values have no specific type representation and so are > interpreted as plain strings. Same comment as for section 5.4.3. --------------------------------------------------------------------------- §8.3: > err_msg (String) > > A printable US-ASCII string describing the status of the action. Same comment as for section 5.4.3. --------------------------------------------------------------------------- §10.5.3: > To help TACACS+ administraots select the stronger authentication Nit: "...administrators..." ---------------------------------------------------------------------------
- [OPSAWG] Adam Roach's Discuss on draft-ietf-opsaw… Adam Roach via Datatracker
- Re: [OPSAWG] Adam Roach's Discuss on draft-ietf-o… Adam Roach
- Re: [OPSAWG] Adam Roach's Discuss on draft-ietf-o… Douglas Gash (dcmgash)
- Re: [OPSAWG] Adam Roach's Discuss on draft-ietf-o… Douglas Gash (dcmgash)