Subject: Re: [OPSAWG] Action Items on TACACS+ informational draft v 10

From: Joe Clarke <[email-masked]>
Date: Mon, 9 Jul 2018 16:54:41 -0400

On 6/28/18 18:16, Alan DeKok wrote:
> 
>> On Jun 28, 2018, at 3:00 PM, Joe Clarke <jclarke=[email-masked]> wrote:
>>
>> I would ask that people like Alan (that have been very vocal) make sure
>> that any points have been addressed and if specific changes require more
>> thorough explanation.
> 
>   I would prefer that the document approach publication quality before doing significantly more work.
> 
>   Despite many, many, reviews and both editorial and technical feedback, the new text in the document isn't much better than text from 3 years ago.  It's still vague, not prescriptive, doesn't use normative text, etc.
> 
>   I've done do a quick check recently, and there are still major issues with the document. So there isn't much point in doing more detailed reviews.  Having done that lots, I'm disinclined to do it again.

Thanks, Alan.  I do want it to get closer to publication quality, and
now that the authors are engaging more actively, I want the WG to help
them get there.

Specific to the normative language, I have a few questions here,
especially with the security concerns.  I'll comment on Douglas' email,
and I would appreciate your input on my comments.

Broadly, given that we want an informational draft that describes the
protocol as it is implemented today, I feel there should be a balance
struck with respect to normative language so that we don't make existing
clients "out of spec."

Joe

---

From: Alan DeKok <[email-masked]>
Date: Mon, 9 Jul 2018 17:02:11 -0400

> struck with respect to normative language so that we don't make existing

  It's an informational draft, so from a bureaucratic point of view, it doesn't really define a standard.

  That being said, the spec should require that implementations be as secure as possible given the protocol limits.  If this means forbidding things that are widely used... well... that's progress.

  If the spec is as strong as possible, then implementors will still be free to ignore it.  Just as they ignore the specs for most other protocols. :(  But users of those implementations can ask pointed questions of "Why are you shipping me something that is insecure by design?"

  Which is a Good Thing.

  Alan DeKok.

---

From: Andrej Ota <[email-masked]>
Date: Mon, 9 Jul 2018 22:17:13 +0100

> On 9 Jul 2018, at 22:02, Alan DeKok <[email-masked]> wrote:
> 

I think that forbidding some parts with MUST would go against the original mandate for this draft which I understood to be documenting what's used and specifically not working to do a revision of protocol (which I would love to hide behind TLS).

Would using SHOULD work or do you think that would make the language too weak ... induce lack of any kind of progress.

>  If the spec is as strong as possible, then implementors will still be free to ignore it.  Just as they ignore the specs for most other protocols. :(  But users of those implementations can ask poi…

The problem with the protocol as it's implemented today is that it's "unsafe at any speed". There is nothing that either servers or clients can do to change that on a protocol level. The only sensible normative text would be MUST NOT implement. This in my mind shifts the focus from implementation constraints to operational requirements. If we there isn't even one sensible implementation band aid (and I certainly don't see one), we can only apply deployment band aids.

Net sum of both is that the document veered away from normative and into realm of "here are the facts about insecurity of the protocol, use your best judgement when deploying".

We can certainly turn the draft back into more normative but I don't think that we can do anything to the protocol itself that would salvage it in any useful form whatsoever.

Andrej Ota.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 9 Jul 2018 21:12:02 -0400

> I think that forbidding some parts with MUST would go against the original mandate for this draft which I understood to be documenting what's used and specifically not working to do a revision of p…

  The IETF is not about rubber-stamping existing implementations or practices.

  As a case in point, in 1993, the original RADIUS implementations had provisions for "change user password".  That was remove (in *1993*), because it was insecure.

  I doubt very much that the security requirements have been *relaxed* in the subsequent 25 years.

> The problem with the protocol as it's implemented today is that it's "unsafe at any speed". There is nothing that either servers or clients can do to change that on a protocol level. The only sensible normative text would be MUST NOT implement. This in my mind shifts the focus from implementation constraints to operational requirements.

  I disagree.  There are portions of the protocol which are vaguely "OK", such as insecured names/passwords being sent in the clear over a management network.  Ugly, but somewhat acceptable.

  There are portions of the protocol which *no one* would agree is a good idea today.  e.g. sending secrets to a client.  That's just... bad.

> If we there isn't even one sensible implementation band aid (and I certainly don't see one), we can only apply deployment band aids.

  There are many sensible implementation suggestions.

