IETF Logo Mail Archive

Re: [radext] Proposed new charter text

Sam Hartman <hartmans@painless-security.com> Mon, 23 March 2015 23:21 UTC

Return-Path: <hartmans@painless-security.com>
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E8301A040C for <radext@ietfa.amsl.com>; Mon, 23 Mar 2015 16:21:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 QFbFYfwDcnNE for <radext@ietfa.amsl.com>; Mon, 23 Mar 2015 16:21:50 -0700 (PDT)
Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5FEE1A03A6 for <radext@ietf.org>; Mon, 23 Mar 2015 16:21:50 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 72C1920675; Mon, 23 Mar 2015 19:19:42 -0400 (EDT)
Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1rzbcCAmBw1t; Mon, 23 Mar 2015 19:19:41 -0400 (EDT)
Received: from carter-zimmerman.suchdamage.org (c-50-177-26-195.hsd1.ma.comcast.net [50.177.26.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Mon, 23 Mar 2015 19:19:41 -0400 (EDT)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 719CF87201; Mon, 23 Mar 2015 19:21:17 -0400 (EDT)
From: Sam Hartman <hartmans@painless-security.com>
To: Alan DeKok <aland@deployingradius.com>
References: <5502B836.5000100@restena.lu> <alpine.WNT.2.20.1.1503221133420.3600@SMURF> <9C712CB9-7834-4049-9318-54E769F7661D@deployingradius.com> <alpine.WNT.2.20.1.1503221518060.3600@SMURF> <2DB68EA1-97A6-4263-9E7F-9BD24B567C7A@deployingradius.com> <alpine.WNT.2.20.1.1503221852040.3600@SMURF> <5FA970CC-2E05-4EFC-8AE6-840D334B28E4@deployingradius.com> <alpine.WNT.2.20.1.1503230923000.3600@SMURF> <1A6EF1EA-3412-4AAA-9646-3FD18EC0C4E4@deployingradius.com>
Date: Mon, 23 Mar 2015 19:21:17 -0400
In-Reply-To: <1A6EF1EA-3412-4AAA-9646-3FD18EC0C4E4@deployingradius.com> (Alan DeKok's message of "Mon, 23 Mar 2015 17:38:52 -0500")
Message-ID: <tsl4mpbb8r6.fsf@mit.edu>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/radext/3_ncIkUYJc41HzADgSopISwWb28>
Cc: radext@ietf.org, Peter Deacon <peterd@iea-software.com>
Subject: Re: [radext] Proposed new charter text
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Mon, 23 Mar 2015 23:21:52 -0000

>>>>> "Alan" == Alan DeKok <aland@deployingradius.com> writes:


    Alan>   i.e. what you’re saying is that there is a requirement for
    Alan> home server A to NOT be allowed to disconnect users for home
    Alan> server B in a visited network.  That is a *new* requirement,
    Alan> which doesn’t negate my comments above.

    Alan>   I want to solve one problem at a time.  Operator-Name and
    Alan> Operator-NAS-Identifier are sufficient to get the packet to
    Alan> the visited NAS.  Your earlier comments seemed to say that
    Alan> they were NOT sufficient, which is what was unclear.


I think solving this requirement would be necessary for moving COA to
the standards track or removing the health warning in 5176.

I'm fine not solving that problem provided that we have a fairly serious
health warning on this draft.
For this and other reasons COA massively fails to meet our current
security expectations for standards track.

--Sam

v2.23.0 | Report a Bug | By Email