Re: [OPSAWG] New Version Notification for draft-ietf-opsawg-tacacs-10.txt

[Joe Clarke]

On 4/15/18 02:27, Douglas Gash (dcmgash) wrote:
> Hello Opsawg,
> 
> We have uploaded a new version of the TACACS+ informational draft which 
> includes corrections for typos over the document as a whole, but also revised 
> the security section. We anticipate this security section will get most 
> comments, so it is reproduced below.
> 
> We will endeavor to be much more reactive to comments, whether on section 
> below, or any other in rest of uploaded document.

Thank you, Douglas.  My individual comments on this new security
requirements section in line below (since you copied it to email).

> 9.1.  General Security of The Protocol
> 
>TACACS+ protocol does not include a security mechanism that would
>meet modern-day requirements.  Support for MD5-based crypto pad
>encryption fails to provide any kind of transport integrity, which
>presents at least the following risks:
> 
>   Accounting information may be modified by the man-in-the-middle
>   attacker, making such logs unsuitable and untrustable for auditing
>   purposes.
> 
>   Only the body of the request is encrypted which leaves all header
>   fields open to trivial modification by the man-in-the-middle
>   attacker.  For this reason, connections with
>   TAC_PLUS_UNENCRYPTED_FLAG are disallowed, as mentioned in the
>   recommendations section.

JC: Disallowed for discouraged?  This is a doc defining a
currently-deployed protocol.  Implementations MAY allow for this to
work.  However, from a best current practice standpoint, this should be
strongly discouraged.

>For these reasons, users deploying TACACS+ protocol in their
>environments MUST limit access to known clients and MUST control the
>security of the entire transmission path.  Attacks who can guess the
>key or otherwise break the obfuscation will gain unrestricted and
>undetected access to all TACACS+ traffic.  Ensuring that a
>centralized AAA system like TACACS+ is deployed on a secured
>transport is essential to managing security risk of such an attack.

JC: s/Attacks who/Attackers who/


> 9.3.  Security of Authorization Sessions
> 
>Authorization sessions MUST be used via secure transport only as it's
>trivial to execute a successful man-in-the-middle attacks that
>changes well-known plaintext in either requests or responses.

JC: Your statement makes a lot of sense, but I struggle with how this
can be achieved in the current implementation of T+.  To use normative
language here, you are saying that all T+ servers and all NASes must
implement something like an IPSec tunnel to exchange authz details?
Again, I get the recommendation, but in light of existing, interoperable
implementations, I don't see this being a reality.


> 9.6.  TACACS+ Server Implementation Recommendations
> 
>The following recommendations are made when implementing a TACACS+
>server:
> 
>The Server SHOULD NOT accept any connections which have the
>TAC_PLUS_UNENCRYPTED_FLAG set and SHOULD reject those packets with
>applicable ERROR response for type of packet.
> 
>The configuration of dedicated secret keys per individual client MUST
>be supported by the Server implementation.  It is also recommended
>that Servers SHOULD warn administrators if secret keys are not unique
>per client.
> 
>If an invalid shared secret is detected, Servers MUST NOT accept any
>new sessions on a connection, and terminate the connection on
>completion of any sessions previously established with a valid shared
>secret.
> 
>The Server implementation must allow the administrator to mandate:

JC: Should this be MUST?  I ask while still grappling with the use of
such strong language for an informational doc citing recommendations
when so many existing implementations exist in the wild.

> 
>TAC_PLUS_AUTHEN_TYPE_CHAP for authen_type
> 
>TAC_PLUS_AUTHEN_METH_TACACSPLUS for authen_method in authorization
> 
>Minimum length for shared secrets.
> 
> 9.7.  TACACS+ Deployment Best Practices
> 
>Due to above observations about the TACACS+ protocol, it is critical
>to only deploy it using secure transport.  A secure transport for
>TACACS+ is defined as any means that ensure privacy and integrity of
>all data passed between clients and servers.  There are multiple
>means of achieving this, all of them beyond the scope of this
>document.
> 
>Symmetric encryption key represents a possible attack vector at the
>protocol itself.  For this reason, servers SHOULD accept only those
>network connection attempts that arrive from known clients.  This
>limits the exposure and prevents remote brute force attacks from
>unknown clients.
> 
>Due to the security deficiencies of the protocol, it is critical that
>it be deployed in a secure manner.  The following recommendations are
>made for those deploying and configuring TACACS+ as a solution for
>device 

