Re: [OPSAWG] Start of WGLC for TACACS+ document.

["Douglas Gash (dcmgash)" <[e-mail]>]

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" <[e-mail]> wrote:

>On Oct 6, 2016, at 6:00 AM, t.petch <[e-mail]> 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.
>