Hi Douglas, Thank you for your review and for raising this question - I think I misunderstood the requested update. I thought there were 2 separate sentences, but I now understand “Data Obfuscation” refers to the section title. We have updated the document as described below.
>> 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. >> >> > --> > <Authors> > We propose: > The obfuscation mechanism documented in [RFC8907] section 4.5. Data > Obfuscation is weak > </Authors> Current: The obfuscation mechanism documented in Section 4.5 (Data Obfuscation) of [RFC8907] is weak. Please let us know if this conveys the intended meaning. Thank you! Sandy Ginoza RFC Production Center > On Nov 12, 2025, at 10:50 PM, Douglas Gash (dcmgash) <[email protected]> > wrote: > > Thanks Sandy, > All looks good for me, though I had one query. I think the sense of this > change: > The obfuscation mechanism, mechanism is documented in Section 5.2 4.5 of > [RFC5425]. Such a method [RFC8907]. > Data Obfuscation is weak. weak > From the original has changed the meaning from, “the obfuscation in T+ is > weak” to “all obfuscation is weak”. The obfuscation in T+ is weak because it > set out to be encryption. It may be for some other application, Data > obfuscation is absolutely fine, because it is not trying to be encryption, > our text has now become universal across existence 😉 Is that the intent? > From: Sandy Ginoza <[email protected]> > Date: Wednesday, 12 November 2025 at 21:09 > To: [email protected] <[email protected]> > Cc: Douglas Gash (dcmgash) <[email protected]>, Thorsten Dahm > <[email protected]>, RFC Editor <[email protected]>, > [email protected] <[email protected]>, [email protected] <[email protected]>, > [email protected] <[email protected]>, [email protected] > <[email protected]>, Joe Clarke (jclarke) <[email protected]>, > [email protected] <[email protected]> > Subject: Re: [AD - Med] AUTH48: RFC-to-be 9887 > <draft-ietf-opsawg-tacacs-tls13-24> for your review > Hi Med and Authors, > > Med, thank you for your review. We have updated the document and noted your > approval on the AUTH48 page. > > Authors, we updated the document as noted below. For the typos, we opted for > the NEW text. Authors, please let us know if you prefer NEW2. > > The current files are here: > https://www.rfc-editor.org/authors/rfc9887.xml > https://www.rfc-editor.org/authors/rfc9887.txt > https://www.rfc-editor.org/authors/rfc9887.pdf > https://www.rfc-editor.org/authors/rfc9887.html > > AUTH48 diffs (includes earlier updates and the updates Med requested below): > https://www.rfc-editor.org/authors/rfc9887-auth48diff.html > https://www.rfc-editor.org/authors/rfc9887-auth48rfcdiff.html (side by > side) > > Comprehensive diffs: > https://www.rfc-editor.org/authors/rfc9887-diff.html > https://www.rfc-editor.org/authors/rfc9887-rfcdiff.html (side by side) > > > Please let us know if any further updates are needed or if you approve the > RFC for publication. > > Thank you, > Sandy Ginoza > RFC Production Center > > > > > On Nov 12, 2025, at 11:42 AM, [email protected] wrote: > > > > Hi Sandy, all, > > > > I would reword 3.1: > > > > OLD: > > 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). > > > > NEW: > > > > Given the prevalence of default port usage in existing TACACS+ client > > implementations, this specification assigns the well-known TCP port > > number 300 > > ^^^^ ^^^^^^ > > for TACACS+ over TLS (see Section 7). > > > > And fix some typos in 3.2: > > > > OLD: > > TLS TACACS+ connections are generally not long-lived. The connection > > will be closed by either a TLS+ TACACS Peer if it encounters an error > > or an inactivity timeout. > > > > NEW: > > TLS TACACS+ connections are generally not long-lived. The connection > > will be closed by either a TLS TACACS+ peer if it encounters an error > > or an inactivity timeout. > > > > Or simply the following to be consistent with the definition of "peer" in > > Section 2: > > > > NEW2: > > TLS TACACS+ connections are generally not long-lived. The connection > > will be closed by either a peer if it encounters an error > > or an inactivity timeout. > > > > Other than that, I approve the changes. > > > > Thank you. > > > > Cheers, > > Med > > > >> -----Message d'origine----- > >> De : Sandy Ginoza <[email protected]> > >> Envoyé : mercredi 12 novembre 2025 20:05 > >> À : Douglas Gash (dcmgash) <[email protected]> > >> Cc : Thorsten Dahm <[email protected]>; RFC Editor <rfc- > >> [email protected]>; [email protected]; [email protected]; opsawg- > >> [email protected]; [email protected]; Joe Clarke (jclarke) > >> <[email protected]>; BOUCADAIR Mohamed INNOV/NET > >> <[email protected]>; [email protected] > >> Objet : [AD - Med] Re: AUTH48: RFC-to-be 9887 <draft-ietf-opsawg- > >> tacacs-tls13-24> for your review > >> > >> > >> Greetings Authors, Med*, > >> > >> We have updated the document as discussed thus far (including > >> using "Certificate Authority”). > >> > >> *Med, as AD, please review the changes in sections 3.1, 3.2, and > >> 5.1.6 and let us know if they are approved. The updates can most > >> easily be viewed in one of the AUTH48 diffs: > >> > >> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > >> www.rfc-editor.org%2Fauthors%2Frfc9887- > >> auth48diff.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Ce3 > >> b653038a514bef2b9e08de221eb7d1%7C90c7a20af34b40bfbc48b9253b6f5d20% > >> 7C0%7C0%7C638985712528875984%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hc > >> GkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIld > >> UIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=n9Q8KQSu5ORLQ2vLb4TSpRSrPAcIozDxG > >> yMBAr%2BOLoc%3D&reserved=0 > >> > >> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > >> www.rfc-editor.org%2Fauthors%2Frfc9887- > >> auth48rfcdiff.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7 > >> Ce3b653038a514bef2b9e08de221eb7d1%7C90c7a20af34b40bfbc48b9253b6f5d > >> 20%7C0%7C0%7C638985712528904029%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU > >> 1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIs > >> IldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=1gSvXqkzt3WSkl7hL2qg6i30P9KkJG > >> e%2F1AJ%2BCY3ZFBY%3D&reserved=0 (side by side) > >> > >> > >> The fully updated files are available here: > >> > >> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > >> www.rfc- > >> editor.org%2Fauthors%2Frfc9887.xml&data=05%7C02%7Cmohamed.boucadai > >> r%40orange.com%7Ce3b653038a514bef2b9e08de221eb7d1%7C90c7a20af34b40 > >> bfbc48b9253b6f5d20%7C0%7C0%7C638985712528921743%7CUnknown%7CTWFpbG > >> Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs > >> IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=VMEH610ARIMOoi > >> e1Mew7vnTyeskpp2dndfJQ%2FHTV2mA%3D&reserved=0 > >> > >> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > >> www.rfc- > >> editor.org%2Fauthors%2Frfc9887.txt&data=05%7C02%7Cmohamed.boucadai > >> r%40orange.com%7Ce3b653038a514bef2b9e08de221eb7d1%7C90c7a20af34b40 > >> bfbc48b9253b6f5d20%7C0%7C0%7C638985712528940954%7CUnknown%7CTWFpbG > >> Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs > >> IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=5ufs5ScgGtl3Ih > >> F5QVMy0M9r7mCOOntASyChaBt1ntA%3D&reserved=0 > >> > >> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > >> www.rfc- > >> editor.org%2Fauthors%2Frfc9887.pdf&data=05%7C02%7Cmohamed.boucadai > >> r%40orange.com%7Ce3b653038a514bef2b9e08de221eb7d1%7C90c7a20af34b40 > >> bfbc48b9253b6f5d20%7C0%7C0%7C638985712528958954%7CUnknown%7CTWFpbG > >> Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs > >> IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=RwnA9ZPfdWjkkq > >> C3veYeHzsosm0gwyVEo7ERH2HGr0w%3D&reserved=0 > >> > >> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > >> www.rfc- > >> editor.org%2Fauthors%2Frfc9887.html&data=05%7C02%7Cmohamed.boucada > >> ir%40orange.com%7Ce3b653038a514bef2b9e08de221eb7d1%7C90c7a20af34b4 > >> 0bfbc48b9253b6f5d20%7C0%7C0%7C638985712528975143%7CUnknown%7CTWFpb > >> GZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiI > >> sIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=lQpi3%2BDp9nb > >> xJqk5Kq9zQBo8v%2BcVFzC%2FrP8kAaVOLpw%3D&reserved=0 > >> > >> Comprehensive diffs are available here: > >> > >> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > >> www.rfc-editor.org%2Fauthors%2Frfc9887- > >> diff.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Ce3b65303 > >> 8a514bef2b9e08de221eb7d1%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C > >> 0%7C638985712528990904%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnR > >> ydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyf > >> Q%3D%3D%7C0%7C%7C%7C&sdata=3geG5DoNpZIGqTwFuUQC7cHQ0TebV5EnBESa7QU > >> tFkA%3D&reserved=0 > >> > >> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > >> www.rfc-editor.org%2Fauthors%2Frfc9887- > >> rfcdiff.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Ce3b65 > >> 3038a514bef2b9e08de221eb7d1%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0 > >> %7C0%7C638985712529007450%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGki > >> OnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIj > >> oyfQ%3D%3D%7C0%7C%7C%7C&sdata=it3%2FZDDhkHnMMdz1I%2FQGn%2FBATOTQhP > >> fzKapSnDRMbaA%3D&reserved=0 (side by side) > >> > >> > >> All, please review and let us know if any additional updates are > >> needed or if you approve the RFC for publication. > >> > >> Thank you, > >> Sandy Ginoza > >> RFC Production Center > >> > >> > >> > >>> On Nov 9, 2025, at 12:46 PM, Douglas Gash (dcmgash) > >> <[email protected]> wrote: > >>> > >>> Many thanks for the work to unentangle the document! > >>> Please see our initial responses: > >>> 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. > >>> --> > >>> > >>> <Authors>Thanks, that makes sense</Authors> > >>> > >>> > >>> 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). > >>> --> > >>> <Authors>Thanks, that makes sense</Authors> > >>> > >>> > >>> > >>> 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. > >>> --> > >>> > >>> <Authors>Having reviewed this change, and the relation to next > >> paragraph, we’d like to propose the following which replaces the > >> Original quoted above, and the next paragraph in the document: > >>> TLS TACACS+ connections are generally not long-lived. The > >> connection > >>> will be closed by either TLS+ TACACS Peer if it encounters an > >> error or > >>> inactivity timeout. For connections not operating in Single > >> Connection Mode (as defined in > >>> Section 4.3 of [RFC8907]) the TCP session SHALL be closed upon > >>> completion of the associated TACACS+ session. Connections > >> operating > >>> in Single Connection Mode MAY persist for a longer duration but > >> are > >>> typically subject to timeout and closure after a brief period of > >> inactivity. > >>> Consequently, support for transport-layer keepalive mechanisms > >> is not > >>> required. > >>> > >>> Why a connection is closed has no bearing on TLS resumption, > >> unless > >>> closed by a TLS error, in which case it is possible that the > >> ticket has been invalidated. > >>> </Authors> > >>> > >>> > >>> 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]. > >>> --> > >>> > >>> <Authors>Thanks, that makes sense</Authors> > >>> > >>> > >>> 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. > >>> --> > >>> > >>> <Authors>Thanks, that makes sense</Authors> > >>> > >>> > >>> 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. > >>> > >>> > >>> --> > >>> <Authors> > >>> We propose: > >>> The obfuscation mechanism documented in [RFC8907] section 4.5. > >> Data > >>> Obfuscation is weak </Authors> > >>> > >>> > >>> > >>> 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. > >>> --> > >>> <Authors>Thanks, that makes sense</Authors> > >>> > >>> > >>> 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). > >>> --> > >>> > >>> <Authors>Thanks, Authors have voted for option A</Authors> > >>> > >>> > >>> 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. > >>> --> > >>> > >>> <Authors>Thanks, that makes sense</Authors> > >>> > >>> > >>> 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 > >> Fwww.iana.org%2Fassignments%2Fservice-names-port- > >> numbers&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Ce3b653038a > >> 514bef2b9e08de221eb7d1%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0% > >> 7C638985712529021870%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRyd > >> WUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ% > >> 3D%3D%7C0%7C%7C%7C&sdata=IrZUb96oVZKfcsTwK3gf8DLoB8fzZrIWx0PHhq7kN > >> Ik%3D&reserved=0>. > >>> > >>> Description in the template and the IANA registry: > >>> TLS Secure Login Host Protocol (TACACSS) See > >>> > >> <https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 > >> Fwww.iana.org%2Fassignments%2Fservice-names-port- > >> numbers%2Fservice-names-port- > >> numbers.xhtml%3F%3D%26skey%3D2%26page%3D6&data=05%7C02%7Cmohamed.b > >> oucadair%40orange.com%7Ce3b653038a514bef2b9e08de221eb7d1%7C90c7a20 > >> af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638985712529036571%7CUnknown%7 > >> CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXa > >> W4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=kHnvTn2 > >> 8iTaatvwupOsJtDvgltFN8ka%2BJcUt4Tulw%2FY%3D&reserved=0>. > >>> > >>> 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 > >> Fwww.iana.org%2Fassignments%2Fservice-names-port- > >> numbers%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Ce3b6530 > >> 38a514bef2b9e08de221eb7d1%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7 > >> C0%7C638985712529052794%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOn > >> RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoy > >> fQ%3D%3D%7C0%7C%7C%7C&sdata=FCXIFhF3drMSNs%2Bhnw6HSXrrn3WV5leFDYbr > >> c2qzRGo%3D&reserved=0>). 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). > >>> --> > >>> > >>> <Authors>Thanks, that makes sense</Authors> > >>> > >>> > >>> 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. > >>> --> > >>> > >>> <Authors>Thanks, that makes sense</Authors> > >>> > >>> > >>> Thank you. > >>> Sandy Ginoza > >>> RFC Production Center > >>> > >>> > >>> > >>> Cisco Confidential > >>> 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 > >> Fwww.rfc- > >> editor.org%2Ffaq%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com% > >> 7Ce3b653038a514bef2b9e08de221eb7d1%7C90c7a20af34b40bfbc48b9253b6f5 > >> d20%7C0%7C0%7C638985712529068274%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0e > >> U1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCI > >> sIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=j2KHnAW%2FkiZ2Wc8sqWy9nWYb9CN > >> U5zvKycJjUxyf7ds%3D&reserved=0). > >>> > >>> 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > >> trustee.ietf.org%2Flicense- > >> info&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Ce3b653038a514 > >> bef2b9e08de221eb7d1%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6 > >> 38985712529084885%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUs > >> IlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D% > >> 3D%7C0%7C%7C%7C&sdata=MnGFs9d7lZjGZEw5UmcewtNSuIeydceWEkT2pK8pEw8% > >> 3D&reserved=0). > >>> > >>> * 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 > >> Fauthors.ietf.org%2Frfcxml- > >> vocabulary&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Ce3b6530 > >> 38a514bef2b9e08de221eb7d1%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7 > >> C0%7C638985712529101497%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOn > >> RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoy > >> fQ%3D%3D%7C0%7C%7C%7C&sdata=RYT5U68nmXFjOBk6qSAernb4KPYfsPN4OYMJ2i > >> BwztE%3D&reserved=0>. > >>> > >>> * 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > >> mail > >>> archive.ietf.org%2Farch%2Fmsg%2Fietf-announce%2Fyb6lpIGh- > >> 4Q9l2USxIAe6P > >>> > >> 8O4Zc&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Ce3b653038a51 > >> 4bef > >>> > >> 2b9e08de221eb7d1%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6389 > >> 8571 > >>> > >> 2529118570%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiI > >> wLjA > >>> > >> uMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7 > >> C%7C > >>> > >> &sdata=pUVLs80YAAIh0Z%2BcNfCoRwjMBN1srrHHeOKShHCHLPo%3D&reserved=0 > >>> > >>> * The archive itself: > >>> > >>> > >> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > >> mail > >>> > >> archive.ietf.org%2Farch%2Fbrowse%2Fauth48archive%2F&data=05%7C02%7 > >> Cmoh > >>> > >> amed.boucadair%40orange.com%7Ce3b653038a514bef2b9e08de221eb7d1%7C9 > >> 0c7a > >>> > >> 20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638985712529134213%7CUnknown > >> %7CT > >>> > >> WFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4 > >> zMiI > >>> > >> sIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=1jl6vwKxNXyZU > >> P67H > >>> zToknUXJoVAy41qzwYB6jdpqLI%3D&reserved=0 > >>> > >>> * 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > >> www.rfc- > >> editor.org%2Fauthors%2Frfc9887.xml&data=05%7C02%7Cmohamed.boucadai > >> r%40orange.com%7Ce3b653038a514bef2b9e08de221eb7d1%7C90c7a20af34b40 > >> bfbc48b9253b6f5d20%7C0%7C0%7C638985712529149944%7CUnknown%7CTWFpbG > >> Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs > >> IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=M3WrUV1PcF5dd4 > >> cYsXxb84eUjx5f78%2FwLnIOTZceWvQ%3D&reserved=0 > >>> > >> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > >> www.rfc- > >> editor.org%2Fauthors%2Frfc9887.html&data=05%7C02%7Cmohamed.boucada > >> ir%40orange.com%7Ce3b653038a514bef2b9e08de221eb7d1%7C90c7a20af34b4 > >> 0bfbc48b9253b6f5d20%7C0%7C0%7C638985712529347863%7CUnknown%7CTWFpb > >> GZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiI > >> sIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=3D4HYnhdn8cAE > >> lhP5fIGS7Sm%2FSlwVA8JDugpmznddG8%3D&reserved=0 > >>> > >> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > >> www.rfc- > >> editor.org%2Fauthors%2Frfc9887.pdf&data=05%7C02%7Cmohamed.boucadai > >> r%40orange.com%7Ce3b653038a514bef2b9e08de221eb7d1%7C90c7a20af34b40 > >> bfbc48b9253b6f5d20%7C0%7C0%7C638985712529364761%7CUnknown%7CTWFpbG > >> Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs > >> IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Ppce%2BUdysTx0 > >> %2FQkJt3BQj46IWs6ppEnvv2cgvvlfbk4%3D&reserved=0 > >>> > >>> > >> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > >> www. > >>> rfc- > >> editor.org%2Fauthors%2Frfc9887.txt&data=05%7C02%7Cmohamed.boucadai > >>> > >> r%40orange.com%7Ce3b653038a514bef2b9e08de221eb7d1%7C90c7a20af34b40 > >> bfbc > >>> > >> 48b9253b6f5d20%7C0%7C0%7C638985712529379848%7CUnknown%7CTWFpbGZsb3 > >> d8ey > >>> > >> JFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoi > >> TWFp > >>> > >> bCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=8XoLHLWji2zaVQvu%2FkFnDXFI > >> H6Fg > >>> Eyq8h9puYCc7LtU%3D&reserved=0 > >>> > >>> Diff file of the text: > >>> > >> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > >> www.rfc-editor.org%2Fauthors%2Frfc9887- > >> diff.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Ce3b65303 > >> 8a514bef2b9e08de221eb7d1%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C > >> 0%7C638985712529393617%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnR > >> ydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyf > >> Q%3D%3D%7C0%7C%7C%7C&sdata=s%2FVMKvELSiCTPvnLEvStFgI4TqnoJYazvuU2Z > >> zV%2BZtw%3D&reserved=0 > >>> > >>> > >> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > >> www. > >>> rfc-editor.org%2Fauthors%2Frfc9887- > >> rfcdiff.html&data=05%7C02%7Cmohamed > >>> > >> .boucadair%40orange.com%7Ce3b653038a514bef2b9e08de221eb7d1%7C90c7a > >> 20af > >>> > >> 34b40bfbc48b9253b6f5d20%7C0%7C0%7C638985712529411532%7CUnknown%7CT > >> WFpb > >>> > >> GZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiI > >> sIkF > >>> > >> OIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=jUNLnN2gLvKku0gqc > >> h6GV > >>> im0XIYqmSNsV%2F6ADm5uhbY%3D&reserved=0 (side by side) > >>> > >>> Diff of the XML: > >>> > >>> > >> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > >> www. > >>> rfc-editor.org%2Fauthors%2Frfc9887- > >> xmldiff1.html&data=05%7C02%7Cmohame > >>> > >> d.boucadair%40orange.com%7Ce3b653038a514bef2b9e08de221eb7d1%7C90c7 > >> a20a > >>> > >> f34b40bfbc48b9253b6f5d20%7C0%7C0%7C638985712529428268%7CUnknown%7C > >> TWFp > >>> > >> bGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMi > >> IsIk > >>> > >> FOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=CGmulrA9NSUfbZOp > >> 7b3r > >>> b4Z8VxD%2FU%2BdkSQSNgNm44Tk%3D&reserved=0 > >>> > >>> > >>> Tracking progress > >>> ----------------- > >>> > >>> The details of the AUTH48 status of your document are here: > >>> > >>> > >> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > >> www. > >>> rfc- > >> editor.org%2Fauth48%2Frfc9887&data=05%7C02%7Cmohamed.boucadair%40o > >>> > >> range.com%7Ce3b653038a514bef2b9e08de221eb7d1%7C90c7a20af34b40bfbc4 > >> 8b92 > >>> > >> 53b6f5d20%7C0%7C0%7C638985712529444453%7CUnknown%7CTWFpbGZsb3d8eyJ > >> FbXB > >>> > >> 0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpb > >> CIsI > >>> > >> ldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=7nBle%2BJ5TdIRTs9kvIUNyd3MK%2Be > >> hzGV > >>> 6Ad9g5FdVoX8%3D&reserved=0 > >>> > >>> 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 > >> > > > > ____________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > > confidentielles ou privilegiees et ne doivent donc > > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu > > ce message par erreur, veuillez le signaler > > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > > electroniques etant susceptibles d'alteration, > > Orange decline toute responsabilite si ce message a ete altere, deforme ou > > falsifie. Merci. > > > > This message and its attachments may contain confidential or privileged > > information that may be protected by law; > > they should not be distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender and > > delete this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have been > > modified, changed or falsified. > > Thank you. -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