> We can certainly turn the draft back into more normative but I don't think that we can do anything to the protocol itself that would salvage it in any useful form whatsoever.

  The point (again) is that we should document the protocol, *and* recommended best practices.

  If you don't think that the protocol is salvageable at all, then please withdraw the draft.

  If you think we *can* document best practices, then we should do so.

  If you think documenting best practices isn't productive, then you will get roundly trounced when all of the non-TACACS+ people read it, and go "OMFG you can't *do* this in 2018."

  Alan DeKok.

---

From: "Scott O. Bradner" <[email-masked]>
Date: Mon, 9 Jul 2018 21:17:49 -0400

> On Jul 9, 2018, at 9:12 PM, Alan DeKok <[email-masked]> wrote:
> 

imo - documenting existing practice is not the same thing as “rubber stamping”

Scott

---

From: Tianran Zhou <[email-masked]>
Date: Tue, 10 Jul 2018 01:52:19 +0000

Hi All,

The WG has discussed how to deliver this document two years ago, and came out the solution as follows:
https://www.ietf.org/mail-archive/web/opsawg/current/msg04363.html

So the first step is to document the existing TACACS+ protocol as best as we can.
We agreed existing TACACS+ protocol is not secure. We Should discuss the security issues in the security considerations section, which could be the input/trigger for the following enhanced protocol.

So I hope the discussion do not go off the track. Let's work on the delivery of the first document.

Regards,
Tianran, as co-chair 

> -----Original Message-----
> From: OPSAWG [mailto:[email-masked]] On Behalf Of Scott O. Bradner
> Sent: Tuesday, July 10, 2018 9:18 AM
> To: Alan DeKok <[email-masked]>
> Cc: Douglas Gash (dcmgash) <[email-masked]>; [email-masked]; Andrej Ota
> <[email-masked]>; Thorsten Dahm <[email-masked]>
> Subject: Re: [OPSAWG] Action Items on TACACS+ informational draft v 10
> 
> 
> 
> >> I think that forbidding some parts with MUST would go against the original
> mandate for this draft which I understood to be documenting what's used and
> specifically not working to do a revision of protocol (which I would love
> to hide behind TLS).
> >
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg

---

From: Alan DeKok <[email-masked]>
Date: Mon, 9 Jul 2018 21:56:23 -0400

> imo - documenting existing practice is not the same thing as “rubber stamping”

  Perhaps my messages were unclear.

  I'm not opposed to *documenting* existing practices.  I'm opposed to *endorsing* existing practices.  Especially where those practices are insecure.

  There is every reason for the spec to say "A, B, and C are OK if you hold your nose.  D, E, and F are right out."

  But that suggestion is apparently controversial.  The reasons given are "existing practices".

  Which sounds to me like there's a requirement for a "rubber stamp" approval of existing implementations.

  Let me be clear: if the protocol and existing implementations allow for unauthenticated, insecure, remote access to a root shell... then the spec SHOULD say "OMG that's a terrible idea, don't do that.  Yes, I know everyone's done that for 20 years.  It's bad.  Really, really, bad.  Don't do it.  Honestly, bad things will happen."

  That's largely where we are today with TACACS+:

a) we document existing practices and implementations, no matter how insecure [1]

 or

b) we describe the protocol, along with recommendations for how best to secure it

  I choose (b).  There is non-trivial support for (a).

  It's not clear to me why this position is in any way controversial, or misunderstood.

 Alan DeKok.

[1] Without mentioning pesky issues like "security".  I mean, why warn people that bad things can happen?

---

From: "Douglas Gash (dcmgash)" <[email-masked]>
Date: Tue, 10 Jul 2018 04:20:39 +0000

Hi,

I believe the MUST/SHOULD debate pertains only to the recommendations section, the rest of the documents sticks to description of current status apart from the documented deprecations that no sensible implementation would do today, i.e. a few deletions but no updates.

The discussion focusses specifically the MUSTs for implementations. Now there is not much point in making recommendations for the past (i.e. implementations that are actually already in the field), so I think that it is implicit that the recommendations are for new implementations and upgrades. I believe the discussion sums to: if we add a note to make this explicit, then it should be clear for all. What is more, if we mark the deltas then we may actually be providing a useful service for implementers of current products: we can explicitly point out where we believe the implementations which strictly follow previous draft should be enhanced.

For example:

Deployment Best Practices

