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 protected]> 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] _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
