[OPSAWG] Barry Leiba's Discuss on draft-ietf-opsawg-tacacs-13: (with DISCUSS)

[Barry Leiba via Datatracker <[e-mail]>]

Barry Leiba 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 support the DISCUSS ballots by Alexey and Roman, as well as the comments by
Deborah and Alissa that more text be in the introduction about the status and
limitations here.

I also need to add to Alexey’s DISCUSS on 4.6, Text Encoding:

   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.

This is a mine field.  Treating passwords as raw octets without concern for
encoding and normalization can cause authentication failures and can be used to
attack systems where non-ASCII passwords are in use.

Suppose I enter “crème brûlée” as my password. How that’s represented in UTF-8
depends upon my input device, as there are at least two valid representations
of each accented vowel.  Without normalization/canonicalization, passwords
entered on different input devices might not match, blocking my access.  And we
haven’t touched on bidirectional issues (mixing, say, Hebrew and English
characters).

The precis framework has detailed explanations of how to deal with usernames
and passwords — see RFC 8265 (and, for the overall precis framework, RFC 8264).

   The encoding SHOULD be UTF-8, and other
   encodings outside printable US-ASCII SHOULD be deprecated.”

This doesn’t make sense with respect to how we use “deprecated”.  You need to
say “are deprecated”, meaning that we recommend against using them.  There’s no
BCP 14 “SHOULD” involved here.