[OPSAWG] Mirja Kühlewind's No Objection on draft-ietf-opsawg-tacacs-13: (with COMMENT)

[Mirja Kühlewind via Datatracker <[e-mail]>]

Mirja Kühlewind has entered the following ballot position for
draft-ietf-opsawg-tacacs-13: No Objection

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/



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

A couple of comments/question:

1) I would like to see it more explicitly mentioned in the title, abstract, and
introduction that this is only documenting the protocol as deployed today.
Usually we use titles like “Company X’s TACACS+ protocol”; this is probably not
applicable here but maybe something like “Documentation of the TACACS+
Protocol” would work as well…?

2) If Single Connection Mode is used and the connection is idle for a while, it
can be possible that some middlebox or the server lost state and the connection
is actually not available anymore. I guess it could be good to explicit mention
this case and say something like if a RST or timeout is encountered for a
connection in Single Connection Mode, the client should try to open a new
connection and resend the request immediately.

3) I would recommend to define the term “session” in section 3 (as it seems to
a central term that is important to understand correctly).

4) Sec 10.5.1: “TACACS+ servers MUST NOT leak sensitive data.”
Not sure if that is an actionable requirement, as I would assume leaking is
often done by accident. Maybe “TACACS+ servers MUST store sensitive data
securely.”… or something…? Not sure  how much better that is… Actually the next
sentence could probably be normative: S/TACACS+ servers should not expose
shared secrets in logs./TACACS+ servers MUST NOT expose shared secrets in logs./

5) One question regarding the unencrypted/non-obfuscated mode: Why was this
mode (and TAC_PLUS_UNENCRYPTED_FLAG=1) not deprecated completely? You mention
briefly somewhere that this is/was used for debugging but then later say that
modern tools should also support debugging of obfuscated traffic.

6) Sec 10.5.5: “TACACS+ servers SHOULD deprecate the redirection mechanism.”
I believe you want to use a MUST here because you anyway only specify this for
servers that follow or update to this spec; it will of course not change
existing implementations…