Re: [secdir] Secdir last call review of draft-ietf-opsawg-tacacs-13

Andrej Ota <andrej@ota.si> Mon, 22 April 2019 18:24 UTC

Return-Path: <andrej@ota.si>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB0EE120132; Mon, 22 Apr 2019 11:24:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.701
X-Spam-Level:
X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral (1024-bit key) reason="invalid (public key: does not support hash algorithm 'sha256')" header.d=ota.si
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b2KuenUapQTv; Mon, 22 Apr 2019 11:24:26 -0700 (PDT)
Received: from mta2.toshio.eu (mta2.toshio.eu [IPv6:2001:470:99f7::b423]) by ietfa.amsl.com (Postfix) with ESMTP id 2F17F120092; Mon, 22 Apr 2019 11:24:25 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mta2.toshio.eu (Postfix) with ESMTP id A94DC17829; Mon, 22 Apr 2019 18:24:01 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ota.si; h= message-id:references:content-transfer-encoding:date:date :in-reply-to:from:from:subject:subject:mime-version:content-type :content-type:received; s=toshio; t=1555957439; x=1557771840; bh=m/Mzp39GuiHtPxN4cRJdy1V3oRT1Ihpllg7fkp5DD/I=; b=rpu+j6kgzMDK LdgRrKFAROpsf/AeevznKriWwFqQFe1hk70Irwr+gaXPErNDhVFSuiIvqu4yVPok +4Vl8X6D//3j2qF7kJHVR+Aecg5KhgVXo112vZZSOyJIJCRpxUuKzfr1Ngzp/yRl ieZpfJztuSY4U4US8tdyNg3mRw42EkE=
X-Virus-Scanned: amavisd-new at toshio.org
Received: from mta2.toshio.eu ([89.143.197.195]) by localhost (srv-fe-3.dom.ota.si [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id pd99ivsENu02; Mon, 22 Apr 2019 18:23:59 +0000 (UTC)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Andrej Ota <andrej@ota.si>
In-Reply-To: <155590495142.9736.10585624358883108199@ietfa.amsl.com>
Date: Mon, 22 Apr 2019 19:24:17 +0100
Cc: secdir@ietf.org, opsawg@ietf.org, iesg@ietf.org, draft-ietf-opsawg-tacacs.all@ietf.org
Content-Transfer-Encoding: quoted-printable
References: <155590495142.9736.10585624358883108199@ietfa.amsl.com>
To: Joseph Salowey <joe@salowey.net>
Message-Id: <20190422182358.B69FB17821@mta2.toshio.eu>
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/UgtsSfh1RaauNoMRi87FRqtI0YI>
Subject: Re: [secdir] Secdir last call review of draft-ietf-opsawg-tacacs-13
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
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 18:24:29 -0000

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 <noreply@ietf.org> wrote:
> 
> 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.

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.

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

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

Agreed.

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

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


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

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.