[OPSAWG] Roman Danyliw's Discuss on draft-ietf-opsawg-tacacs-13: (with DISCUSS and COMMENT)
Roman Danyliw via Datatracker <noreply@ietf.org> Wed, 15 May 2019 19:12 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: opsawg@ietf.org
Delivered-To: opsawg@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A099412001B; Wed, 15 May 2019 12:12:50 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Roman Danyliw via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-opsawg-tacacs@ietf.org, Joe Clarke <jclarke@cisco.com>, opsawg-chairs@ietf.org, opsawg-chairs@ietf.org, jclarke@cisco.com, opsawg@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.96.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Roman Danyliw <rdd@cert.org>
Message-ID: <155794757064.30599.16805992272677304176.idtracker@ietfa.amsl.com>
Date: Wed, 15 May 2019 12:12:50 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/LQ-klalA7V-f10aI8msleCN2Vac>
Subject: [OPSAWG] Roman Danyliw's Discuss on draft-ietf-opsawg-tacacs-13: (with DISCUSS and COMMENT)
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.29
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 May 2019 19:12:51 -0000
Roman Danyliw has entered the following ballot position for draft-ietf-opsawg-tacacs-13: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-tacacs/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- (1) I appreciate the deliberate and thoughtful attempt in this section to enumerate the possible risks/attacks and mitigations of the protocol as is. In addition to the top-level risks in Section 10.1, I can see the value of maintaining symmetry between Sections 5+10.2; 6+10.3 and 7+10.4. In the spirit of the middle ground this draft is trying to realize (document the as-is, but highlight the issues), I have the following feedback: (a) Section 10.1. I recommend replacing the first three paragraphs of Section 10.1 (“TACACS+ protocol does not …”, “While the protocol …”, and “Even though …”) with the following text synthesized from Joe Salowey’s LC review (https://mailarchive.ietf.org/arch/msg/secdir/rsqrNbVEKph1RdWh836Ard73pHs) and the current introduction: TACACS+ protocol does not include a security mechanism that would meet modern-day requirements. These security mechanisms would be best referred to as “obfuscation” and not “encryption” since they provide no meaningful integrity, privacy or replay protection. An attacker with access to the data stream should be assumed to be able to read and modify all TACACS+ packets. Without mitigation, a range of risks such as the following are possible: Accounting information may be modified by the man-in-the-middle attacker, making such logs unsuitable and untrustable for auditing purposes. 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 obfuscated body. (b) I recommend finding an alternative home and strengthening the text “For this reason, deployments SHOULD NOT use connections with TAC_PLUS_UNENCRYPTED_FLAG, as mentioned in the Best Practices section (Section 10.5)”. It seemed odd to mix deployment guidance in a list of risks as currently written. I take Andrej Ota’s point from https://mailarchive.ietf.org/arch/msg/secdir/UgtsSfh1RaauNoMRi87FRqtI0YI that there is no harm in requiring the obfuscation, such as it is. Furthermore, why couldn’t this be MUST NOT use? (c) Section 10.5.3. I concur with the SECDIR recommendation and the follow-up discussion with Andrej Ota per https://mailarchive.ietf.org/arch/msg/secdir/UgtsSfh1RaauNoMRi87FRqtI0YI which would: s/stronger authentication/less weak/ (2) Section 10.2. I’m confused by the deprecation of TAC_PLUS_AUTHEN_STATUS_FOLLOW but a seemingly weaker “SHOULD NOT be used in modern deployments”. I was expecting a MUST NOT. (3) Section 10.4. Why shouldn’t accounting sessions also use secure transport per 10.5 (like 10.3 and 10.4) given the risks outlined in the text? I was expecting to see this section open with “Accounting Session SHOULD be used via a secure transport (see Best Practices section (Section 10.5))". ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- (1) Editorial Nits: ** Section 10.5.3. Typo. s/administraots/administrators/ ** Global. Various places in the document have an extra space between the end of a reference and the closing period. Recommend: s/] ./]./g (2) I endorse Mirja and Deborah’s point that strong text is needed in Section 1 to state that this document is describing the current deployment of the protocol which has serious security issues.
- [OPSAWG] Roman Danyliw's Discuss on draft-ietf-op… Roman Danyliw via Datatracker
- Re: [OPSAWG] Roman Danyliw's Discuss on draft-iet… Douglas Gash (dcmgash)
- Re: [OPSAWG] Roman Danyliw's Discuss on draft-iet… Douglas Gash (dcmgash)
- Re: [OPSAWG] Roman Danyliw's Discuss on draft-iet… Warren Kumari