Re: [OPSAWG] New Version Notification for draft-ietf-opsawg-tacacs-10.txt

[Joe Clarke]

Alan, T+ authors, and opsawg,

Sorry for the noticeable absence from this thread.  I've been focused on
some dayjob projects these past couple of weeks.

I have followed the threads, though.  I want to hopefully bring some
things to closure and get us all to move forward to come to consensus on
this doc.


On 4/17/18 11:07, Alan DeKok wrote:
> On Apr 17, 2018, at 10:15 AM, Douglas Gash (dcmgash)  
> wrote:
>> Initially (up to around version 5) we included just a very simple security 
>> section admitting that T+ was insecure and that the second document would 
>> address the issue. This was deemed to be insufficient, and instead the WG 
>> collectively determined that more detail should be added to enumerate some 
>> of the issues, you kindly catalogued some of these, providing a proposed 
>> text which we took to be a genuine suggestion for text for the document.
> 
>   Which it was.
> 
>   The point I've been trying to make for over a year is apparently still 
> unclear.
> 
>   There was no excuse for plagiarizing the text in the first place.  Using it 
> verbatim was fine, so long as attribution was given.
> 
>   There was no excuse for ignoring every single email I made to the list 
> asking about this issue.
> 
>   There was no excuse for *continuing* to plagiarize the text for over a 
> year, across four separate revisions of the document.

I agree this was not handled well on many fronts, but we can only learn
and move forward.  As a co-chair, I take responsibility for our part and
apologize it took this long to get sorted.  The authors have added
attribution to your excellent contribution and apologized.

I would like to consider the matter, albeit belatedly, closed.

>> 2) Reactivity of the Authors.
>>
>> As far as I know, we have responded to most posts regarding the content of 
>> the document, with point-by-point replies,
> 
>   No.
> 
>   See the list archives, especially May 2017.  There are multiple people 
> suggesting that you have *not* done this, and that you *should* do this.

I for one have asked for a summary of changes when I did my last review.
 I did not see it.  There was a subsequent revision that did seem to
absorb my comments, but there wasn't a response to me email.  Typically,
when authors receive feedback, they respond in line to either ack or
discuss points (typos notwithstanding).

> 
>   See line-by-line reviews done by me, which were generally ignored.  Despite 
> that, I did *multiple* such reviews, until such time as it became clear that 
> such reviews were entirely unproductive.
> 
>> but there has been, for various logistic reasons, long delays in submitting 
>> the resulting new documents. Hopefully this has been addresses in last 
>> versions and we will continue with more rapid uploads until process 
>> completes one way or other.
> 
>   The issue isn't rapid uploads.  The issue is engagement.  It's not 
> productive to ignore the messages on the mailing list for 6 months, and then 
> to issue a new release saying "we fixed stuff".

Spot on.  One needs to engage.  I am pleased with the authors' attempts
to do better these past couple of weeks.  I want to see this momentum
continue.

>> 3) Change Tracking
>>
>> The uploads have generally had extensive changes relating to comments (which 
>> should generally have been summarized by previous email responses to 
>> comments). 
> 
>   Which I admit did happen sometimes, but not nearly as often as it should 
> have.  Again, see mailing list archives from May 2017.  I'm not the only 
> person who holds this opinion.  I'm just the main one pushing the point.
> 
>> Because of this, unless the updates have been for specific purposes (such as 
>> the recent update of the security section) then I would leave the changes to 
>> the diff tool which works pretty effectively.
> 
>   The diff tool lets us know what changed in the document.  It doesn't let us 
> know if those changes addressed issues raise on the mailing list.
> 
>   To summarize:
> 
> * we have no idea if this revision of the document addresses multiple WG 
> reviews
> 
> * we have no idea if the document even describes TACACS+ as currently 
> implemented
> 
>   As such, it should not be put into working group last call, or much less 
> published until such time as those issues are addressed.

