I share Ketan's belief that the tacacs+ protocol should be Standards Track. Now that the security issues have been resolved, then why not publish a Standards Track RFC that documents the protocol. It would be easier for developers/implementers and probably operators as the information on this widely used protocol would be in one place.
Deb p.s. just because RFC 8907 has been used as a downref, does not imply that it is in the downref registry. On Wed, Jun 25, 2025 at 11:06 PM <[email protected]> wrote: > Hi Ketan, > > > > Thanks for digging into this and for clearing. > > > > The PS justification for this extension (see more details in the writeup) > is strong enough to not revisit it. It is true that 8907 will be a downref, > but that one should already be in the downref registry as it was already > normatively cited by other RFC. > > > > Cheers, > > Med > > > > *De :* Ketan Talaulikar <[email protected]> > *Envoyé :* mercredi 25 juin 2025 20:20 > *À :* Joe Clarke (jclarke) <[email protected]> > *Cc :* BOUCADAIR Mohamed INNOV/NET <[email protected]>; The > IESG <[email protected]>; [email protected]; > [email protected]; [email protected] > *Objet :* Re: Ketan Talaulikar's Discuss on > draft-ietf-opsawg-tacacs-tls13-21: (with DISCUSS) > > > > > > Hi Med & Joe, > > > > Thanks for those clarifications. I did also go into the history of RFC8907 > and found that it was changed from PS to Info quite early in the WG stage > of that document. From reading the shepherd write-up, I got a sense that it > was changed from PS to Info due to the security aspect that is mitigated by > the move to TLS. > > > > In general, I believe the community would benefit from standardization at > the IETF of something that is widely deployed. As with any protocol > (developed within or outside the IETF), we do have to make compromises for > backward compatibility aspects. I do hope the WG will at some point pick up > the work to progress TACACS+ over TLS to PS track. > > > > I'll be clearing my DISCUSS shortly. > > > > On a separate note, I am wondering whether this document should also be > informational since it builds on TACACS+ that is informational. > > > > Thanks, > > Ketan > > > > > > On Wed, Jun 25, 2025 at 4:38 AM Joe Clarke (jclarke) <[email protected]> > wrote: > > As chair of opsawg and the shepherd of this draft, I want to echo Med’s > words. When we were working on the original TACACS+ informational > document, the agreement we reached with the IESG was to document how > TACACS+ currently works and essentially “freeze” that with the > understanding a new document would be published which essentially says, do > TACACS+ (RFC8907) over TLS. > > > > This was the original IESG action statement for the work (and Med provided > Warren’s additional summary already): > > > > > https://mailarchive.ietf.org/arch/msg/ietf-announce/vzKb8ovYowa_QC-SvwtVug0GupQ/ > > > > I do not see a reason to revisit this decision. > > > > Joe > > > > *From: *[email protected] <[email protected]> > *Date: *Saturday, June 21, 2025 at 05:11 > *To: *Ketan Talaulikar <[email protected]>, The IESG <[email protected]> > *Cc: *[email protected] < > [email protected]>, [email protected] < > [email protected]>, [email protected] <[email protected]>, Joe Clarke > (jclarke) <[email protected]> > *Subject: *RE: Ketan Talaulikar's Discuss on > draft-ietf-opsawg-tacacs-tls13-21: (with DISCUSS) > > Hi Ketan, > > The approach followed here follows what was agreed with the IESG at the > time of publication of 8907 and which is captured in the note sent by > Warren to the WG to act upon (2021): > https://mailarchive.ietf.org/arch/msg/opsawg/IPNhvGyhDAawsavqRUHIliCr4xk/, > especially this part: > > " When we wrote this, it was with the understanding that we'd first puslish > how TACACS+ currently works, and then a second document which, AFAIR, would > basically say "... and now just run this over TLS, K, thanks, done". " > > It tooks a bit long to get us where we are today, but I do highly > appreciate the dedication of the authors to push this forward and deliver > this piece of work with the agreed scope. > > Thanks. > > Cheers, > Med > > > -----Message d'origine----- > > De : Ketan Talaulikar via Datatracker <[email protected]> > > Envoyé : vendredi 20 juin 2025 12:46 > > À : The IESG <[email protected]> > > Cc : [email protected]; opsawg- > > [email protected]; [email protected]; BOUCADAIR Mohamed INNOV/NET > > <[email protected]>; [email protected]; [email protected] > > Objet : Ketan Talaulikar's Discuss on draft-ietf-opsawg-tacacs- > > tls13-21: (with DISCUSS) > > > > Ketan Talaulikar has entered the following ballot position for > > draft-ietf-opsawg-tacacs-tls13-21: 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.) > > > > > > > > -------------------------------------------------------------------- > > DISCUSS: > > -------------------------------------------------------------------- > > > > Thanks for the work on this document and updating TACAS+ for TLS. > > > > I have read the shepherd writeup regarding the proposed PS status > > for this. > > Since the security issues were the reason why the base TACAS+ > > document was > > downgraded from PS and this document is fixing that, I would like to > > discuss > > with the authors/WG why they did not do this work as a BIS such that > > the base > > TACAS+ would also get elevated to PS status? > > > > Given its use, I would have thought updating TACAS+ to PS with this > > fix would > > be of help to the community. > > > > > ____________________________________________________________________________________________________________ > 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. > > ____________________________________________________________________________________________________________ > 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. > >
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
