Re: [radext] [Technical Errata Reported] RFC7585 (4991)

Alan DeKok <aland@deployingradius.com> Fri, 07 April 2017 15:38 UTC

Return-Path: <aland@deployingradius.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 CFEB11294BC for <radext@ietfa.amsl.com>; Fri, 7 Apr 2017 08:38:27 -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, SPF_PASS=-0.001, URIBL_BLOCKED=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 FolpDHp8KGO5 for <radext@ietfa.amsl.com>; Fri, 7 Apr 2017 08:38:25 -0700 (PDT)
Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id CB9A5127444 for <radext@ietf.org>; Fri, 7 Apr 2017 08:38:24 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 18CCB60B for <radext@ietf.org>; Fri, 7 Apr 2017 15:38:24 +0000 (UTC)
Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h6VHy-0qM--S for <radext@ietf.org>; Fri, 7 Apr 2017 15:38:24 +0000 (UTC)
Received: from [192.168.20.91] (CPEf4cc552207f0-CM00fc8dce0fa0.cpe.net.cable.rogers.com [99.230.129.191]) by mail.networkradius.com (Postfix) with ESMTPSA id AE831B1 for <radext@ietf.org>; Fri, 7 Apr 2017 15:38:23 +0000 (UTC)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alan DeKok <aland@deployingradius.com>
In-Reply-To: <20170407153616.79D17B80CE5@rfc-editor.org>
Date: Fri, 7 Apr 2017 11:38:22 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <C9BE749E-277F-41A6-B01D-62EA46C4D65E@deployingradius.com>
References: <20170407153616.79D17B80CE5@rfc-editor.org>
To: radext@ietf.org
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/hQGuvDnFs7sfe8Bb2PE1SsoBfb4>
Subject: Re: [radext] [Technical Errata Reported] RFC7585 (4991)
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 07 Apr 2017 15:38:28 -0000

  Me causing trouble again. :(

  I think this all makes sense, and I didn't see anywhere in the RFC were these issues were discussed.

> On Apr 7, 2017, at 11:36 AM, RFC Errata System <rfc-editor@rfc-editor.org> wrote:
> 
> The following errata report has been submitted for RFC7585,
> "Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS Based on the Network Access Identifier (NAI)".
> 
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=7585&eid=4991
> 
> --------------------------------------
> Type: Technical
> Reported by: Alan DeKok <aland@freeradius.org>
> 
> Section: GLOBAL
> 
> Original Text
> -------------
> 
> 
> Corrected Text
> --------------
> 
> 
> Notes
> -----
> The document describes how to look up realms, but doesn't describe what to do after that.  i.e. are the lookups cached? Are the lookups done for every request that comes in?
> 
> This gives little guidance for an implementor.
> 
> I suggest leveraging the "logical AAA routing table" described in RFC 7542 Section 3.  In short form:
> 
> * a client MUST maintain a table of known dynamic realms.
> 
> * the table MUST be keyed by the realm name, and the contents MUST be server-specific information as described in RFC 7542 Section 3
> 
> * when a realm is being looked up, the realm SHOULD be inserted into the table with a "pending" flag, so subsequent requests during the lookup process do not cause additional lookups to be made
> 
> * if server validation fails, the realm SHOULD be updated with a "failed" state and a TTL, so that subsequent requests do not cause additional lookups for a period of time.  No server information should be stored for this entry. i.e. the realm is marked as "failed", the corresponding server MUST NOT be marked as "failed".  This prevents attacks where a malicious actor could point their realm to an unknowing third-party server, and cause poorly implemented proxies to mark it "failed".
> 
> * if server validation succeeds, the realm MUST be updated with a "live" state (and a TTL), so that subsequent requests go to the same server without additional lookups
> 
> *  if server validation succeeds, all realms in the TLS "subject alternative names" presented by the server SHOULD be inserted into the realm table, all pointing to the same server definition, so that subsequent requests for those other realms do not cause additional lookups to be made.
> 
> * servers which have been dynamically looked up MUST NOT be added to any global pool of servers.  i.e. the lookup is always "realm -> server", and not "There's a known server at this IP address"
> 
> I thought we had a short discussion of some of these topics on RADEXT, but I can't find it in the archives.
> 
> I think these comments are substantial enough to warrant "wait for document update".  I just wanted to ensure they weren't lost.
> 
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> can log in to change the status and edit the report, if necessary. 
> 
> --------------------------------------
> RFC7585 (draft-ietf-radext-dynamic-discovery-15)
> --------------------------------------
> Title               : Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS Based on the Network Access Identifier (NAI)
> Publication Date    : October 2015
> Author(s)           : S. Winter, M. McCauley
> Category            : EXPERIMENTAL
> Source              : RADIUS EXTensions
> Area                : Operations and Management
> Stream              : IETF
> Verifying Party     : IESG
> 
> _______________________________________________
> radext mailing list
> radext@ietf.org
> https://www.ietf.org/mailman/listinfo/radext