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

[t.petch <[e-mail]>]

----- Original Message -----
From: "Alan DeKok" <[e-mail]>
Sent: Thursday, October 06, 2016 2:56 PM


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.

<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.