Subject: [OPSAWG] Adam Roach's Discuss on draft-ietf-opsawg-tacacs-13: (with DISCUSS and COMMENT)

From: Adam Roach via Datatracker <[email-masked]>
Date: Wed, 15 May 2019 23:04:45 -0700

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..."

---------------------------------------------------------------------------

---

From: Adam Roach <[email-masked]>
Date: Thu, 16 May 2019 09:34:46 -0500

> one of its username preparation profiles, and indicate its password

And I completely missed that RFC 7613 has been obsoleted by RFC 8265. 
Please consult RFC 8265 instead.

/a