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

From: "Douglas Gash (dcmgash)" <[email-masked]>
Date: Sun, 15 Apr 2018 06:27:55 +0000

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.

Many thanks,

The authors.

9.  TACACS+ Security Considerations

   The original TACACS+ Draft[1] from 1998 did not address all of the
   key security concerns which are considered when designing modern
   standards.  This section addresses known limitations and concerns
   which will impact overall security of the protocol and systems where
   this protocol is deployed to manage central authentication,
   authorization or accounting for network device administration.

   Multiple implementations of the protocol described in the draft[1]
   have been deployed.  As the protocol was never standardized, current
   implementations may be incompatible in non-obvious ways, giving rise
   to additional security risks.  This section does not claim to
   enumerate all possible security vulnerabilities.

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.

      Invalid or misleading values may be inserted by the man-in-the-
      middle attacker in various fields at known offsets to try and
      circumvent the authentication or authorization checks even inside
      the encrypted body.

   While the protocol provides some measure of transport privacy, it is
   vulnerable to at least the following attacks:

      Brute force attacks exploiting increased efficiency of MD5 digest
      computation.

      Known plaintext attacks which may decrease the cost of brute force
      attack.

      Chosen plaintext attacks which may decrease the cost of a brute
      force attack.

      No forward secrecy.

   Even though, to the best knowledge of authors, this method of
   encryption wasn't rigorously tested, enough information is available
   that it is best referred to as "obfuscation" and not "encryption".

   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.

   The following parts of this section enumerate only the session-
   specific risks which are in addition to general risk associated with
   bare obfuscation and lack of integrity checking.

9.2.  Security of Authentication Sessions

   Authentication sessions SHOULD NOT be used via insecure transport as
   the man-in-the-middle attack may completely subvert them.  Even CHAP,
   which may be considered resistant to password interception, is unsafe
   as it does not protect the username from a trivial man-in-the-middle
   attack.

   This document deprecates the redirection mechanism using the
   TAC_PLUS_AUTHEN_STATUS_FOLLOW option which was included in the
   original draft.  As part of this process, the secret key for a new
   server was sent to the client.  This public exchange of secret keys
   means that once one session is broken, it may be possible to leverage
   that key to attacking connections to other servers.  This mechanism
   SHOULD NOT be used in modern deployments.  It MUST NOT be used
   outside a secured deployment.

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.

   As an example, take the field "authen_method".  It's not unusual in
   actual deployments to authorize all commands received via the device
   local serial port (a console port) as that one is usually considered
   secure by virtue of the device located in a physically secure
   location.  If an administrator would configure the authorization
   system to allow all commands entered by the user on a local console
   to aid in troubleshooting, that would give all access to all commands
   to any attacker that would be able to change the "authen_method" from
   TAC_PLUS_AUTHEN_METH_TACACSPLUS to TAC_PLUS_AUTHEN_METH_LINE.  In
   this regard, the obfuscation provided by the protocol itself wouldn't
   help much, because:

      Lack of integrity means that any byte in the payload may be
      changed without either side detecting the change.

      Known plaintext means that an attacker would know with certainty
      which octet is the target of the attack (in this case, 1st octet
      after the header).

      In combination with known plaintext, the attacker can determine
      with certainty the value of the crypto-pad octet used to obfuscate
      the original octet.

9.4.  Security of Accounting Sessions

   Accounting sessions are not directly involved in authentication or
   authorizing operations on the device.  However, man-in-the-middle
   attacker may do any of the following:

      Replace accounting data with new valid or garbage which prevents
      to provide distraction or hide information related to their
      authentication and/or authorization attack attempts.

      Try and poison accounting log with entries designed to make
      systems behave in unintended ways (which includes TACACS+ server
      and any other systems that would manage accounting entries).

   In addition to these direct manipulations, different client
   implementations pass different fidelity of accounting data.  Some
   vendors have been observed in the wild that pass sensitive data like
   passwords, encryption keys and similar as part of the accounting log.
   Due to lack of strong encryption with perfect forward secrecy, this
   data may be revealed in future, leading to a security incident.

