Re: [OPSAWG] Secdir last call review of draft-ietf-opsawg-tacacs-13
Joseph Salowey <joe@salowey.net> Mon, 22 April 2019 21:19 UTC
Return-Path: <joe@salowey.net>
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 0677C120178 for <opsawg@ietfa.amsl.com>; Mon, 22 Apr 2019 14:19:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.20150623.gappssmtp.com
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 fO8aibci-lHs for <opsawg@ietfa.amsl.com>; Mon, 22 Apr 2019 14:19:30 -0700 (PDT)
Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF6E01200FC for <opsawg@ietf.org>; Mon, 22 Apr 2019 14:19:26 -0700 (PDT)
Received: by mail-qk1-x729.google.com with SMTP id n81so3440798qke.2 for <opsawg@ietf.org>; Mon, 22 Apr 2019 14:19:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=b2Si+H/Gt+CxCpKYL13cPo2PHRAIZrpyYkE6+jYorgI=; b=T8SNj8aLIVMTBlxB6pGQOnO2doywJUlUaYfqetWK4aASvWtvbS9R1sf8ySfEgTH951 9pSQq0M5n7needndRQ1pgTqd/tvDnlaDXZpxIn0/3Q0AnRa3ypXBqzD+Oi6LfT2ZE8Wo eV3wHyl4AGVDGKJvaRT+rwVJwEwbfC/fIn/RtsDI1SQH77EPaS94iScCaVmYnMJK0vaV rUsCTpvZ/UBxfblzPU++4x29RZRMjz+GCQ/6Fu/RlRWz2qBSTiDlNnBsk5gWxV3UNp+1 +SA/E1Nh9lsZiKi+I8Hxq/VsW4h0tDJtNNTg3yxL985h7w510xzmOYvKso1SNoOCGPsf IDzQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=b2Si+H/Gt+CxCpKYL13cPo2PHRAIZrpyYkE6+jYorgI=; b=QiOgWy748YGkOwuMv0oOOyThUwhBtgiDOr0qEct6rra0Akfvb6pwt07BOBlxlDJdwI UpNPI0AzhUSAtCh0JpnWwEnjZuySoF0tRWxESoyrtax4eQP2X3yGHSr2LvfX2R01YThm ryH4o/IsGbkXUzMVo9iDg592l2Tew+e8luUEX9HkbKTP6lJ1hjS+5YvcEQeGRhIO2wDO /UkbZCgPftSo5SgHr4Wo8RazRWxiN1tikMNPzmYym+UvI2Mb7po2NT0o2EpqV60LIVW5 tYlIB0CRFLNxBe1hikL9LfqL6hpgjV4y5AoWEQGKGnCNTWYXmklRLcwbkAbp8BvD3nAH EfLA==
X-Gm-Message-State: APjAAAU1UnX1qmQJe9inuLSPUcpzAs6nVBUSRMk54QixKDM4sPje3sZA r7qacjVutggdsUfpZ7bTd2PZ+ftVrXh8PyIQJZ9ADwk1hPc=
X-Google-Smtp-Source: APXvYqz0jXRhX/YuLLpsbZoUtdKNu/iQBOWW3BBQS3F70ec/YRi/zYIyPtPkfAQnqiVN4AIxMoJ0HFuc9ZiTFsm4go0=
X-Received: by 2002:a05:620a:16b5:: with SMTP id s21mr15685289qkj.321.1555967965806; Mon, 22 Apr 2019 14:19:25 -0700 (PDT)
MIME-Version: 1.0
References: <155590495142.9736.10585624358883108199@ietfa.amsl.com> <20190422182358.B69FB17821@mta2.toshio.eu>
In-Reply-To: <20190422182358.B69FB17821@mta2.toshio.eu>
From: Joseph Salowey <joe@salowey.net>
Date: Mon, 22 Apr 2019 14:19:14 -0700
Message-ID: <CAOgPGoB1GvQOTWPnTCLmOA=CWsc5znr-Y_Xr9jqmOEzJuepr3g@mail.gmail.com>
To: Andrej Ota <andrej@ota.si>
Cc: secdir <secdir@ietf.org>, opsawg@ietf.org, The IESG <iesg@ietf.org>, draft-ietf-opsawg-tacacs.all@ietf.org
Content-Type: multipart/alternative; boundary="000000000000e255c205872505e5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/oMWFY5jmAK-E4wHd7uQbgisKKqw>
Subject: Re: [OPSAWG] Secdir last call review of draft-ietf-opsawg-tacacs-13
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: Mon, 22 Apr 2019 21:19:33 -0000
On Mon, Apr 22, 2019 at 11:24 AM Andrej Ota <andrej@ota.si> wrote: > 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. > > [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. > > > > 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). > > [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. > > > > > 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. > > [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. > > > Andrej.
- [OPSAWG] Secdir last call review of draft-ietf-op… Joseph Salowey via Datatracker
- Re: [OPSAWG] Secdir last call review of draft-iet… Randy Bush
- Re: [OPSAWG] Secdir last call review of draft-iet… Andrej Ota
- Re: [OPSAWG] Secdir last call review of draft-iet… Joseph Salowey
- Re: [OPSAWG] Secdir last call review of draft-iet… Randy Bush
- Re: [OPSAWG] Secdir last call review of draft-iet… joel jaeggli