Re: [radext] Adam Roach's Discuss on draft-ietf-radext-coa-proxy-05: (with DISCUSS and COMMENT)

Adam Roach <adam@nostrum.com> Tue, 14 August 2018 17:44 UTC

Return-Path: <adam@nostrum.com>
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 E2F36130E92; Tue, 14 Aug 2018 10:44:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.88
X-Spam-Level:
X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 sjYP-U3khtxv; Tue, 14 Aug 2018 10:44:05 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 8D1021277C8; Tue, 14 Aug 2018 10:44:05 -0700 (PDT)
Received: from Orochi.local (c-73-206-50-7.hsd1.tx.comcast.net [73.206.50.7]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w7EHhnWb070678 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 14 Aug 2018 12:43:51 -0500 (CDT) (envelope-from adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host c-73-206-50-7.hsd1.tx.comcast.net [73.206.50.7] claimed to be Orochi.local
To: Alan DeKok <aland@deployingradius.com>
Cc: Winter Stefan <stefan.winter@restena.lu>, radext@ietf.org, The IESG <iesg@ietf.org>, draft-ietf-radext-coa-proxy@ietf.org, radext-chairs@ietf.org
References: <153421241151.25112.5942779659969287406.idtracker@ietfa.amsl.com> <DCBC0F8A-E486-4844-8C7A-CCDEBD41A0E4@deployingradius.com> <0d9cc14c-d065-87fa-5ea1-f76fde1c9c2f@nostrum.com> <B33A4595-EDBE-41C5-9FD6-5EEACB6EEDE4@deployingradius.com> <b6c70613-40b1-9c78-ec63-927ffdffa094@nostrum.com> <44429A5F-F978-4D7B-8330-C6A665E8BF53@deployingradius.com> <680f1611-e86a-abd1-fb5f-63f27a265226@nostrum.com> <E586556A-97FC-4719-9A76-9201477CEDD9@deployingradius.com>
From: Adam Roach <adam@nostrum.com>
Message-ID: <bb979dfc-8241-ffa1-876b-f833053d49e7@nostrum.com>
Date: Tue, 14 Aug 2018 12:43:49 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <E586556A-97FC-4719-9A76-9201477CEDD9@deployingradius.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/pU9LcpHZHBX6qu3v5OEbH3pi27g>
Subject: Re: [radext] Adam Roach's Discuss on draft-ietf-radext-coa-proxy-05: (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: Tue, 14 Aug 2018 17:44:07 -0000

On 8/14/18 12:31, Alan DeKok wrote:
>    Any security issues with the contents of Operator-NAS-Identifier are largely mitigated by the utter crap-fest that's the rest of RADIUS.  Which means that it doesn't really matter how the values of Operator-NAS-Identifier are created, stored, or used.


Perfect! That's what the document should say.

Mostly, I was taking issue with language that implies that there is some 
level of security being applied to this token, and that the guidance and 
mechanisms in this draft were sufficient to even allow doing so (see, 
e.g., my comment on field sizes). Securing this field would be fine, if 
done correctly. Leaving it unsecured -- as is done with similar 
information in Radius -- is fine also. It's the middle-ground of 
security theater -- and, in this case, RFC-2119-language normative 
security theater --  that I think is dangerous.

/a