IETF Logo Mail Archive

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

Alexander Clouter <alex+ietf@coremem.com> Wed, 26 July 2023 19:05 UTC

Return-Path: <alex+ietf@coremem.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 1A204C15198D for <radext@ietfa.amsl.com>; Wed, 26 Jul 2023 12:05:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.106
X-Spam-Level:
X-Spam-Status: No, score=-7.106 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_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=coremem.com header.b="TnEjUK4F"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="OhEcHuJv"
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 A7NIG0FgFaDU for <radext@ietfa.amsl.com>; Wed, 26 Jul 2023 12:05:21 -0700 (PDT)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (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 89F13C151531 for <radext@ietf.org>; Wed, 26 Jul 2023 12:05:21 -0700 (PDT)
Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id DDCAF5C0101; Wed, 26 Jul 2023 15:05:20 -0400 (EDT)
Received: from imap46 ([10.202.2.96]) by compute5.internal (MEProxy); Wed, 26 Jul 2023 15:05:20 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=coremem.com; h= cc:cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to; s=fm2; t=1690398320; x=1690484720; bh=ic iQjgI2X5IEM/4P6rishrjstAgRE57nQKKMUkIdKNI=; b=TnEjUK4FKRA78w4/W1 u9lE8kDvLEsTohQYOYrLG9UveizDRauKcbLEsUSUOsUFsv/gp4+rk9calV/7WsM5 r/cZRlHjm0yTo2QMcfoqIRReDlLT5XUvdJF7NhOeMqee6EADt532+4FNw/UNjVe+ D5n+TZ5M5RcmBtPGaKi1jILpAjDhqi5g1CkLzX2FRiHlJRXoebiHx9LU79sKH6bF f93hd55TdOl4TE/wuupOsFyc8ZWwxVSHMWSo/3FGvLxOES9KpmVQkUhsFIJ4TeB0 Wg/++NHG0bjd0/DnJDrh20EvWvVQloT/BNBM4uuuenCHFepLqC/bbcItbUTzorZW meFQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; t=1690398320; x=1690484720; bh=iciQjgI2X5IEM /4P6rishrjstAgRE57nQKKMUkIdKNI=; b=OhEcHuJvaaEVY/G47iQ9FPXeeu7C5 j27fVCB2kUU+eR70cKm7lHng6wdMDt7Y/m3cgCKuEDlUiG50X/6p/cqTpcgEQtLh PeP2p2hcJFT1b0rKUQ+T72xmhRoj3XTo/q7xGl2exhG6EZKOGgl9WRH7MVnTFSYX 5Vf7783INsl7urFSK5qhZorOr5NMmcMYoVfjd9YAt3XROzxx8E3AjiwSpzkeEZg5 JZLGa5DaZ2kPG5FZRK4HA4Di1uS0niM6lcRwGAtT99j3oteoFC7nCwhsR/HBuLIq Zbmt/1t1EgD0GiyLhk4YUYP2M594vCJTFXbhMa9UKzlMfqCrHQEIrZLxQ==
X-ME-Sender: <xms:cG7BZGezPiromGZq2dUIkxHU7gGDIzaRgYeTlO75iXmjdc0imRHJyA> <xme:cG7BZAMJy07i1mRv1CVcHrSmOlp_kg2GP2HytZ0ic4pT2kFZZgpBSri2Pyft7e32N Pd3FBKHwKzLCsbBmg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedriedvgddufedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvfevufgtsehttdertderredtnecuhfhrohhmpedftehl vgigrghnuggvrhcuvehlohhuthgvrhdfuceorghlvgigodhivghtfhestghorhgvmhgvmh drtghomheqnecuggftrfgrthhtvghrnhepveegheejueevkeevvdfhheeuudefheegudeu tdelleeiteehgeffieettddugfdunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrg hmpehmrghilhhfrhhomheprghlvgigodhivghtfhestghorhgvmhgvmhdrtghomh
X-ME-Proxy: <xmx:cG7BZHjgr9bE32jNgCRnN5IxkU8uaCxdMDWETFudNI_bXTq7LDO4vA> <xmx:cG7BZD_PEbD8xcqpb3gaPDQFniIUV719bubpq-GoBrK4WNgQRtUY9A> <xmx:cG7BZCucH-Rvv4qA_CMTbwzNmLwiklYvLCjPgElZoomtz0tdCW8Wcw> <xmx:cG7BZHXjdfJmpSFik60-muKtryo-KAURYlLm5cdHhTiV0dWXfFNzlA>
Feedback-ID: ie3614602:Fastmail
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 815EB2A20085; Wed, 26 Jul 2023 15:05:20 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.9.0-alpha0-592-ga9d4a09b4b-fm-defalarms-20230725.001-ga9d4a09b
Mime-Version: 1.0
Message-Id: <e5ac439a-9777-47c1-8eaa-6914b0d12610@app.fastmail.com>
In-Reply-To: <076501d9bfe8$61d13a00$2573ae00$@gmail.com>
References: <06c301d9bfc0$e07154d0$a153fe70$@gmail.com> <5390176A-A8D1-40E5-AA3B-9008328650F9@gmail.com> <076501d9bfe8$61d13a00$2573ae00$@gmail.com>
Date: Wed, 26 Jul 2023 20:04:59 +0100
From: Alexander Clouter <alex+ietf@coremem.com>
To: "josh.howlett" <josh.howlett@gmail.com>, Margaret Cullen <mrcullen42@gmail.com>
Cc: Alan DeKok <aland@deployingradius.com>, radext@ietf.org
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/kjL0SX60K0LD73lBw9_hVWFp3QI>
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 19:05:26 -0000

On Wed, 26 Jul 2023, at 18:41, josh.howlett@gmail.com wrote:
>> 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.
>
> I'm not sure I do agree with that :-) because there are lawful and
> legitimate reasons for IDPs and access providers to want to do that. If CUI
> doesn't meet these needs,  it is trivial to create a VSA that does...

I mean, if you require this and already doing that, you may as well just expose User-Name in the Access-Accept.

I also work in AdTech when not packet pushing, nothing good for the user comes from exposing data to different entities in this way.

I think having a CUI that is unique per visiting site, a 1:1 mapping of the user and slowly changing over time is a really good balance.

For legal situations, I would suspect any requirements could be reworked to be fully handled at the IdP end and the visiting sites do not need to be exposed to this kind of data.

Cheers

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