IETF Logo Mail Archive

Re: [radext] Question about ALPN and "end to end" identifier

Alan DeKok <aland@deployingradius.com> Wed, 26 April 2023 13:45 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 0D724C151547 for <radext@ietfa.amsl.com>; Wed, 26 Apr 2023 06:45:04 -0700 (PDT)
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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 pZCJBvWa9E21 for <radext@ietfa.amsl.com>; Wed, 26 Apr 2023 06:44:59 -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 8E011C151538 for <radext@ietf.org>; Wed, 26 Apr 2023 06:44:58 -0700 (PDT)
Received: from smtpclient.apple (135-23-95-173.cpe.pppoe.ca [135.23.95.173]) by mail.networkradius.com (Postfix) with ESMTPSA id 574E32FF; Wed, 26 Apr 2023 13:44:54 +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: <02d001d97837$f6c1a300$e444e900$@gmail.com>
Date: Wed, 26 Apr 2023 09:44:52 -0400
Cc: Alexander Clouter <alex+ietf@coremem.com>, radext@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <6C35E4C5-4AEB-42D2-AEE3-62075C8E94FD@deployingradius.com>
References: <0fbeb2cb-198f-f56a-88fd-a63dc540cb5b@newtoncomputing.co.uk> <223B186E-7791-494D-8F55-B3AA64AF2CF9@gmail.com> <b9e409d5-3173-46d4-b474-af2f6be944e6@app.fastmail.com> <7943C2AC-255A-4891-BFC2-DAF91E77F37F@deployingradius.com> <45e839f2-f48e-4213-aa45-c0c1cafda032@app.fastmail.com> <23326E1C-DBD5-419A-80C4-3EB08C3FAF52@deployingradius.com> <0a9101d97218$453ae710$cfb0b530$@gmail.com> <F060F874-16D9-4EFB-8C5A-2756F6169E82@deployingradius.com> <0c1201d97394$1c136f10$543a4d30$@gmail.com> <8DE89FE3-ECA5-46B1-BF89-DDA68C5B01A9@deployingradius.com> <013a01d976bf$1ce8f300$56bad900$@gmail.com> <B47B720D-AA20-422D-B273-7D278ED77EAA@deployingradius.com> <01e401d97760$d29f6ed0$77de4c70$@gmail.com> <02d001d97837$f6c1a300$e444e900$@gmail.com>
To: josh.howlett@gmail.com
X-Mailer: Apple Mail (2.3696.120.41.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/cjkBxFR-UqYFk-o4ubtehwjEkIM>
Subject: Re: [radext] Question about ALPN and "end to end" identifier
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 Apr 2023 13:45:04 -0000

On Apr 26, 2023, at 8:09 AM, josh.howlett@gmail.com wrote:
> I have noticed some ambiguity here in the specs.
> 
> * RFC 2865 explicitly forbids anything in an Access-Reject except
> Proxy-State and Reply-Message
> * RFC 3579 appears to permit the use of Error-Cause in Access-Rejects, based
> on the table in section 3.3, although the text only refers to
> Access-Challenges
> * RFC 5080 touches on this in section 2.6.1, suggesting it is permissible
> without citing a reference
> * RFC 5176 itself doesn't state discuss Access-Rejects at all.
> 
> I think clarifying this in RADIUS1.1 might be helpful. Better error
> reporting would go some way to reducing troubleshooting complexity.

  I agree.  I'll update the document.

  Alan DeKok.

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