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

From: "Douglas Gash (dcmgash)" <[email-masked]>
Date: Wed, 26 Jun 2019 04:33:49 +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 16/05/2019, 6:10, "Barry Leiba via Datatracker" <[email-masked]> wrote:

    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).
    
TA> Thanks, we will take advantage of this work to help clarify the charset issues.  [AI-TA]

       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.

TA Agreed, will resolve [AI-TA]