[radext] Eric Rescorla's No Objection on draft-ietf-radext-coa-proxy-05: (with COMMENT)

Eric Rescorla <ekr@rtfm.com> Wed, 15 August 2018 15:15 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: radext@ietf.org
Delivered-To: radext@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4368D131031; Wed, 15 Aug 2018 08:15:07 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Eric Rescorla <ekr@rtfm.com>
To: "The IESG" <iesg@ietf.org>
Cc: radext@ietf.org, stefan.winter@restena.lu, radext-chairs@ietf.org, draft-ietf-radext-coa-proxy@ietf.org, Stefan Winter <stefan.winter@restena.lu>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.83.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <153434610726.14442.18102779548524907034.idtracker@ietfa.amsl.com>
Date: Wed, 15 Aug 2018 08:15:07 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/0XaqKMbNu6mkEb-rhYYEAqR9kX4>
Subject: [radext] Eric Rescorla's No Objection on draft-ietf-radext-coa-proxy-05: (with COMMENT)
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.27
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: Wed, 15 Aug 2018 15:15:10 -0000

Eric Rescorla has entered the following ballot position for
draft-ietf-radext-coa-proxy-05: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


Rich version of this review at:

I concur with Adam's DISCUSS (but marking no-objection to let him
manage this). Specifically, you need to describe what the security
expectations are for the Operator-NAS-Identifier. Need it be
unguessable? Should separate identifiers that refer to the same NAS be
unlinkable? "Cryptographically strong" is not a sufficiently specific
term to determine what the requirements are here.

S 6.
>      issues.
>      The Operator-NAS-Identifier SHOULD be created by the Visited Network
>      such that its contents are opaque to all other parties.  This ensures
>      that anyone observing unencrypted RADIUS traffic gains no information
>      about the internals of the Visited Network.

See above about the requirements here. Does there need to be an
unlinkable identifier each time?