9.5.  TACACS+ Client Implementation Recommendations

   The following recommendations are made when implementing a TACACS+
   client:

      Clients SHOULD not use TAC_PLUS_UNENCRYPTED_FLAG, even on networks
      that are considered secure.

      Treat TAC_PLUS_AUTHEN_STATUS_FOLLOW as
      TAC_PLUS_AUTHEN_STATUS_FAIL.

      If receiving an unknown mandatory authorization attribute, behave
      as if it had received TAC_PLUS_AUTHOR_STATUS_FAIL.

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:

   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 administration:

      Secure the Deployment: TACACS+ MUST BE deployed over networks
      which ensure an appropriate privacy and integrity of the
      communication.  The way this is ensured will depend upon the
      organizational means: a dedicated and secure management network
      where available in enterprise deployments, or IPsec where
      dedicated networks are not available.

      Do not use the TAC_PLUS_UNENCRYPTED_FLAG option.

      Always configure a secret key (recommended minimum 16 characters)
      on the server for each client.

      Consider shared secrets to be sensitive data, and manage securely
      on server and client.

      Change secret keys at regular intervals.

      Do not use TAC_PLUS_AUTHEN_SENDAUTH or TAC_PLUS_AUTHEN_SENDPASS
      options.

      Use TAC_PLUS_AUTHEN_TYPE_CHAP or MS_CHAP options for authen_type
      where possible.  Use other options only when unavoidable due to
      requirements of identity/password systems.

      Require TACACS+ authentication for authorization requests (i.e.
      TAC_PLUS_AUTHEN_METH_TACACSPLUS is used).

      Do not use the redirection mechanism
      (TAC_PLUS_AUTHEN_STATUS_FOLLOW).  Specifically avoid the option to
      send secret keys in the server list.

      Take case when applying extensions to the dictionary of
      authorization/accounting arguments.  Ensure that the client and
      server use of new argument names are consistent.

   In summary: It is strongly advised that TACACS+ MUST be used within a
   secure deployment.  Failure to do so may impact overall network
   security.

---

From: "Douglas Gash (dcmgash)" <[email-masked]>
Date: Tue, 17 Apr 2018 14:15:52 +0000

Hi Alan,

I hope that we can address your concerns. I think the main points that you raise the we (the authors) need to address are:

1) The security section
2) Reactivity of the authors 
3) Change Tracking

1) The Security Section

The starting point is that we know that TACACS+ needs enhancement from security perspective. That was the reason that this process was initiated, the first document being mainly an adaption of the original draft with security features plus some minor cleansing. This plan was evolved into two documents, the first, that we are in process of preparing, that codifies the protocol, to be followed by the version with enhanced security.

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. Subsequently we interpreted your proposal more accurately (as just a suggestion of the points to cover), and so we made sure that these were covered, but without verbatim reuse of the text.  We hope that we have covered the thrust of your issues (and others), but without the plagiarism.

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

We have not generally responded to posts regarding procedural matters, and would leave such discussions to more knowledgeable stewards of the lists where possible,

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

Please let us know if there are specific points below that you’d like to address which would not be covered above.

Many thanks,

Regards,

Doug

 Responding to:

“I have some concerns with the document, and with the process by which we've gotten here.

  Let me recap some history.  There's a lot to take
in, so I'll present concerns in point form.

  First, the document.

* my "Security Considerations" text was first plagarised in draft-06,

* when I pointed this out (May 9, 2017), there was no reply to my
  message by the authors, and no change was made to the document.

* the ADs did respond, and indicated that they had talked to the
  authors about the issue, and that it was a simple misunderstand and
  would be fixed.

* A year later, I raised the issue again (March 2018).  There as no
  reply to my concerns by the authors, and no change was made to the
  document.

* in all, 4 separate revisions of the document plagarized my text, for
  over a year, sometimes with minor edits, despite repeated requests
  to address the issue.

  Those issues alone are surprising.

* The text which was good enough to plagarize was then claimed to have
  deficiencies

* no one in the WG had noted any technical issues with the text

* the only issues were with attribution, not with the text in the
  Security Considerations section

* there is now a -10, which has essentially the same points as the
  previous text, just reworded

  I should point out that the RFC process is supposed to be about
content, not authorship.  There are many RFCs issued with text written
by multiple people.  Where the authors cannot all be acknowledged on
the first page, the primary editor can be listed with the (Ed.)
suffix, to indicate editorship.  Other authors can be named as authors
on the first page, or in the Acknowledgements section.

  Second, concerns with engagement with the WG.  It continues.

