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

[Alexey Melnikov via Datatracker <[e-mail]>]

Alexey Melnikov 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:
----------------------------------------------------------------------

I appreciate that this is documenting an existing protocol and I am very glad
that it is being documented. However there are several things which are still
not documented well enough/not in enough details to implement. So I would like
to discuss these issues before recommending approval of this document:

1) 4.6.  Text Encoding

   All text fields in TACACS+ MUST be printable US-ASCII, excepting

Please add a reference to RFC 20 (for US-ASCII) here. Without out it
"printable" has no meaning.

   special consideration given to user field and data fields used for
   passwords.

   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

Please add Normative RFC 3629 reference here for UTF-8.

   encodings outside printable US-ASCII SHOULD be deprecated.

I am not sure what this mean. You didn't define allowed encoding (really you
mean charsets).

2) In 5.1:

   The printable US-ASCII name of the client port on which the
   authentication is taking place,

This doesn't mean anything. Is there a registry? It doesn't look like you are
using transport service name registry for this. Is it a fixed list?

   and its length in bytes.  The value
   of this field is client specific.  (For example, Cisco uses "tty10"
   to denote the tenth tty line and "Async10" to denote the tenth async
   interface).  The port_len indicates the length of the port field, in
   bytes.

3) Later in 5.1:

   A printable US-ASCII string indicating the remote location from which
   the user has connected to the client.  It is intended to hold a
   network address

What are the allowed formats for IPv4 and IPv6? Or is this just human readable?

   if the user is connected via a network, a caller ID
   is the user is connected via ISDN or a POTS, or any other remote
   location information that is available.

4) In 5.4:

   If the information being requested by the server form the client is
   sensitive, then the server should set the TAC_PLUS_REPLY_FLAG_NOECHO
   flag.  When the client queries the user for the information, the
   response MUST NOT be echoed as it is entered.

What does the last sentence mean? (When is it ever echoed?) Are you missing a
forward reference or some explanation of echoing?

5) KRB5 and KRB4 need normative references.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

In 4.8:

4.8.  The TACACS+ Packet Header

   The total length of the packet body (not including the header).

In network byte order? There is some text about that in 4.9, but readers don't
know that yet.

In 6.1:

   The arguments are the primary elements of the authorization
   interaction.  In the request packet they describe the specifics of
   the authorization that is being requested.  Each argument is encoded
   in the packet as a single arg filed (arg_1...  arg_N) with a

Typo: filed --> field.

   corresponding length fields (which indicates the length of each
   argument in bytes).

Later in the same section:

   Optional arguments are ones that may be disregarded by either client
   or server.  Mandatory arguments require that the receiving side can
   handle the attribute, that is: its implementation and configuration
   includes the details of how to act on it.  If the client receives a
   mandatory argument that it cannot handle, it MUST consider the
   authorization to have failed.  It is legal to send an attribute-value
   pair with a zero length value.

Last sentence: do you just mean that the value can be empty?

In 8.1:

   Date Time

   Absolute date/times are specified in seconds since the epoch, 12:00am
   Jan 1 1970.  The timezone MUST be UTC unless a timezone attribute is
   specified.  Stardate is canonically inconsistent and so SHOULD NOT be
   used.

I am not sure what the last sentence means.

In 8.2:

8.2.  Authorization Attributes

   For example: "shell", "tty-server", "connection", "system" and
   "firewall".  This attribute MUST always be included.

Is this a full list or is there a registry?

Later in the same section:

   remote_host (String)

What is the syntax of this field?

10.4.  Security of Accounting Sessions

      Replace accounting data with new valid or garbage which prevents
      to provide distraction

"prevents to provide distraction" doesn't read well.

      or hide information related to their
      authentication and/or authorization attack attempts.

In 10.5.1:

   TACACS+ server administrators SHOULD change secret keys at regular
   intervals.

Humans are very bad at this. So I think it would be better if this is changed
to add a requirement on management UIs.

10.5.3.  Authentication

   To help TACACS+ administraots select the stronger authentication

Typo: administrators.