Re: [radext] Extended IDs

Stefan Winter <stefan.winter@restena.lu> Thu, 14 December 2017 14:39 UTC

Return-Path: <stefan.winter@restena.lu>
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 0969C126C89 for <radext@ietfa.amsl.com>; Thu, 14 Dec 2017 06:39:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 utLlPfriNprt for <radext@ietfa.amsl.com>; Thu, 14 Dec 2017 06:39:01 -0800 (PST)
Received: from smtprelay.restena.lu (smtprelay.restena.lu [158.64.1.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 465621201F2 for <radext@ietf.org>; Thu, 14 Dec 2017 06:39:01 -0800 (PST)
Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 48BDE43A65 for <radext@ietf.org>; Thu, 14 Dec 2017 15:38:59 +0100 (CET)
To: radext@ietf.org
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> <alpine.WNT.2.21.1.1712041849350.2252@smurf> <c75160a5-1196-bdbd-f313-108085ea0c37@restena.lu> <D65692C4.E13AA%acee@cisco.com>
From: Stefan Winter <stefan.winter@restena.lu>
Organization: RESTENA
Message-ID: <cf5f59f1-c2ba-9dad-7ce0-c2afdd8e55e4@restena.lu>
Date: Thu, 14 Dec 2017 15:38:59 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0
MIME-Version: 1.0
In-Reply-To: <D65692C4.E13AA%acee@cisco.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Language: lb-LU
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/1H2rr83nHGlPcLLdoERkl26Qdcs>
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: Thu, 14 Dec 2017 14:39:03 -0000

Hello,

> I believe you are speaking as a contributor and not as a chair when making
> technical contributions to this discussion (last two E-mails).

Your belief if wrong. There are two obvious reasons:

- I stated "as a chair" when beginning my mails
- I am not a contributor to either of the two drafts

Greetings,

Stefan Winter

>
> Thanks,
> Acee 
>
> On 12/13/17, 2:22 AM, "radext on behalf of Stefan Winter"
> <radext-bounces@ietf.org on behalf of stefan.winter@restena.lu> wrote:
>
>> Hello,
>>
>> again as a chair:
>>
>> regarding the question of whether overloading of Request-Authenticator
>> should be considered harmful, I think the message from Peter below best
>> summarises the deployed reality in RADIUS.
>>
>> Basically, it makes clear that the decision to overload
>> Message-Authenticator or not is not on our table. That decision has been
>> taken ages ago, by this working group, and for a good number of RADIUS
>> attributes.
>>
>> So, for the discussion at hand, fears about overloading the
>> Request-Authenticator can safely be considered a non-argument.
>>
>> Greetings,
>>
>> Stefan Winter
>>
>>> 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
>>>
>> _______________________________________________
>> radext mailing list
>> radext@ietf.org
>> https://www.ietf.org/mailman/listinfo/radext