* multiple people in the WG have requested the authors engage with the
  Working Group.  Most notably, many messages in May 2017.

* multiple people in the WG have requested the authors explain what's
  changed in each new revision, or perhaps to acknowlege comments and
  reviews (May 2017 again, among other times).

* This engagement has been minimal, despite multiple revisions of
  the document being published after these WG requests.

* new revisions have most often been "thrown over the wall" with
  minimal (or no) explanation as to what changed, and why.

* this new draft is no different, i.e. it "revised the security
  section".  Why?  How?  What changed?  What were any alleged
  "deficiencies"?

* the author have stated again that they "will endeavor to be much
  more reactive to comments".

* this statement or similar ones have been repeatdly, with little
  change in observable behavior.

* The authors request (again) that the WG review this new document
  wholesale.

  Speaking of reviews, let's continue with third, responses to
reviews.

* I have given multiple line-by-line reviews of the entire document,
  for multiple revisions of the document.

* as noted above, these reviews have generally been ignored.

* as noted above, new versions of the document have appeared which may
  or may not have addressed these reviews.

* Given the lack of feedback on the reviews before a new draft is
  issued, it is unclear whether the review comments have been
  addressed.

* due to these issues, I have stopped reviewing the document, as it
  is not productive.

  There are other issues with the larger community.  I'll continue.

* there was broad support for publication of early revisions of the
  document, despite it clearly not describing the protocol in a way
  that permits inter-operable implementations

* the people who supported adopting the document as a WG document
  have generally not reviewed or commented on it

* existing implementors of TACACS+ have not reviewed or commented on
  the document (Alex Clouter's review was done as part of a brand-new
  implementation)

* we have therefore no idea whether or not this document describes
  anything that anyone has implemented

  In order for the document to be published, we should have (at the
minimum) statements from multiple implementors that the draft matches
their implementations.

  Fourth, there are process issues, too.  I'll continue.

* the IETF has traditionally started a new WG to standardize new
  management protocols (i.e. a protocol new to the IETF)

* examples include the protocols described in RFC 6632.  These
  protocols have had their own working groups, going back to at least
  1996, and continuing to the present

* working on a new (and eventually standards track) document in the
  OPS area is therefore a new step for the IETF

* I have raised all of the concerns mentioned herein with the chairs
  and ADs in private email, public email on the list, and in person at
  multiple meetings

* There does not appear to be any action taken as a result.

* Messages to the list raising these issues have largely been
  unaddressed

  It is general IETF practice for document authors to interact with
the WG. And, to respond to WG reviews and comments.  See the many
comments in the OPSAWG archives in May 2017 for broad WG support of
this position.

  As the authors have largely ignored the WG comments, the chairs and
ADs should have taken steps to address this issue.  As of this
writing, it appears to be the same "status quo" of the past few years.

  I don't think these comments are unreasonable.  If we truly don't
care about the WG opinion, then the chairs and AD can:

* make a public statement saying that WG feedback can be ignored

* state that that the document can be published in whatever form the
  authors choose

* publish the document even if it does not describe the protocol in
  sufficient detail to create inter-operable implementations.

  I don't think that's the right approach, of course.  But it's
largely what's been happening due to silence and/or inaction of the
parties involved.

  I see no point in further reviewing the document.  I again oppose
publication of this document until such time as all of the WG issues
have been addressed.

  If we do actually care about what's in the document, then I suggest
finally the following steps be taken to address the ongoing concerns:

* the document should not be published until such time as multiple
  implementors have agreed that the specification matches their
  implementation.

* the chairs and ADs should insist that the authors address the
  outstanding WG concerns about this document

* the chairs and ADs should insist that authors follow established
  practice of *interacting* with the WG, including responding to
  future reviews and comments.

* the chairs and ADs should insist that new revisions of the document
  are accompanied by an explanation of what changed, and why

* that if the authors do not follow these steps (as they have not so
  far), that the chairs and ADs should replace them with other WG
  member(s) who will follow the IETF process.

  Alan DeKok.

”

---

From: Alan DeKok <[email-masked]>
Date: Tue, 17 Apr 2018 11:07:09 -0400

