Re: [radext] Extended IDs

Peter Deacon <peterd@iea-software.com> Tue, 05 December 2017 04:26 UTC

Return-Path: <peterd@iea-software.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 1B63E124E15 for <radext@ietfa.amsl.com>; Mon, 4 Dec 2017 20:26:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 Y6H_CHcWkWpd for <radext@ietfa.amsl.com>; Mon, 4 Dec 2017 20:26:51 -0800 (PST)
Received: from aspen.iea-software.com (www.iea-software.com [70.89.142.193]) by ietfa.amsl.com (Postfix) with ESMTP id 624EA120454 for <radext@ietf.org>; Mon, 4 Dec 2017 20:26:51 -0800 (PST)
Received: from smurf (unverified [10.0.3.195]) by aspen.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id <B0006061205@aspen.iea-software.com>; Mon, 4 Dec 2017 20:26:51 -0800
Date: Mon, 04 Dec 2017 20:26:53 -0800
From: Peter Deacon <peterd@iea-software.com>
To: "Jakob Heitz (jheitz)" <jheitz@cisco.com>
cc: "radext@ietf.org" <radext@ietf.org>
In-Reply-To: <8DE62B3C-D2FA-4467-9CCE-7F8D039B87E2@cisco.com>
Message-ID: <alpine.WNT.2.21.1.1712041849350.2252@smurf>
References: <fef698a5-9802-c9be-04d7-1e869651c988@restena.lu> <dfd0ff02-c9e8-7253-4fb4-1e6def3e93b2@restena.lu> <8BD2C2F2-D42E-4B84-8F86-3A803160DD74@cisco.com> <b6ed7a87de434ea4a39f584a92e933b9@XCH-ALN-014.cisco.com>, <285C5C94-578E-4293-81A2-9D73E1105ABE@deployingradius.com> <8DE62B3C-D2FA-4467-9CCE-7F8D039B87E2@cisco.com>
User-Agent: Alpine 2.21.1 (WNT 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/Xft70rfQnY5K_aTcNmsm_wrv-ls>
Subject: Re: [radext] Extended IDs
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: Tue, 05 Dec 2017 04:26:53 -0000

On Fri, 1 Dec 2017, Jakob Heitz (jheitz) wrote:

> What if the quantum computers turn out to live up to their promises? 
> Then we can throw out all this authentication stuff and decide to not 
> share our Ethernets with the attackers instead. No more request 
> authenticator.

RADIUS security already lost cause no matter what :(

Best practice for many years - use a secure transport and or RADIUS over 
(D)TLS.  Regardless of selected security option in all cases operation of 
authenticator is maintained.

> The request authenticator is already overloaded. It may be used for the 
> CHAP challenge. Now, you want another overload?

Authenticator currently also used for at least following:

Tunnel Passwords
Message-Authenticator
PAP
CHAP
MPPE Keys

Clearly no possibility of authenticator ever changing in RADIUS protocol 
without creation of an incompatible replacement.  In event of an 
incompatible replacement there would be no need for either of these two 
drafts.

I am aware of no practical downside to "Overloading".

regards,
Peter