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

From: "Douglas Gash (dcmgash)" <[email-masked]>
Date: Sat, 22 Jun 2019 06:03:13 +0000

Many thanks for the comments.

Please see responses from authors inline, marked “TA”. Action items from this mail to update the document are marked: [AI-TA] to mean: “action item for the authors”.

On 15/05/2019, 19:03, "Mirja Kühlewind via Datatracker" <[email-masked]> wrote:

    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…?

TA>  Agreed, will update as advised  [AI-TA]
    
    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.

TA> Yes, that is certainly a possible scenario. I believe it will likely be caught by regular timeout mechanisms in the implementation, but  we  can  call it out explicitly  [AI-TA]
    
    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).

TA>Agreed, will add a definition of session as advised [AI-TA]
    
    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./

TA> Agreed that section can be tidied and the clause you highlight normatized. [AI-TA]
    
    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.

TA> It is certainly a valid point. If there is consensus, then I agreed it would make sense to be clear and say  that unencrypted mode MUST NOT be used.
    
    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…
    
TA> Agreed  [AI-TA]