Re: [radext] Ben Campbell's Discuss on draft-ietf-radext-coa-proxy-06: (with DISCUSS and COMMENT)

Alan DeKok <aland@freeradius.org> Thu, 16 August 2018 11:08 UTC

Return-Path: <aland@freeradius.org>
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83637130F00; Thu, 16 Aug 2018 04:08:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 6MinyjjX9Cw7; Thu, 16 Aug 2018 04:08:46 -0700 (PDT)
Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 162B8130EFF; Thu, 16 Aug 2018 04:08:46 -0700 (PDT)
Received: from [192.168.46.58] (198-84-237-221.cpe.teksavvy.com [198.84.237.221]) by mail.networkradius.com (Postfix) with ESMTPSA id 8262940D; Thu, 16 Aug 2018 11:08:44 +0000 (UTC)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/signed; boundary="Apple-Mail=_18B9E403-065F-4F7B-B0B9-FDE9648B3FFB"; protocol="application/pgp-signature"; micalg="pgp-sha256"
X-Pgp-Agent: GPGMail
From: Alan DeKok <aland@freeradius.org>
In-Reply-To: <A1A49AB9-ED90-4681-A7B4-9CFFDFEBFF8C@nostrum.com>
Date: Thu, 16 Aug 2018 07:08:42 -0400
Cc: The IESG <iesg@ietf.org>, draft-ietf-radext-coa-proxy@ietf.org, Winter Stefan <stefan.winter@restena.lu>, radext-chairs@ietf.org, radext@ietf.org
Message-Id: <458094D6-96C1-4EC1-9CDB-DFE47F5F5C4F@freeradius.org>
References: <153436290915.3118.1227345371925581329.idtracker@ietfa.amsl.com> <78BEFFD7-2B87-4EC1-A1A3-8BDD7AB97C5F@freeradius.org> <A1A49AB9-ED90-4681-A7B4-9CFFDFEBFF8C@nostrum.com>
To: Ben Campbell <ben@nostrum.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/Mc0FAirzqh7xMrCf6woK15e0UZ4>
Subject: Re: [radext] Ben Campbell's Discuss on draft-ietf-radext-coa-proxy-06: (with DISCUSS and COMMENT)
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: RADIUS EXTensions working group discussion list <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/radext/>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Aug 2018 11:08:49 -0000

On Aug 16, 2018, at 12:05 AM, Ben Campbell <ben@nostrum.com> wrote:
> What I had in mind was just a statement to the effect that, while this extension includes normative language, it is informational because it is based on RFC 5176, which is also informational.

  That makes sense.

> However, I do not understand your point that the applicability statement from 5176 does not apply to this draft. It b
> asically says that 5176 is informational because CoA has (or had) issues (security, architectural, etc) that made it inappropriate for standards track. Since this draft is fundamentally based on 5176, it seems like it would inherit those issues.

  Perhaps this is a matter of semantics.

  On one hand, any spec built on 5176 inherits it's properties, good or bad.  On the other hand, it would be inappropriate for the coa-proxy draft to have the same applicability text as 5176.  i.e. saying "this document is informational, because implementations of this document have issues".  That statement is simply false.

> Or do you think all those issues have been mitigated, either by this draft or others? (The answer is probably academic, in that it addresses the question about whether 5176 _should_ still be informational, which doesn’t change the fact that it _is_.)

  I think those issues are largely illusory, or have been mitigated since 5176 was published.  Since there is a complex topic, let me explain by quoting Section 1.1 of RFC 5176, and commenting on it:

  ...  While fixes are recommended,
   they cannot be made mandatory since this would be incompatible with
   existing implementations.

  I think we've moved on in the 10 years since that draft was published.  At this point, if implementations are insecure, it is entirely appropriate to mark them as non-compatible.

  RFC 5176 was *not* simply documenting a pre-existing proprietary protocol.  It was developed in the IETF, based on RFC 3576, which was also developed within the IETF.  The "compatibility with existing implementations" issue is a polite statement that there was no WG consensus to make it standards track.

  i.e. the vendors with incompatible / insecure implementations did not want their products to me marked as such.

   Existing implementations of this protocol do not support
   authorization checks, so that an ISP sharing a NAS with another ISP
   could disconnect or change authorizations for another ISP's users.

  That's called "trusting people you work with".  The cos-proxy document makes it clear that there are limited technical means to address abuses by trusted parties. The limited security of RADIUS is the root cause of this problem.  However, 20+ years of practice in roman environments shows that this trust is warranted.  Abuses have been negligible, or non-existent.

  The coa-proxy specification mandates not only reverse path checks, but *additional* checks not mentioned in 5176.  That would seem to mitigate the above security issues.

   Existing implementations utilize per-packet authentication and
   integrity protection algorithms with known weaknesses [MD5Attack].

 That statement is describing a fundamental property of RADIUS.  i.e. it could be applied to every single RADIUS specification, resulting in *zero* standards-track RADIUS specifications.

  i.e. I think it's safe to ignore that rationale as a reason for making the document Informational.

   Existing implementations lack replay protection.

 That statement is also describing a fundamental property of RADIUS.

   The approach taken with CoA commands in existing implementations
   results in a semantic ambiguity.  Existing implementations of the
   CoA-Request identify the affected session, as well as supply the
   authorization changes.  Since RADIUS Attributes included within
   existing implementations of the CoA-Request can be used for session
   identification or authorization change, it may not be clear which
   function a given attribute is serving.

  That statement is still true, and there was much discussion in the WG about it.  The WG refused even to make recommendations here, because vendors refused to have a spec that marked their implementations as incompatible.

  In practice, this ambiguity is not much of a problem.  The vendor documents what is needed, and RADIUS clients send it.

  In short, the reasons given in Section 1.1 of RFC 5176 are illusory in practice.  Or, they're a fundamental part of the RADIUS protocol, and applicable to all RADIUS specifications.

  Further, even if those reasons *are* true, issues of "compatibility with existing implementations" do not apply to the coa-proxy draft, because there are few existing implementations of it.  (i.e. FreeRADIUS, which does do sane things...)  On top of that, the coa-proxy draft leverages existing implementations... whatever they are.  And those implementations (while perhaps ambiguous) manifestly work.

  As such, IMHO, the applicability statement of RFC 5176 can be ignored in it's entirety.

  Alan DeKok.