On Apr 17, 2018, at 10:15 AM, Douglas Gash (dcmgash) <[email-masked]> 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.

> Subsequently we interpreted your proposal more accurately (as just a suggestion of the points to cover), and so we made sure that these were covered, but without verbatim reuse of the text.  We hope that we have covered the thrust of your issues (and others), but without the plagiarism.

  I have no idea.  Because at this point, I'm pretty much done reviewing the document.

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

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

> We have not generally responded to posts regarding procedural matters, and would leave such discussions to more knowledgeable stewards of the lists where possible,

  You haven't responded to posts where I ask about the plagiarism.  A simple reply of "oops, sorry, I'll fix it ASAP" has taken over a year to write.

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

  Alan DeKok.

---

From: Tianran Zhou <[email-masked]>
Date: Wed, 18 Apr 2018 08:26:38 +0000

Hi the Authors,

I remember you posted a list of Alan's comments in the mailing list, and mentioned what have been addressed and how, what will be addressed later. 
I think it's a good start. Why not continue doing this for your new revision.
It would be very helpful.

Tianran

> -----Original Message-----
> From: OPSAWG [mailto:[email-masked]] On Behalf Of Alan DeKok
> Sent: Tuesday, April 17, 2018 11:07 PM
> To: Douglas Gash (dcmgash) <[email-masked]>
> Cc: [email-masked]; Andrej Ota <[email-masked]>; Thorsten Dahm
> <[email-masked]>
> Subject: Re: [OPSAWG] New Version Notification for
> draft-ietf-opsawg-tacacs-10.txt
> 
> > 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.
> 
>   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 *continuing* to plagiarize the text for over a year,
> across four separate revisions of the document.
> 
> > Subsequently we interpreted your proposal more accurately (as just a
> suggestion of the points to cover), and so we made sure that these were covered,
> but without verbatim reuse of the text.  We hope that we have covered the
> thrust of your issues (and others), but without the plagiarism.
> 
> > 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.
> 
>   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".
> 
> > We have not generally responded to posts regarding procedural matters, and
> would leave such discussions to more knowledgeable stewards of the lists where
> possible,
> 
>   You haven't responded to posts where I ask about the plagiarism.  A simple
> reply of "oops, sorry, I'll fix it ASAP" has taken over a year to write.
> 
> > 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:
> 
>   As such, it should not be put into working group last call, or much less
> published until such time as those issues are addressed.
> 
>   Alan DeKok.
> 
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg

---

From: Joe Clarke <[email-masked]>
Date: Mon, 30 Apr 2018 10:25:26 -0400

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.

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

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

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

>   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

---

From: Joe Clarke <[email-masked]>
Date: Mon, 30 Apr 2018 10:30:20 -0400

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

>       TAC_PLUS_UNENCRYPTED_FLAG are disallowed, as mentioned in the

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.

>    transport is essential to managing security risk of such an attack.

JC: s/Attacks who/Attackers who/

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

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

>       dedicated networks are not available.

JC: This dedicated and restricted network, I agree with.  This is
realistic in the vast majority (if not all) of T+ implementations.  But
this dedicated network is not necessarily secure in the IPSec sense.  I
can run a physical wire from all NASes back to my T+ server, but that
doesn't mean that the transport ensures integrity or confidentiality.

JC: My (contributor) recommendation is to say MUST to this and SHOULD to
the encrypted transport given that the latter is likely not done in the
majority of deployments today (though I'm willing to hear the argument
here).

>       server use of new argument names are consistent.

JC: s/client and server use of/client and server uses of/

Joe

---

From: Andrej Ota <[email-masked]>
Date: Mon, 30 Apr 2018 15:33:57 +0100

Hi Joe & opsawg,

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

> to do better these past couple of weeks.  I want to see this momentum

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.

> sure you could look back at your revisions and spot anything that needs

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

> requirements soon, and I would like to see this renewed sense of

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.

---

From: Joe Clarke <[email-masked]>
Date: Mon, 30 Apr 2018 10:43:40 -0400

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

Thank you.

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

Again, thanks.

> 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 yoursel…

My point was that as reviews come in, keep the discussion going.  I
realize there may be delays, but let's avoid the need to keep doing
"digest" updates moving forward.

Joe