FWIW - I agree with much of Alan's observation and with his approach here. Documenting an existing protocol does not mean changing it. Asking for changes in the content of the document (including more details about implementation of parts of the protocols, and security implications of deploying this technology in today's Internet) does not mean changing the protocol. These are legitimate comments and IMO necessary changes to ask at WGLC phase. Keeping 'changes to the minimum, omissions or contradictions and those required by the publication process' is not a WGLC goal.
Regards, Dan On Thu, Oct 6, 2016 at 7:19 PM, t.petch <ie...@btconnect.com> wrote: > ----- Original Message ----- > From: "Alan DeKok" <al...@deployingradius.com> > Sent: Thursday, October 06, 2016 2:56 PM > > > On Oct 6, 2016, at 6:00 AM, t.petch <ie...@btconnect.com> wrote: > > Alan is right to pick up on the style - philosophical - and the > > security - lack of. > > > > But do we want to change it all at this time? > > Please show where I'm trying to change the protocol. > > <tp> > > Alan > > You are not, and I did not mean to imply that you were. I mean that > your changes seem to me reflect a different approach, a different style > which I do not see as that of the authors. I see the existing style as > unusual, but not wrong, and am content to leave it as is for an > Informational RFC which documents what is, or perhaps what has been. You > used the word 'philosophical' and I agreed. > > So I would keep changes to the minimum, omissions or contradictions and > those required by the publication process (such as splitting References > into Informative and Normative). It is, after all, WGLC. > > On Security, I would invite the chairs to ask for an early review by the > Security Directorate, explaining the context of this document, asking > them how much more is needed and how it should be expressed. It might > not be very much although my experience is that I never know in advance > what they are going to come up with. > > Tom Petch > > > This is an Informational document describing the state of play as of > > some time past, perhaps not as far back as 1997 but not for 2016. It > > would require many changes to make it a 2016 Standards Track document > > but that is not what I see us doing except that is how I take Alan's > > comments. > > Then you're not reading my comments. > > I would like to implement historical TACACS+. I have *NO IDEA* what > to do for huge swaths of the protocol. > > I would like to deploy historical TACACS+. I have *NO IDEA* what the > security implications are of using it. > > > The analogy I have in mind is when SSL v3 was published, long after it > > had been superseded by anyone who took security seriously, but was > > needed as an RFC to refer to, although it would not pass muster > because > > the security thereof was too weak. It would not have met the > standards > > of the day but was published despite that. > > I'm not asking that the protocol be *fixed* in this document. I'm > asking that it be *documented*. That shouldn't be hard to understand. > I've been saying it for about a year now, for anyone who bothers to read > my messages. > > I'll note that RFC 6101 is "Category: Historic", and has substantial > text about the security (or lack thereof) of the protocol. It has > substantial text about how the historical protocol works. I'm suggesting > we do the same here. > > I'm suggesting the the TACACS+ protocol be documented as designed, in > sufficient detail that someone can read the document and create an > inter-operable implementation. I'm suggesting that the TACACS+ > protocols security (or lack thereof) be documented. > > Which is (so far as I'm aware) still IETF practice for informational > specifications. > > If the goal for the document is something else, fine. Update the > document to say that. Something like: > > "This document attempts to specify the historical TACACS+ protocol. > However, there are many portions of the protocol which are > under-specified or unspecified. We cannot second-guess twenty years of > practice here. As a result, this specification is incomplete, > under-specified, insecure, and should not be used by anyone to implement > anything. Please wait for the Standards track document to get the > actual TACACS+ specification that people can implement". > > If the document can be updated with such text, I'll withdraw all of my > review comments. But I predict that the document won't pass security > area review. And they'll make all of the same comments as I've made > here, with a recommendation that the document not be published until > it's fixed. > > Alan DeKok. > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg >
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
