[radext] [Errata Held for Document Update] RFC7585 (4991)

RFC Errata System <rfc-editor@rfc-editor.org> Thu, 27 July 2017 13:51 UTC

Return-Path: <wwwrun@rfc-editor.org>
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 0F2C1132167; Thu, 27 Jul 2017 06:51:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id TgDkJFHtdxZK; Thu, 27 Jul 2017 06:51:43 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6463120721; Thu, 27 Jul 2017 06:51:43 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id EF8EAB80C65; Thu, 27 Jul 2017 06:51:32 -0700 (PDT)
To: aland@freeradius.org, stefan.winter@restena.lu, mikem@airspayce.com
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: bclaise@cisco.com, iesg@ietf.org, radext@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset=UTF-8
Message-Id: <20170727135132.EF8EAB80C65@rfc-editor.org>
Date: Thu, 27 Jul 2017 06:51:32 -0700 (PDT)
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/3zVQlscU1IgDphb1wwSws799az8>
Subject: [radext] [Errata Held for Document Update] 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: Thu, 27 Jul 2017 13:51:45 -0000

The following errata report has been held for document update 
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:

Status: Held for Document Update
Type: Technical

Reported by: Alan DeKok <aland@freeradius.org>
Date Reported: 2017-04-07
Held by: Benoit Claise (IESG)

Section: GLOBAL

Original Text

Corrected Text

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.

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