IETF Logo Mail Archive

[radext] Re: New I-D: draft-seralathan-radext-persistent-devid-00

Alan DeKok <alan.dekok@inkbridge.io> Tue, 26 May 2026 10:51 UTC

Return-Path: <alan.dekok@inkbridge.io>
X-Original-To: radext@mail2.ietf.org
Delivered-To: radext@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 0F901F51EFD6; Tue, 26 May 2026 03:51:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1779792668; bh=rZ3b+0yqo8vbBPV6maav6/BOXPqPGoLIwjOILKjdqf4=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=jtS1U/pZMiciPeJHfjlaS1brz0GvHVxgxOkAvJGCi8CovLqsSZDenKlwnb1N713Rl VAe/1keTdI6oVRA/7WzosX13V2m3WuOMq0+2Q0PJPkm4E55Udw3jc+dbDKlFtOLTHK SfNMEqPv21TmrHRHHeeBBNlT3FCceCsRJ48pAv0E=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=inkbridge.io header.b="ayvCD7pe"; dkim=pass (2048-bit key) header.d=inkbridge.io header.b="nGPUlGB9"
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ce_2OsgeU-zc; Tue, 26 May 2026 03:51:06 -0700 (PDT)
Received: from mail2.networkradius.com (mail2.networkradius.com [184.95.211.25]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 6E0E5F51EFCA; Tue, 26 May 2026 03:51:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=inkbridge.io; s=sep2024; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=09ySDXl67EAY5bQnW5IvUj2Ft2LpjVgqdL+aaWlyUmw=; b=ayvCD7pe2Qpq99ZAVwINm/RwAr PP0ehQ8ev2XUggBCCw+3WNvr4GC/uuIWippRKWTx3osZac3/UuHe2pfl8SUeSBHbS/Cr0uz19rW65 9nzQ0+hftEsHYvxExyR9EtbOkRhNH6+Sej5hMxkH+N2+5ZrrAzo6VqbRD08ruVV+kj07gQlZYUg6g Z7QNWE6uNF4y3zdOTWJErgHpIHAhxHOzrYSZF21XR7Wi2upR58p3P807avovNzWG/4koFKZImVhjA 3dYqBbcyJom9eL2dyrrnWvXpvVz/V7r1oeN9niOybcwuhXi+eKFCbioF7tfvn/zC3YbAB5nLJRtye qu7u2J+w==;
Received: from mail.servers.fr.internal.networkradius.com ([192.168.42.56]:50232 helo=mail.networkradius.com) by mail2.networkradius.com with esmtp (Exim 4.97) (envelope-from <alan.dekok@inkbridge.io>) id 1wRpNB-00000000XJI-2xUc; Tue, 26 May 2026 10:50:57 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inkbridge.io; s=sep2024; t=1779792657; bh=09ySDXl67EAY5bQnW5IvUj2Ft2LpjVgqdL+aaWlyUmw=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=nGPUlGB9gP4N2HmNWq6rukTZ9AKd5juXNI5DMXMLAR7I1ng0UiBkqTBI2ApzTSXz7 CD8ieT1XUmFNwFsv1nwS6Q+TslQNS3x1MvmJ4lXScwK75aV+es8Lvpb7Kt6WE6YhkM PSploShSDUw6i+fl5CY+97i7nObQG91TqbqyMc3yhxcBL4OTMFPI21zsOySW2bgRTA Ne/XTS86RHgSVXq3+KxUzGev0mkfM6PTMQJrSqnIPxIgIJ7wzrQg8rAV90u/KZ2Bx5 B1ZqzvwJmavI0bQeuaZeKskwDyhZ5undiGPhdx+mQSWRCSMsXF1QjU7gCadeBEESrz QPYTjT7dahiKA==
Received: from smtpclient.apple (24-246-4-149.cable.teksavvy.com [24.246.4.149]) by mail.networkradius.com (Postfix) with ESMTPSA id A53C826D; Tue, 26 May 2026 10:50:56 +0000 (UTC)
Content-Type: multipart/signed; boundary="Apple-Mail=_E860F503-BF12-427A-A689-8B391A7B047D"; protocol="application/pgp-signature"; micalg="pgp-sha256"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.700.81.1.4\))
From: Alan DeKok <alan.dekok@inkbridge.io>
In-Reply-To: <BYAPR11MB3768995A3F905845409EF032CC0B2@BYAPR11MB3768.namprd11.prod.outlook.com>
Date: Tue, 26 May 2026 06:50:44 -0400
Message-Id: <4C8F2356-BE1F-43AC-AC9A-3AAAE136D906@inkbridge.io>
References: <BYAPR11MB37689273BC46B447843F3516CC352@BYAPR11MB3768.namprd11.prod.outlook.com> <C035972D-A954-4449-B1AA-194C7954F27B@inkbridge.io> <BYAPR11MB3768995A3F905845409EF032CC0B2@BYAPR11MB3768.namprd11.prod.outlook.com>
To: "Premanand Seralathan (pseralat)" <pseralat=40cisco.com@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3826.700.81.1.4)
Message-ID-Hash: LZYHQZHD6PLKCBGJVAS3J6IINOYGGUED
X-Message-ID-Hash: LZYHQZHD6PLKCBGJVAS3J6IINOYGGUED
X-MailFrom: alan.dekok@inkbridge.io
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-radext.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: "radext@ietf.org" <radext@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [radext] Re: New I-D: draft-seralathan-radext-persistent-devid-00
List-Id: RADIUS EXTensions working group discussion list <radext.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/dwcHMWBNiKdh7_M_LSwMKllzTss>
List-Archive: <https://mailarchive.ietf.org/arch/browse/radext>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Owner: <mailto:radext-owner@ietf.org>
List-Post: <mailto:radext@ietf.org>
List-Subscribe: <mailto:radext-join@ietf.org>
List-Unsubscribe: <mailto:radext-leave@ietf.org>

On May 25, 2026, at 11:42 PM, Premanand Seralathan (pseralat) <pseralat=40cisco.com@dmarc.ietf.org> wrote:
> The NAS doesn't need to correlate across connections — the server does. On reconnect with a new MAC, the same certificate yields the same UUID server-side. The NAS caches Persistent-Device-Id for the current session, echoes it in accounting, and shares it with integrated platforms (profiling engines, location services) so they can identify the endpoint across MAC changes. Will clarify this in -01.

  Thanks.

  This functionality could be done by a RADIUS proxy, so the NAS doesn't have to be modified.  That would make it much easier to deploy.

  Alternately, since this proposal provides for device tracking, it could just be done with CUI.  i.e. instead of sending a new attribute, just send:

	Chargeable-User-Identity = <persistent-device-id>@<realm from User-Name>

  Or since most User-Names are "@realm" or "anonymous@realm", the IdP can reply with

	User-Name = <persistent-device-id>@<realm from User-Name>

  And then the functionality works, without changing anything else in RADIUS.  The main downside here is that there's no separate attribute for persistent device ID.  But I think the main goals of the document are met.

  Alan DeKok.

v2.45.0 | Report a Bug | By Email | System Status