I'm not sure what line-item changes are still outstanding.  Authors, I'm
sure you could look back at your revisions and spot anything that needs
to be addressed here.

I will be submitting an individual review of the new security
requirements soon, and I would like to see this renewed sense of
engagement on the list.

Joe

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] New Version Notification for draft-ietf-opsawg-tacacs-10.txt

[Andrej Ota]

Hi Joe & opsawg,


>>> 2) Reactivity of the Authors.
>>> 
>>> As far as I know, we have responded to most posts regarding the content of 
>>> the document, with point-by-point replies,
>> 
>>  No.
>> 
>>  See the list archives, especially May 2017.  There are multiple people 
>> suggesting that you have *not* done this, and that you *should* do this.
> 
> I for one have asked for a summary of changes when I did my last review.
> I did not see it.  There was a subsequent revision that did seem to
> absorb my comments, but there wasn't a response to me email.  Typically,
> when authors receive feedback, they respond in line to either ack or
> discuss points (typos notwithstanding).

We're still going through a year's worth of archive to locate WG comments and 
link them to changes. Currently the focus is on security section as that one 
was the most contentious, but the goal is to get this information out in the 
open.

Going forward, we've done bad and we're learning+adjusting based on all 
feedback.


> 
>> 
>>  See line-by-line reviews done by me, which were generally ignored.  Despite 
>> that, I did *multiple* such reviews, until such time as it became clear that 
>> such reviews were entirely unproductive.
>> 
>>> but there has been, for various logistic reasons, long delays in submitting 
>>> the resulting new documents. Hopefully this has been addresses in last 
>>> versions and we will continue with more rapid uploads until process 
>>> completes one way or other.
>> 
>>  The issue isn't rapid uploads.  The issue is engagement.  It's not 
>> productive to ignore the messages on the mailing list for 6 months, and then 
>> to issue a new release saying "we fixed stuff".
> 
> Spot on.  One needs to engage.  I am pleased with the authors' attempts
> to do better these past couple of weeks.  I want to see this momentum
> continue.

We have the next e-mail for section 9 changes almost ready and we're taking 
care to be both watching and responding on the mailing list.

> 
>>> 3) Change Tracking
>>> 
>>> The uploads have generally had extensive changes relating to comments 
>>> (which should generally have been summarized by previous email responses to 
>>> comments). 
>> 
>>  Which I admit did happen sometimes, but not nearly as often as it should 
>> have.  Again, see mailing list archives from May 2017.  I'm not the only 
>> person who holds this opinion.  I'm just the main one pushing the point.
>> 
>>> Because of this, unless the updates have been for specific purposes (such 
>>> as the recent update of the security section) then I would leave the 
>>> changes to the diff tool which works pretty effectively.
>> 
>>  The diff tool lets us know what changed in the document.  It doesn't let us 
>> know if those changes addressed issues raise on the mailing list.
>> 
>>  To summarize:
>> 
>> * we have no idea if this revision of the document addresses multiple WG 
>> reviews
>> 
>> * we have no idea if the document even describes TACACS+ as currently 
>> implemented
>> 
>>  As such, it should not be put into working group last call, or much less 
>> published until such time as those issues are addressed.
> 
> I'm not sure what line-item changes are still outstanding.  Authors, I'm
> sure you could look back at your revisions and spot anything that needs
> to be addressed here.

We're in the process of both linking changes to where they were suggested from 
while checking that we haven't missed any.

> 
> I will be submitting an individual review of the new security
> requirements soon, and I would like to see this renewed sense of
> engagement on the list.


You can start with e-mail I've already sent that comes with commentary of what 
we changed and for what reason. There's going to be few more coming in to spare 
you from trying to diff all by yourself and spend time thinking about "why" 
something changed.



KR, Andrej.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg