Re: [secdir] 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: 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 08E6C1200B9 for <secdir@ietfa.amsl.com>; Mon, 22 Apr 2019 14:19:30 -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 Fsy9vpzdi9hZ for <secdir@ietfa.amsl.com>; Mon, 22 Apr 2019 14:19:27 -0700 (PDT)
Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (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 D6CF71200EB for <secdir@ietf.org>; Mon, 22 Apr 2019 14:19:26 -0700 (PDT)
Received: by mail-qk1-x72f.google.com with SMTP id c190so3540844qke.9 for <secdir@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=ty2qTr8g+9yc52S6Q09zGLX0a9jt+kEzh66TqRBUvz8DXUlXJZYwIUavbIZeKBZuCD sFyDUNZfNxXfVBTYRok6uaS6avoI+RmySixZfPgqIM1F46qDZYX37gNlpOfDf3OeKHNK TTFLEqZn/mcyIcxZdG9ylYEKR6kxhC97gXgbmnPug1C7JU26ZacgSMhTt4cRWHhGnb8w nFgy5IlMB0l3yEUc18cjWGCSLXL3pAqoUdnYf+KOjC0x09GxxbedNLidCXwSdIFyx3T6 TMCkPViFJ2P+tmyHUVHLutxZzNgdSD4i5OD54kX9yjKfLhEaJqfTa+Lie+kRxttJTavi /3HA==
X-Gm-Message-State: APjAAAVN8YR0g429Gkuo3BlO4DOuxlDRbfpcpBr7DwMSaIgv/Tr6VRUV jevthbRcMzvN6xLgs1zXZXazrx9q6X2GORLvowUZlA==
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/secdir/leWdRxfFUJ554GiQiGsMNi8jb3Q>
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 21:19:30 -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.