Subject: [OPSAWG] Secdir last call review of draft-ietf-opsawg-tacacs-13

From: Joseph Salowey via Datatracker <[email-masked]>
Date: Sun, 21 Apr 2019 20:49:11 -0700

Reviewer: Joseph Salowey
Review result: Serious Issues

As the draft mentions the MD5 based stream cipher used by TACACS+ is 
completely insecure.  I think there is too much discussion in the security
considerations that may lead one to think that in some cases it provides
sufficient protection.

Section 10.1 -
There have been plenty of analysis of the problems with the TACACS+ message
protection.  This section should just simply say the encryption/obfuscation
mechanism provides no integrity protection, no privacy protection and no replay
protection.  An attacker with access to the data stream should be assumed to be
able to read and modify all TACACS+ packets.  There are just too many flaws to
to enumerate in this document and the rest of the information in this section
is wrong or incomplete at best.

Section 10.2 -
Why not MUST NOT for TAC_PLUS_AUTHEN_STATUS_FOLLOW?  Is this really still used?

Section 10.2, 10.3, 10.4 -
You can probably replace most of these sections with
"TACACS+ MUST be used with an addition security mechanism to protection of the
communication such as IPSEC or a secure network such as described in 10.5. "

Section 10.5.1 and 10.5.2 -
Why should I care about secrets if they are just providing obfuscation?   Are
you relying on these secrets for something other than obfuscation?

Section 10.5.3 -
Use "less weak" instead of stronger when referring to CHAP, MS-CHAP, and
MSCHAPv2.   Its pretty debatable how much better they are than plaintext
passwords.

---

From: Randy Bush <[email-masked]>
Date: Sun, 21 Apr 2019 20:56:52 -0700

> "TACACS+ MUST be used with an addition security mechanism to
> protection of the communication such as IPSEC or a secure network such
> as described in 10.5. "

not operationaly viable

randy

---

From: Andrej Ota <[email-masked]>
Date: Mon, 22 Apr 2019 19:24:17 +0100

Hi Joseph,

Thank you for taking time to review the document. Answers are in-line.

> On 22 Apr 2019, at 04:49, Joseph Salowey via Datatracker <[email-masked]> wrote:
> 
> Reviewer: Joseph Salowey

Agreed to replace the section with a simple statement that obfuscation provides no integrity or replay protection. I'm assuming this refers just to 10.1 and not the whole of 10.

I think we should still press the point that everyone MUST use obfuscation as even though the privacy is almost non-existent, it's still slightly better than plain-text and ROT13.

> Why not MUST NOT for TAC_PLUS_AUTHEN_STATUS_FOLLOW?  Is this really still used?

I think Douglas is best positioned to answer this question.

> communication such as IPSEC or a secure network such as described in 10.5. "

Agreed.

> you relying on these secrets for something other than obfuscation?

Shared secrets also serve to "authenticate" a NAS to a server and vice versa.

Which may or may not matter when we state that secure transport MUST be used. I would like to err on the safe side because mistakes happen and sometimes unauthorized devices do connect to otherwise secured networks - intentionally or unintentionally (lab devices and similar come to my mind).

> MSCHAPv2.   Its pretty debatable how much better they are than plaintext

I think "less weak" is acceptable.

When you wrote that their value is debatable, did that refer to safety of the authentication session (as in it can be successfully attacked), to ability of a network attacker (active or passive) to deduce the user's password, or both?

My understanding is that they're still viable for the purpose of limiting the loss of user's password from MiTM attacks. If I'm wrong about this, let me know so we can be explicit about it in the document as well.

Andrej.

---

From: Joseph Salowey <[email-masked]>
Date: Mon, 22 Apr 2019 14:19:14 -0700

On Mon, Apr 22, 2019 at 11:24 AM Andrej Ota <[email-masked]> wrote:

> Agreed to replace the section with a simple statement that obfuscation
> provides no integrity or replay protection. I'm assuming this refers just
> to 10.1 and not the whole of 10.
>
> [Joe] I think you could probably replace a large portion of 10.2, 3 and 4
as well.

> I think we should still press the point that everyone MUST use obfuscation
> as even though the privacy is almost non-existent, it's still slightly
> better than plain-text and ROT13.
>
> [Joe] The current mechanism is roughly equivalent to ROT13 when compared
to current encryption mechanisms.   I don't think making it a must helps
confidentiality, perhaps it helps with authentication below.

> Which may or may not matter when we state that secure transport MUST be
> used. I would like to err on the safe side because mistakes happen and
> sometimes unauthorized devices do connect to otherwise secured networks -
> intentionally or unintentionally (lab devices and similar come to my mind).
>
>
[Joe] I don't think this section talks about authentication as a goal at
all.   If this is a goal it should be stated.   There will still be some
limitations here in that an attacker who can observe the communication will
be able to forge and replay messages.   I think it could be useful to
detect misconfiguration,  but there should to be some other mechanism in
place to provide stronger authentication.

> When you wrote that their value is debatable, did that refer to safety of
> the authentication session (as in it can be successfully attacked), to
> ability of a network attacker (active or passive) to deduce the user's
> password, or both?
>
> My understanding is that they're still viable for the purpose of limiting
> the loss of user's password from MiTM attacks. If I'm wrong about this, let
> me know so we can be explicit about it in the document as well.
>
>
[Joe] If an attacker can obtain the challenge and response in these
mechanisms they can typically carry out an offline dictionary attack to
recover the password.  They're unsafe to use without a transport that
provides confidentiality.

---

From: Randy Bush <[email-masked]>
Date: Mon, 22 Apr 2019 18:24:56 -0700

>> Agreed to replace the section with a simple statement that
>> obfuscation provides no integrity or replay protection. I'm assuming
>> this refers just to 10.1 and not the whole of 10.
>>

hyperbole is not constructive

creaky as it is, this is an informational draft which is documenting an
extremely widely used and distributed protocol.  no one is gonna change
millions of devices and thousands of servers for tweaks.  no one moves
for a 10% improvement, especially if there is no functional improvement.

we need to document it so we can put this in the can and move forward to
modernizing it.  then, if we have a seriously functionally improved and
modernized protocol, we will start the 42 year process of rolling it
out.

randy

---

From: joel jaeggli <[email-masked]>
Date: Tue, 23 Apr 2019 01:03:19 -0700

>> protection of the communication such as IPSEC or a secure network such

I don't deploy tacacs+ plus anymore, but when I did, concerted efforts
were in place to insure that the management network and it's traffic
inclusive of the tacacs traffic remained isolated from our production
network as well as the internet as whole. that's more or less in keeping
with the sentiments of 10.5. securiting it with ah or esp ipsec isn't
going to to happen except in the context of route based vpns.

> randy
> 
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg
>