[secdir] Secdir last call review of draft-ietf-opsawg-tacacs-13
Joseph Salowey via Datatracker <noreply@ietf.org> Mon, 22 April 2019 03:49 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: secdir@ietf.org
Delivered-To: secdir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 78C601201EC; Sun, 21 Apr 2019 20:49:11 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Joseph Salowey via Datatracker <noreply@ietf.org>
To: secdir@ietf.org
Cc: opsawg@ietf.org, iesg@ietf.org, draft-ietf-opsawg-tacacs.all@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.95.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Joseph Salowey <joe@salowey.net>
Message-ID: <155590495142.9736.10585624358883108199@ietfa.amsl.com>
Date: Sun, 21 Apr 2019 20:49:11 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/rsqrNbVEKph1RdWh836Ard73pHs>
Subject: [secdir] Secdir last call review of draft-ietf-opsawg-tacacs-13
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Apr 2019 03:49:12 -0000
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.
- [secdir] Secdir last call review of draft-ietf-op… Joseph Salowey via Datatracker
- Re: [secdir] [OPSAWG] Secdir last call review of … Randy Bush
- Re: [secdir] Secdir last call review of draft-iet… Andrej Ota
- Re: [secdir] Secdir last call review of draft-iet… Joseph Salowey
- Re: [secdir] [OPSAWG] Secdir last call review of … Randy Bush
- Re: [secdir] [OPSAWG] Secdir last call review of … joel jaeggli