Hi Alan, Thank you for your detailed review so far. When we get the last instalment, we¹ll categorise the comments and respond.
Best regards, Doug. On 06/10/2016 14:56, "Alan DeKok" <[email protected]> wrote: >On Oct 6, 2016, at 6:00 AM, t.petch <[email protected]> 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. > >> 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 [email protected] https://www.ietf.org/mailman/listinfo/opsawg
