Hi, thanks for the feedback, the authors have already started looking into it and we get back to you ASAP.
Thanks, Thorsten Am Sa., 25. Okt. 2025 um 02:01 Uhr schrieb <[email protected]>: > Authors, > > While reviewing this document during AUTH48, please resolve (as necessary) > the following questions, which are also in the source file. > > 1) <!-- [rfced] May we update this text for readability? > > Original: > While the content of the protocol is highly sensitive, TACACS+ lacks > effective confidentiality, integrity, and authentication of the > connection and network traffic between the TACACS+ server and client, > requiring secure transport to safeguard a deployment. The security > mechanisms as described in Section 10 of [RFC8907] are extremely > weak. > > Suggested: > The content of the protocol is highly sensitive and requires > secure transport to safeguard a deployment. However, TACACS+ lacks > effective confidentiality, integrity, and authentication of the > connection and network traffic between the TACACS+ server and client. > The security mechanisms as described in Section 10 of [RFC8907] are > extremely weak. > --> > > > 2) <!-- [rfced] Should "for test" be "for testing"? > > Original: > It is a connection without TLS, using the unsecure > TACACS+ authentication and obfuscation (or the unobfuscated option > for test). > --> > > > 3) <!-- [rfced] We recommend simplifying this sentence for clarity. Does > the connection persist until either a) the TLS TACACS+ peer closes it or > b) > an inactivity timeout occurs? Please consider how the text may be > updated. > > Original: > The connection persists until the TLS TACACS+ peer closes it, either > due to an error, or at the conclusion of the TACACS+ session, or, if > Single Connection Mode (Section 4.3 of [RFC8907]) has been > negotiated, when an inactivity timeout occurs. > > Perhaps: > The connection persists until the TLS TACACS+ peer closes it or > until an inactivity timeout occurs when Single Connection Mode > (Section 4.3 of [RFC8907]) is used. The TLS TACACS+ peer may close > the connection due to an error or because the TACACS+ session has > concluded. > --> > > > 4) <!-- [rfced] "verification" does not appear in Section 6 of RFC 5280. > Would it be helpful to the reader to use "validation" for consistency with > the reference? > > Original: > The implementation of certificate-based mutual authentication MUST > support certificate path verification as described in Section 6 of > [RFC5280]. > --> > > > 5) <!-- [rfced] Is it correct to refer to the "TLS Resumption protocol"? > > Original: > The TLS Resumption protocol, detailed in [RFC8446], can minimize the > number of round trips required during the handshake process. > > Perhaps: > TLS Resumption [RFC8446] can minimize the > number of round trips required during the handshake process. > --> > > > 6) <!-- [rfced] Section 5.2 of [RFC5425] is titled "Subject Name > Authorization" and doesn't appear to mention any kind of obfuscation > mechanism. Also, is the obfuscation mechanism described in both RFC 8907 > and 5425 (or other)? Please review and let us know how/if the text may > be > clarified. > > Original: > [RFC8907] describes the obfuscation mechanism, documented in Section > 5.2 of [RFC5425]. Such a method is weak. > > > --> > > > 7) <!-- [rfced] We are having trouble parsing "for implementing protocols > that use TLS and their deployment." > > Original: > [BCP195] offers substantial guidance for implementing protocols that > use TLS and their deployment. > > Perhaps: > [BCP195] offers substantial guidance for implementing and deploying > protocols that use TLS. > --> > > > 8) <!-- [rfced] The use of "MUST" twice in this sentence reads oddly. > Please review. > > Original: > Further, operators MUST ensure that the TLS TACACS+ servers covered > by a wildcard certificate MUST be impervious to redirection of > traffic to a different server (for example, due to on-path attacks or > DNS cache poisoning). > > Perhaps A: > Further, operators MUST ensure that the TLS TACACS+ servers covered > by a wildcard certificate are impervious to redirection of > traffic to a different server (for example, due to on-path attacks or > DNS cache poisoning). > > > Perhaps B: > Further, operators MUST ensure that the TLS TACACS+ servers are covered > by a wildcard certificate and MUST be impervious to redirection of > traffic to a different server (for example, due to on-path attacks or > DNS cache poisoning). > --> > > > 9) <!-- [rfced] Does the operator need to consider the impact of > supporting > both TLS and non-TLS connections? > > Original: > * The operator must consider the impact of mixed TLS and Non-TLS on > security, as mentioned above. > > Perhaps: > * The operator must consider the security impact of supporting both > TLS > and non-TLS connections, as mentioned above. > --> > > > 10) <!-- [rfced] The description of the service name in the first > paragraph > differs from the what appears in the registration template below it and > what appears on the IANA site. Is the intent to relay that the service > name "tacacss" is commonly referred to as "TACACS+ over TLS" rather than > the description in the template? Or, should the descriptions be the > same? > > Original: > IANA has allocated a new well-known system TCP/IP port number (300) > for the service name "tacacss", described as "TACACS+ over TLS". The > service name "tacacss" follows the common practice of appending an > "s" to the name given to the Non-TLS well- known port name. This > allocation is justified in Section 5.3. > > IANA has added tacacss as a new entry to the "Service name and > Transport Protocol Port Number Registry" available at > <https://www.iana.org/assignments/service-names-port-numbers>. > > Description in the template and the IANA registry: > TLS Secure Login Host Protocol (TACACSS) > See < > https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?=&skey=2&page=6>. > > > If the text should be the same, perhaps the paragraphs could be combined > as > follows: > IANA has allocated the following new well-known system in the > "Service Name and Transport Protocol Port Number Registry" (see > <https://www.iana.org/assignments/service-names-port-numbers/>). The > service name "tacacss" follows the common practice of appending an > "s" to the name given to the non-TLS well-known port name. See the > justification for the allocation in Section 5.3. > > Related: > Original in Section 3.1: > Given the prevalence of default port usage in existing TACACS+ client > implementations, this specification assigns a well-known TCP port > number for TACACS+ over TLS: [TBD] (Section 7), with the associated > service name "tacacss" Section 7. > > Perhaps: > Given the prevalence of default port usage in existing TACACS+ client > implementations, this specification assigns well-known TCP port > 300 for TACACS+ over TLS (see Section 7). > > Original in Section 3.1 - We believe this is intentional to align with the > line prior: > * for Non-TLS connection TACACS+: Port number 49. > * for TLS connection TACACS+: (TBD). > --> > > > 11) <!-- [rfced] This document used both "non-TLS" and "Non-TLS". We have > lowercased instances of "Non-TLS" for consistency and because > overcapitalization can detract from readability. > --> > > > Thank you. > Sandy Ginoza > RFC Production Center > > > On Oct 24, 2025, at 5:59 PM, [email protected] wrote: > > *****IMPORTANT***** > > Updated 2025/10/24 > > RFC Author(s): > -------------- > > Instructions for Completing AUTH48 > > Your document has now entered AUTH48. Once it has been reviewed and > approved by you and all coauthors, it will be published as an RFC. > If an author is no longer available, there are several remedies > available as listed in the FAQ (https://www.rfc-editor.org/faq/). > > You and you coauthors are responsible for engaging other parties > (e.g., Contributors or Working Group) as necessary before providing > your approval. > > Planning your review > --------------------- > > Please review the following aspects of your document: > > * RFC Editor questions > > Please review and resolve any questions raised by the RFC Editor > that have been included in the XML file as comments marked as > follows: > > <!-- [rfced] ... --> > > These questions will also be sent in a subsequent email. > > * Changes submitted by coauthors > > Please ensure that you review any changes submitted by your > coauthors. We assume that if you do not speak up that you > agree to changes submitted by your coauthors. > > * Content > > Please review the full content of the document, as this cannot > change once the RFC is published. Please pay particular attention to: > - IANA considerations updates (if applicable) > - contact information > - references > > * Copyright notices and legends > > Please review the copyright notice and legends as defined in > RFC 5378 and the Trust Legal Provisions > (TLP – https://trustee.ietf.org/license-info). > > * Semantic markup > > Please review the markup in the XML file to ensure that elements of > content are correctly tagged. For example, ensure that <sourcecode> > and <artwork> are set correctly. See details at > <https://authors.ietf.org/rfcxml-vocabulary>. > > * Formatted output > > Please review the PDF, HTML, and TXT files to ensure that the > formatted output, as generated from the markup in the XML file, is > reasonable. Please note that the TXT will have formatting > limitations compared to the PDF and HTML. > > > Submitting changes > ------------------ > > To submit changes, please reply to this email using ‘REPLY ALL’ as all > the parties CCed on this message need to see your changes. The parties > include: > > * your coauthors > > * [email protected] (the RPC team) > > * other document participants, depending on the stream (e.g., > IETF Stream participants are your working group chairs, the > responsible ADs, and the document shepherd). > > * [email protected], which is a new archival mailing list > to preserve AUTH48 conversations; it is not an active discussion > list: > > * More info: > > https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc > > * The archive itself: > https://mailarchive.ietf.org/arch/browse/auth48archive/ > > * Note: If only absolutely necessary, you may temporarily opt out > of the archiving of messages (e.g., to discuss a sensitive matter). > If needed, please add a note at the top of the message that you > have dropped the address. When the discussion is concluded, > [email protected] will be re-added to the CC list and > its addition will be noted at the top of the message. > > You may submit your changes in one of two ways: > > An update to the provided XML file > — OR — > An explicit list of changes in this format > > Section # (or indicate Global) > > OLD: > old text > > NEW: > new text > > You do not need to reply with both an updated XML file and an explicit > list of changes, as either form is sufficient. > > We will ask a stream manager to review and approve any changes that seem > beyond editorial in nature, e.g., addition of new text, deletion of text, > and technical changes. Information about stream managers can be found in > the FAQ. Editorial changes do not require approval from a stream manager. > > > Approving for publication > -------------------------- > > To approve your RFC for publication, please reply to this email stating > that you approve this RFC for publication. Please use ‘REPLY ALL’, > as all the parties CCed on this message need to see your approval. > > > Files > ----- > > The files are available here: > https://www.rfc-editor.org/authors/rfc9887.xml > https://www.rfc-editor.org/authors/rfc9887.html > https://www.rfc-editor.org/authors/rfc9887.pdf > https://www.rfc-editor.org/authors/rfc9887.txt > > Diff file of the text: > https://www.rfc-editor.org/authors/rfc9887-diff.html > https://www.rfc-editor.org/authors/rfc9887-rfcdiff.html (side by side) > > Diff of the XML: > https://www.rfc-editor.org/authors/rfc9887-xmldiff1.html > > > Tracking progress > ----------------- > > The details of the AUTH48 status of your document are here: > https://www.rfc-editor.org/auth48/rfc9887 > > Please let us know if you have any questions. > > Thank you for your cooperation, > > RFC Editor > > -------------------------------------- > RFC9887 (draft-ietf-opsawg-tacacs-tls13-24) > > Title : Terminal Access Controller Access-Control System Plus > over TLS 1.3 (TACACS+ over TLS) > Author(s) : T. Dahm, J. Heasley, D. C. Medway Gash, A. Ota > WG Chair(s) : Joe Clarke, Benoît Claise > > Area Director(s) : Mohamed Boucadair, Mahesh Jethanandani > > > -- Gruß, Thorsten Dahm
-- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
