Re: [radext] New Version Notification for draft-henry-radext-stable-mac-identifier-00.txt

lionel.morand@orange.com Wed, 17 November 2021 10:41 UTC

Return-Path: <lionel.morand@orange.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 195233A0777 for <radext@ietfa.amsl.com>; Wed, 17 Nov 2021 02:41:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com
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 HH5zI6xu1BEx for <radext@ietfa.amsl.com>; Wed, 17 Nov 2021 02:41:10 -0800 (PST)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62EE83A0B3A for <radext@ietf.org>; Wed, 17 Nov 2021 02:41:10 -0800 (PST)
Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by opfedar25.francetelecom.fr (ESMTP service) with ESMTPS id 4HvKGX3PfLz8ts5; Wed, 17 Nov 2021 11:41:08 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1637145668; bh=ZsQqTGr/VWO0fnVb/F/aFzeMsk2FOM8b7pZuP/EqH9M=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=KMGpaPivEchR6mth8rMDv2C951OFpY/Pltea2Q6cky8FPm5xl2BFqXPa4zA6y89kz X+3iYZBXMY8A23Diz09hS5HtVUU2VnWcZC45R5OY4/6+SsBL/h4B/mcgK3yaKIwITM 3VIXhCXvl0gODFDPoF0yTDIheYmWZKjuXEhiIctT0tn8rNV/JYokX64A8grXYvPdDB C0Rsprqyb+zMPHPlxwgYun8cDgaS2px37s4YsZGaYy7KHgpOuMQ1tS9gGXuViNAYdW 1JSN2tL7VzQPCyxbxjrer9lKWwv5nHwtKD2Yd65HizJxKF4cR/hGm05zepeICZDyIs vTWTq2h5+djjg==
From: lionel.morand@orange.com
To: Alan DeKok <aland@deployingradius.com>, Bernard Aboba <bernard.aboba@gmail.com>
CC: "radext@ietf.org" <radext@ietf.org>, "Nancy Cam-Winget (ncamwing)" <ncamwing=40cisco.com@dmarc.ietf.org>, "Jerome Henry (jerhenry)" <jerhenry@cisco.com>
Thread-Topic: [radext] New Version Notification for draft-henry-radext-stable-mac-identifier-00.txt
Thread-Index: AQHXvtaeheiDKBqv10uFhsI6k1hHNKv4m6mAgAEpXYCAABZEgIAAAtQAgA3NdcA=
Date: Wed, 17 Nov 2021 10:41:07 +0000
Message-ID: <24224_1637145668_6194DC44_24224_211_5_fc4ddd09513d44b1b4c15dfb5c155345@orange.com>
References: <800563F0-0675-4B19-8286-E03589F2B64D@deployingradius.com> <7E1500CE-0320-4DB4-9615-604D4EC5E39E@gmail.com> <6A131BFA-597D-4DB9-8D92-F808B04FD205@deployingradius.com>
In-Reply-To: <6A131BFA-597D-4DB9-8D92-F808B04FD205@deployingradius.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Enabled=true; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_SetDate=2021-11-17T10:41:06Z; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Method=Standard; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Name=Orange_restricted_external.2; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_SiteId=90c7a20a-f34b-40bf-bc48-b9253b6f5d20; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_ContentBits=2
x-originating-ip: [10.115.26.50]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/uv1VkuuChGziuWTZ8PSXNkZPHtY>
Subject: Re: [radext] New Version Notification for draft-henry-radext-stable-mac-identifier-00.txt
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 17 Nov 2021 10:41:16 -0000

Hi,

First, it is true that this draft should be rather discussed in OPSAWG, as RADEXT is nearly dead.

Now, as the discussed has started, I agree with the comments raised by Bernard on the problem statement.

>From a solution point of view, if the goal of the SMI attribute is to link consecutive authentication phases to the same user using different MAC address, why not just rely on the Acct-Multi-Session-Id used in the accounting messages to link together the multiple sessions?

Regards,

Lionel


Orange Restricted

> -----Message d'origine-----
> De : radext <radext-bounces@ietf.org> De la part de Alan DeKok
> Envoyé : lundi 8 novembre 2021 16:36
> À : Bernard Aboba <bernard.aboba@gmail.com>
> Cc : radext@ietf.org; Nancy Cam-Winget (ncamwing)
> <ncamwing=40cisco.com@dmarc.ietf.org>; Jerome Henry (jerhenry)
> <jerhenry@cisco.com>
> Objet : Re: [radext] New Version Notification for draft-henry-radext-stable-mac-
> identifier-00.txt
> 
> On Nov 8, 2021, at 10:25 AM, Bernard Aboba <bernard.aboba@gmail.com> wrote:
> > The problem is not clearly stated.
> 
>   Agreed.
> 
> > There are issues created by changing MAC addresses that could affect the user
> experience. The document mentions mapping of the MAC address to assigned IP
> addresses.
> 
>   " Continuity might include for example obtaining the same IP address from the
> DHCP server"
> 
>   If the same IP is assigned based on SMI and not RMC MAC, then that sort of
> negates the reason to use random MAC addresses.  You can tell it's the "same"
> machine, because it has the same IP address.
> 
> > I would note that the point of randomized MAC addresses is to reduce the ability
> to track users and devices. EAP supports both machine and user authentication
> and lately there have been efforts to protect those identifiers from exposure in
> clear text so as to limit tracking. Presumably similar concerns would exist about
> any machine identifier.
> 
>   I see it as useful to have a unique device identifier, which is visible only to the
> device and to the RADIUS server.  Ideally, this identifier shouldn't be visible to
> anyone else in the network.
> 
>  The document implies that changes will need to be made to the Ethernet / radio
> layer:
> 
>   "Additionally, once a protected link has been established between the client and
> the AP/WLC, as in 2.1, the client requests from the NAS a stable identifier or
> provides to the NAS a stable identifier."
> 
>   This process requires involvement from the IEEE, in addition to the IETF.  I'm not
> sure why using a stable identifier requires changes to the lower-layer protocols.
> 
>   TBH, the identifier could just be put it in a TLS extension.   Require TLS 1.3 for
> security, and that's it.  Have the device generate a random 128-bit identifier.  No
> negotiation is necessary.
> 
>   A similar method is already being proposed in
> https://datatracker.ietf.org/doc/html/draft-friel-tls-eap-dpp-01
> 
>   Alan DeKok.
> 
> _______________________________________________
> radext mailing list
> radext@ietf.org
> https://www.ietf.org/mailman/listinfo/radext

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.