Hi Thorsten, Thank you for your review. We have noted your approval on the AUTH48 page <https://www.rfc-editor.org/auth48/rfc9887>.
Thank you, Sandy Ginoza RFC Production Center > On Nov 13, 2025, at 2:51 PM, Thorsten Dahm <[email protected]> wrote: > > Thanks Sandy, approved by me as well. > > cheers, > Thorsten > > Am Do., 13. Nov. 2025 um 18:40 Uhr schrieb Sandy Ginoza > <[email protected]>: > 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. > > > > > -- > Gruß, > Thorsten Dahm -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
