IETF Logo Mail Archive

Re: [radext] CUI comments in "deprecating insecure transports"

Alan DeKok <aland@deployingradius.com> Wed, 26 July 2023 16:51 UTC

Return-Path: <aland@deployingradius.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 D8C04C1782BF for <radext@ietfa.amsl.com>; Wed, 26 Jul 2023 09:51:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z_1TbPqldZzJ for <radext@ietfa.amsl.com>; Wed, 26 Jul 2023 09:51:36 -0700 (PDT)
Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (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 ietfa.amsl.com (Postfix) with ESMTPS id 7C5D5C151064 for <radext@ietf.org>; Wed, 26 Jul 2023 09:51:06 -0700 (PDT)
Received: from smtpclient.apple (dhcp-8aa8.meeting.ietf.org [31.133.138.168]) by mail.networkradius.com (Postfix) with ESMTPSA id 8EF6151B; Wed, 26 Jul 2023 16:51:03 +0000 (UTC)
Authentication-Results: NetworkRADIUS; dmarc=none (p=none dis=none) header.from=deployingradius.com
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
From: Alan DeKok <aland@deployingradius.com>
In-Reply-To: <5390176A-A8D1-40E5-AA3B-9008328650F9@gmail.com>
Date: Wed, 26 Jul 2023 09:51:01 -0700
Cc: josh.howlett@gmail.com, radext@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <0D326753-2295-4FA9-B14E-06FE55C9AFB4@deployingradius.com>
References: <06c301d9bfc0$e07154d0$a153fe70$@gmail.com> <5390176A-A8D1-40E5-AA3B-9008328650F9@gmail.com>
To: Margaret Cullen <mrcullen42@gmail.com>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/_OBmQwC4BIA8y2t2zqLUOiPiNWY>
Subject: Re: [radext] CUI comments in "deprecating insecure transports"
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.39
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, 26 Jul 2023 16:51:40 -0000

On Jul 26, 2023, at 9:47 AM, Margaret Cullen <mrcullen42@gmail.com> wrote:
> I understand the value of using a single, unique CUI per user/service provider pair in application-level authentication, because the user may have persistent data or state associated with previous application sessions.

  I'm not sure what that information would be,  There is no persistent state provided to the user in RADIUS.  The only persistent network information which might exist is the association between MAC and IP address.  DHCP takes care of that.

> If so, we might want to say that the CUI MUST be unique per user/access provider pair, rather than unique per-session.

  That should be the minimum recommendation, I think.

> In either case, the IDP can store the user<->CUI mapping for later use, whether it is generated for each access provider or for each session, so that the user can be identified later, if necessary.
> 
> The important point is that the same CUI MUST not be sent to multiple access providers to identify the same user.  Hopefully we all agreed on that.

  Yes.

  Alan DeKok.

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