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

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

To: aland@freeradius.org, stefan.winter@restena.lu, mikem@airspayce.com
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
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/3zVQlscU1IgDphb1wwSws799az8>
Subject: [radext] [Errata Held for Document Update] RFC7585 (4991)
Precedence: list

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:
http://www.rfc-editor.org/errata/eid4991

--------------------------------------
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
--------------

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.

--------------------------------------
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] [Errata Held for Document Update] RFC758… RFC Errata System