In view of the observations about the security issues described above, a network administrator MUST NOT rely on the obfuscation of the TACACS+ protocol and TACACS+ MUST be deployed over networks which ensure privacy and integrity of the communication. TACACS+ MUST be used within a secure deployment.  Failure to do so may impact overall network security.

The recommendations for TACACS+ Server and client implementations below are intended to guide new implementations and upgrades to current implementations. Some of these recommendations are stricter than previous guidance, these will be marked [*] so that implementers of current can see where this WG recommends that improvements should be made to enhance security.

…

On 10/07/2018, 4:56, "Alan DeKok" <[email-masked]> wrote:

    

    

    
    
     or

    
    
     Alan DeKok.

---

From: Andrej Ota <[email-masked]>
Date: Tue, 10 Jul 2018 08:52:23 +0100

On 10/07/2018 02:56, Alan DeKok wrote:
>    Which sounds to me like there's a requirement for a "rubber stamp" approval of existing implementations >

Could it be that we misunderstood each other as to what b) pertains to? 
a) is obviously wrong as we certainly don't have to stop at documenting 
current practices or even care about current practices if they result in 
an insecure deployment.

For b) I don't find it controversial as long as we can agree that 
"implementation" means "how clients and servers implement documented 
protocol" and not "how do operators deploy clients and servers". I.e. 
"implementation" and "practice" refer to two different things.

Then we can comb for ambiguous statements like "server MUST implement 
CHAP in exclusion to PAP" and reword them to say "operators MUST use 
servers and clients configured to disallow authentication methods other 
that CHAP".

Andrej.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 10 Jul 2018 07:34:35 -0400

On Jul 10, 2018, at 3:52 AM, Andrej Ota <[email-masked]> wrote:
> 
> Could it be that we misunderstood each other as to what b) pertains to? a) is obviously wrong as we certainly don't have to stop at documenting current practices or even care about current practices if they result in an insecure deployment.
> 
> For b) I don't find it controversial as long as we can agree that "implementation" means "how clients and servers implement documented protocol" and not "how do operators deploy clients and servers". I.e. "implementation" and "practice" refer to two different things.

  The draft should document how to implement *and* deploy TACACS+ as securely as we know how.  If that "invalidates" current implementations and practices, too bad.

  Again, vendors and administrators are free to ignore the recommendations of the draft.  But they need to *know*.

  If the draft permits deployments we know to be insecure, then that's wrong.  And yes, such practice *would be* "rubber stamping" existing practices.

  While the requirement is to document the historical protocol, that does *not* mean endorsing 20 year-old insecure practices.  The IETF has a responsibility to secure the Internet, among other things.  Where that responsibility conflicts with vendor / operator desire to do insecure things, then the larger Internet security will prevail.

> Then we can comb for ambiguous statements like "server MUST implement CHAP in exclusion to PAP" and reword them to say "operators MUST use servers and clients configured to disallow authentication methods other that CHAP".

  PAP is fine so long as (a) it's in a management network, or (b) it's "protected" by the obfuscation mechanism.

  The spec should just describe the requirements. How the implementors and administrators deploy it is up to them.

  e.g. "PAP MUST NOT be used outside of management networks, unless the packets are protected by the obfuscation mechanism."

  Alan DeKok.

---

From: Andrej Ota <[email-masked]>
Date: Tue, 10 Jul 2018 15:11:28 +0100

>    e.g. "PAP MUST NOT be used outside of management networks, unless the packets are protected by the obfuscation mechanism."

Actually, both PAP and CHAP are irrelevant in this case. If Eve is in a 
position to intercept TACACS+ traffic, she can flip a single bit in the 
authentication response and that will ensure that the device (client) 
will consider authentication to have succeeded. Obfuscation doesn't 
help, only secured transport does.

Thus it's irrelevant to specifically mention any particular currently 
used authentication method as all of them fail in exactly the same way 
*and* it's irrelevant to distinguish between obfuscated and 
non-obfuscated variety as MitM will succeed regardless.

Since this makes secured transport a minimal necessary requirement for 
any secure deployment, what benefit is there to try and find further 
examples of what can be mandated if none of the mandates would 
meaningfully change the end result?

Andrej.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 10 Jul 2018 10:48:09 -0400

On Jul 10, 2018, at 10:11 AM, Andrej Ota <[email-masked]> wrote:
> Actually, both PAP and CHAP are irrelevant in this case. If Eve is in a position to intercept TACACS+ traffic, she can flip a single bit in the authentication response and that will ensure that the device (client) will consider authentication to have succeeded. Obfuscation doesn't help, only secured transport does.

  Yes.

