Re: [OPSAWG] Roman Danyliw's Discuss on draft-ietf-opsawg-tacacs-13: (with DISCUSS and COMMENT)

"Douglas Gash (dcmgash)" <dcmgash@cisco.com> Wed, 26 June 2019 03:52 UTC

Return-Path: <dcmgash@cisco.com>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E15D12061C; Tue, 25 Jun 2019 20:52:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=YsKdSLFL; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=jtXT6G9e
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 AAtgq-PeysAw; Tue, 25 Jun 2019 20:52:18 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73A81120122; Tue, 25 Jun 2019 20:52:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7124; q=dns/txt; s=iport; t=1561521138; x=1562730738; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ETm5ecu3pua8hfTGkJTNBPEsc5Q6lxj09M7l3QOcqEg=; b=YsKdSLFLK4WPMW0FviPvcszQVozVSN+FEqnAEHTMTEhEhmuUw9C34QmZ lU/c/ag6zHW9edmbTMlMFzLYDUrWGOa3Q+TjkyoQEBBRaiFZJlsqfHCls Iw65t99abO+iaS/znPQhUk3i5kLxeZk5m6wKvfWBtXorhC20XtXFXIHEX I=;
IronPort-PHdr: =?us-ascii?q?9a23=3AXGYVzBLrt8keNH51ydmcpTVXNCE6p7X5OBIU4Z?= =?us-ascii?q?M7irVIN76u5InmIFeBvad2lFGcW4Ld5roEkOfQv636EU04qZea+DFnEtRXUg?= =?us-ascii?q?Mdz8AfngguGsmAXEHwKfHjdCwSF8VZX1gj9Ha+YgBY?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BOAQC66xJd/5RdJa1lHAEBAQQBAQc?= =?us-ascii?q?EAQGBVgQBAQsBgUMkLANqVSAECyiEFYNHA45jgjaXXoFCgRADUwEJAQEBDAE?= =?us-ascii?q?BJQgCAQGEQAIXgl4jNwYOAQMBAQQBAQIBBW2KNwyFSwIEEhERDAEBNwEPAgE?= =?us-ascii?q?GAg4MAhkNAgICMBUQAgQBDQUigwABgWoDHQEOA4onkGACgTiIIzxxgTGCeQE?= =?us-ascii?q?BBYFGQYMAGIIRAwaBDCgBi10XgX+BECgME4JMPoJhAgECAYEqARECATWCczK?= =?us-ascii?q?CJowHgk6NT410CQKCFYZQiTCDaxuCKYcOhAuKDY0ogTCGB49bAgQCBAUCDgE?= =?us-ascii?q?BBYFmImdYEQhwFTsqAYJBgkEHMIM5hRSFPgFyAYEojhEBAQ?=
X-IronPort-AV: E=Sophos;i="5.63,418,1557187200"; d="scan'208";a="582383043"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 26 Jun 2019 03:52:16 +0000
Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by rcdn-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id x5Q3qGBY026384 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 26 Jun 2019 03:52:16 GMT
Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 25 Jun 2019 22:52:16 -0500
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 25 Jun 2019 22:52:15 -0500
Received: from NAM03-CO1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 25 Jun 2019 23:52:15 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ETm5ecu3pua8hfTGkJTNBPEsc5Q6lxj09M7l3QOcqEg=; b=jtXT6G9eALPrLPpE93wSbP8PDK8xl/YTBAjr7LykDCOGpzc8djKCadggTKkjU965r0XtLLyiegW/hf7pw/V/Gvm0e8NtTdKYfMSo4AJkb3XozmF4ItB1gt0XnYs5sRgRIWZ6I0XkoSbV38I2KkVOVElAbSdr2Fsujx1I+uaS7cM=
Received: from DM5PR11MB1322.namprd11.prod.outlook.com (10.168.104.140) by DM5PR11MB1740.namprd11.prod.outlook.com (10.175.91.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2008.16; Wed, 26 Jun 2019 03:52:13 +0000
Received: from DM5PR11MB1322.namprd11.prod.outlook.com ([fe80::3167:9c96:1d74:4fcd]) by DM5PR11MB1322.namprd11.prod.outlook.com ([fe80::3167:9c96:1d74:4fcd%2]) with mapi id 15.20.2008.018; Wed, 26 Jun 2019 03:52:13 +0000
From: "Douglas Gash (dcmgash)" <dcmgash@cisco.com>
To: Roman Danyliw <rdd@cert.org>, The IESG <iesg@ietf.org>
CC: "draft-ietf-opsawg-tacacs@ietf.org" <draft-ietf-opsawg-tacacs@ietf.org>, "Joe Clarke (jclarke)" <jclarke@cisco.com>, "opsawg-chairs@ietf.org" <opsawg-chairs@ietf.org>, "opsawg@ietf.org" <opsawg@ietf.org>
Thread-Topic: Roman Danyliw's Discuss on draft-ietf-opsawg-tacacs-13: (with DISCUSS and COMMENT)
Thread-Index: AQHVK9KJ0Dcjq/LsLk+2Gr7Hyqi/Jg==
Date: Wed, 26 Jun 2019 03:52:13 +0000
Message-ID: <1041E0FA-EBCB-4354-9C41-66768C7CF37A@cisco.com>
References: <155794757064.30599.16805992272677304176.idtracker@ietfa.amsl.com>
In-Reply-To: <155794757064.30599.16805992272677304176.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.26.0.170902
authentication-results: spf=none (sender IP is ) smtp.mailfrom=dcmgash@cisco.com;
x-originating-ip: [2001:420:c0c0:1008::12e]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: c8c926c9-0156-432a-dd69-08d6f9e9ac92
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM5PR11MB1740;
x-ms-traffictypediagnostic: DM5PR11MB1740:
x-ms-exchange-purlcount: 4
x-microsoft-antispam-prvs: <DM5PR11MB17405F12122D2C9BEF63C4E3B7E20@DM5PR11MB1740.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:7691;
x-forefront-prvs: 00808B16F3
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(376002)(346002)(396003)(136003)(366004)(51914003)(199004)(189003)(14444005)(54906003)(53936002)(58126008)(6486002)(99286004)(476003)(86362001)(478600001)(256004)(36756003)(229853002)(6436002)(110136005)(316002)(46003)(6506007)(6246003)(186003)(6512007)(102836004)(76176011)(6116002)(446003)(6306002)(11346002)(486006)(53546011)(33656002)(81166006)(4326008)(68736007)(966005)(25786009)(81156014)(2616005)(66476007)(2906002)(8676002)(7736002)(71200400001)(64756008)(5660300002)(66556008)(76116006)(71190400001)(8936002)(66946007)(561944003)(14454004)(91956017)(73956011)(66446008)(305945005); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR11MB1740; H:DM5PR11MB1322.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: HQCU4zoUtSInfyUsataaKfU6fPAKp1KO0EA1DDSuws6n7uztsw9Ai2VGNCNCN5nQOOOaS30jKsENonlde6o06Vzq7Vh6PpchFXyZO3js6IDZo8aRGykKgwFRKBJqi0YdEh0SFx0CKavgnm67vEZcp8zFgTdmv3K5ru7Jh5VvHRT1iT3oTALAfkdX6ficr5dbDDhtiCaM/jBJ92g7BS5Ewf4RbV84qb6mNtotlwuPvd4bIFghgxk7UHApM6qec4VhEKB7M+Oumtd9mRuPvIVglWBNmYuIKm+/08STRidNawB7+EMo6LUvl/abxCUi4EnyUzGGDqpiP2cXKrs6HDM9G+qBZ715U2107iuHIKTFkbuf0oe1M/bB4MR/+3zAHowJ7O1nvRmOYSq2yUPfzEn6+WmLMmnEMP+vdToAVrM8uKo=
Content-Type: text/plain; charset="utf-8"
Content-ID: <6464A3BCEDFB7A4D8A5A05C1A55E851C@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: c8c926c9-0156-432a-dd69-08d6f9e9ac92
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jun 2019 03:52:13.6265 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: dcmgash@cisco.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB1740
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.16, xch-aln-006.cisco.com
X-Outbound-Node: rcdn-core-12.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/E0iTLmX4_3q51eGn8bPDIo7od-o>
Subject: Re: [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
Precedence: list
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, 26 Jun 2019 03:52:22 -0000

Many thanks for the comments.

Please see responses from authors inline, marked “TA”. Action items from this mail to update the document are marked: [AI-TA] to mean: “action item for the authors”.

On 15/05/2019, 20:12, "Roman Danyliw via Datatracker" <noreply@ietf.org> wrote:

    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.

TA>  Many thanks, looks like a  sensible proposal [AI-TA]
    
    (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?

TA> Yes, I think we can move to MUST NOT, and we can remove this reference at this point  [AI-TA]
    
    (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/

TA> Agreed, We will update [AI-TA]
    
    (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.
    
TA> Agreed, We will update [AI-TA]

    (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))".
    
TA> We’ll bring this in line [AI-TA]
    
    ----------------------------------------------------------------------
    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
    
TA> Thanks, will fix [AI-TA]

    (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.
    
TA> Agreed, We will add [AI-TA]