> Thus it's irrelevant to specifically mention any particular currently used authentication method as all of them fail in exactly the same way *and* it's irrelevant to distinguish between obfuscated and non-obfuscated variety as MitM will succeed regardless.

  Yes and no.  It's still bad to send clear-text passwords over a clear channel.  That can be called out and explained.

> Since this makes secured transport a minimal necessary requirement for any secure deployment, what benefit is there to try and find further examples of what can be mandated if none of the mandates would meaningfully change the end result?

  It's useful to explain *what* behaviours are insecure, and *why* they are insecure.

  The alternative is to leave the reader to fend for himself.  "Hmm... the authors didn't say this was bad, so let's do it!"

  Alan DeKok.

---

From: Andrej Ota <[email-masked]>
Date: Tue, 10 Jul 2018 16:42:23 +0100

>    Yes and no.  It's still bad to send clear-text passwords over a clear channel.  That can be called out and explained.

Agreed.

>    It's useful to explain *what* behaviours are insecure, and *why* they are insecure.

Agreed. We (authors) were trying to put in more of the background as to 
what are the threats for this reason - empowering those who need to 
deploy the protocol to make the correct call.

Though I'd flip this and put emphasis on what behaviours are secure and 
declare others explicitly unsecure.

>    The alternative is to leave the reader to fend for himself.  "Hmm... the authors didn't say this was bad, so let's do it!"

No, that would be really bad outcome and I agree we must avoid it.

Let us (authors) take this recent feedback on board and reword things 
along the lines:
  - Use MUST where we want programmers to do the right thing, but be 
careful not to distort the actual protocol as currently implemented. 
Handling secrets, passwords seem like good targets for this.
  - Keep and improve verbiage documenting known risks.
  - Give either MUST verbiage where there's only one thing to do (e.g. 
secured transport is a MUST).
  - Give SHOULD where there's multiple things (e.g. PAP vs. CHAP is 
closely related to password management on the server side).

Would this be the right way or not really?

Andrej.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 10 Jul 2018 12:24:29 -0400

On Jul 10, 2018, at 11:42 AM, Andrej Ota <[email-masked]> wrote:
> Agreed. We (authors) were trying to put in more of the background as to what are the threats for this reason - empowering those who need to deploy the protocol to make the correct call.
> 
> Though I'd flip this and put emphasis on what behaviours are secure and declare others explicitly insecure.

  Sure.  It would be useful to explain why they're insecure.  But that's largely a nit, not a serious disagreement.

> Let us (authors) take this recent feedback on board and reword things along the lines:
> - Use MUST where we want programmers to do the right thing, but be careful not to distort the actual protocol as currently implemented.

  I agree that we shouldn't *change* the protocol.  But *deprecating* portions is entirely appropriate.  Given the insecure nature of it, I would say it's *required* that we deprecate insecure portions of the protocol.

> - Give either MUST verbiage where there's only one thing to do (e.g. secured transport is a MUST).
> - Give SHOULD where there's multiple things (e.g. PAP vs. CHAP is closely related to password management on the server side).
> 

  Yes.

  Alan DeKok.

---

From: Joe Clarke <[email-masked]>
Date: Tue, 10 Jul 2018 17:38:15 -0400

On 7/10/18 11:42, Andrej Ota wrote:

>>> Since this makes secured transport a minimal necessary requirement
>>> for any secure deployment, what benefit is there to try and find
>>> further examples of what can be mandated if none of the mandates
>>> would meaningfully change the end result?
>>

I wholeheartedly agree we should point these out and offer suggestions
to operators (and vendors) on how to best mitigate them.

> declare others explicitly unsecure.

That works for me.

> 
>>
>>    The alternative is to leave the reader to fend for himself. 
>> "Hmm... the authors didn't say this was bad, so let's do it!"
> 

Agreed, and I was not suggesting this.

> Handling secrets, passwords seem like good targets for this.

With the particular point of handling secrets and passwords, linking to
specific suggestions of this would be a plus, too.

> Would this be the right way or not really?

This sounds like the right approach to me.

Joe

---

From: Andrej Ota <[email-masked]>
Date: Wed, 11 Jul 2018 21:43:31 +0100

> On 10 Jul 2018, at 22:38, Joe Clarke <[email-masked]> wrote:
> 
>> 

Daytime job caught up with me, I'll start the writeup on the weekend.

Andrej.