Re: [radext] Proposed charter text based on IETF-115 BoF

Bernard Aboba <bernard.aboba@gmail.com> Tue, 29 November 2022 23:32 UTC

Return-Path: <bernard.aboba@gmail.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 E76AEC14CF06 for <radext@ietfa.amsl.com>; Tue, 29 Nov 2022 15:32:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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=gmail.com
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 ld8Vkt090WG0 for <radext@ietfa.amsl.com>; Tue, 29 Nov 2022 15:32:32 -0800 (PST)
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE400C14CEE2 for <radext@ietf.org>; Tue, 29 Nov 2022 15:32:32 -0800 (PST)
Received: by mail-ej1-x631.google.com with SMTP id ha10so37553101ejb.3 for <radext@ietf.org>; Tue, 29 Nov 2022 15:32:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=qiwn7fZTNqiLLQAL0/BWUiGVOrBFX2AS1GEiImlzmiM=; b=PYt2XHIorYAKMsfix+mmElnLt2ma6oluspeUN4F+9mwr6e7p+fXTDD4CSPSwZ49/8Y JCXyWG8CIReF/Q0ZvEEXLCfXMQjZwXWOwnZxG/x78nK8mzQpAq6JEoTTMNmLWhLoHukz TneGZg2Q+G7K+napVcLiHLKgMrAMtbgHJoJ1Gk72XKEbQHeqmgBHpoeLEZZ5yzlqnoiT xXqpyxm3WZkjocOERrxYJmv5SLDJqz1cKKo44cpDFhx6QAtXhlXCQuyf87E+9UpnTG9e W3/E/xaoIFtKyFX5fM7lCFc7v1ZFkgIE+dxdggTBEoOLUYnE/pTDFc0Wgq1eZJUsUUMC QNxw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=qiwn7fZTNqiLLQAL0/BWUiGVOrBFX2AS1GEiImlzmiM=; b=X84XH370Z+gaQsI9f1N0toQe6aVKYaKoT4e2lu1yV/vvAeOUn4Zx4NBHQDG7ImjJmV Cz147SLCTpSiN2yhKj47ITsyO9fwzuKRpUImRNEeXfUTXPR4i62YBSZPbYf3xN8I5pZt g/SZ3t7K7JJJTwJ0nmQz/P2vo9SMEloMtStpW47lsG/cOYz64c/WnUXskxBHNf9p4R8W N4xPXe1eUWfnKywYP+j2bh2ohet2/DUJhKpJgFr89aP9nGdGeoZhtabF6aa3zexW8CXo bJMatPnRiB1aR4Dlh3hJlhFvb4RTEs36hfC4Xf+3wm3L2AFUVmnSCUjK900pyPlUW4me f56g==
X-Gm-Message-State: ANoB5pk1fM+xur2a75UGSrNQMdKlJ4dPyl3S+ahzHur5JhqyMRQM5XAg 4Prpnzv4n7DQu8VTQjZ93+blGT2LzM/WEHpNJwEga/I04jk/KQ==
X-Google-Smtp-Source: AA0mqf6azWVFARxEopa5BLesYT/+Vmwu7oO9ahVoRTZ4x8jjgr+PgZeCB/LT0gWKbRdkv0h9e1F2WhJlFlDDk1zpk8o=
X-Received: by 2002:a17:906:1188:b0:7b2:c594:2182 with SMTP id n8-20020a170906118800b007b2c5942182mr35844810eja.290.1669764750771; Tue, 29 Nov 2022 15:32:30 -0800 (PST)
MIME-Version: 1.0
References: <FD0507D4-2C1D-478A-97E0-ECEEF1A5613B@deployingradius.com> <EAAC2507-5D29-4453-8881-BC8D9D5314D8@deployingradius.com> <CAOW+2dsKg_H9f3zRUnanCpgGO+G=VPyxzWa9hsrCJCpsnoBsxA@mail.gmail.com> <7CB701B8-BD8F-4ADC-9265-12FC7EBE8FB6@deployingradius.com> <CAOW+2dtDkN3Hvk1vmuyJYGP9KS5WaGDenwQBb7-g12e6SxvEzw@mail.gmail.com> <05f4711f-4f9f-7bb6-e04f-b3c9ebc73202@dfn.de> <9e24bb0f-b12b-8235-3e88-65d4c59f205c@newtoncomputing.co.uk> <e94b8273-6189-efc4-dfa5-3ab3bacbdac6@dfn.de> <7cdb23d1-1d91-71ed-14ee-157315beb278@newtoncomputing.co.uk> <7604703a-075f-7ad6-9c85-24e9a0f845fb@dfn.de> <CAA7Lko9wSP0E8tSQwQ4uhud-f+OBZf6Nw-EGf0XqLPkg8vpN8A@mail.gmail.com> <6D8C428B-D837-4FFE-9739-99C7C20FF64D@deployingradius.com> <CAOW+2dvxo0cpg5+1W-Tyo=s3Ee7EGWFnn+GgW6juEous+6+dug@mail.gmail.com> <9388DD9A-7E92-4C52-8ED8-C36B6282820F@deployingradius.com> <CAOW+2dvc7mKbtzXb_SxBQDarTP_=GrOATvi-dui=giN6jn=ffA@mail.gmail.com> <A4EE4471-92C9-4A7A-AD0B-E2C56EFF8249@deployingradius.com> <cc61da67-e756-de20-aafa-e9485ae9ef57@uni-bremen.de> <CAA7Lko_bbpdVnfS6x3k56W0MnfQkfBxGTbVrViw4Td2J-0H_Nw@mail.gmail.com> <9A56812C-E840-4DF6-9D28-18EF528E79F2@deployingradius.com>
In-Reply-To: <9A56812C-E840-4DF6-9D28-18EF528E79F2@deployingradius.com>
From: Bernard Aboba <bernard.aboba@gmail.com>
Date: Tue, 29 Nov 2022 15:32:19 -0800
Message-ID: <CAOW+2ds6Q=1=9vtWK4oGttWDWg6Su4Lemq+nMugZdx29NdEgGw@mail.gmail.com>
To: Alan DeKok <aland@deployingradius.com>
Cc: radext@ietf.org
Content-Type: multipart/alternative; boundary="000000000000d40ab505eea46672"
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/VoBphmkiFK9EbzuvqARfsMHW4jc>
Subject: Re: [radext] Proposed charter text based on IETF-115 BoF
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: Tue, 29 Nov 2022 23:32:37 -0000

Alan said:

"But if Diameter doesn't see a need for an end-to-end security flag, then
I'm happy to leave it out of RADIUS."

[BA]  As with much of the original Diameter spec, the E2E security flag was
"overtaken by events".

In a system with proxies, the longer the chain gets and the more
domains are involved, the less assurance you have that the entire chain can
conform to any requirement.  The best way to ensure that any requirement is
met is to shorten the chain, if possible to only include only domains where
the requirement is acknowledged contractually.

E2E flags, or even spec SHOULDs and MUSTs don't provide any real assurance
if there is no business or contractual reason for nodes on the chain to
meet the requirement.

In particular, an E2E security flag isn't very useful when transport
security is rarely implemented.

On Tue, Nov 29, 2022 at 2:42 PM Alan DeKok <aland@deployingradius.com>
wrote:

> On Nov 29, 2022, at 1:10 PM, Heikki Vatiainen <hvn@radiatorsoftware.com>
> wrote:
> > Allowing forwarding with RADIUS/TLS has the downside that the flag would
> > be lost and it could result in RADIUS/UDP at some point if it is proxied
> > further.
> > Unless we find a way to include the Flag in "plain" RADIUS, but that
> > would also require all proxies to honor the new flag.
>
>   Yes.  The flag could be added as a new attribute.  Which may have
> utility outside of SRADIUS.
>
> > There's also the possibility that IPsec or some other method is used to
> securely forward RADIUS/UDP. This may not be easily visible for a Radius
> proxy. This could lead to a situation that the potential newly added flag
> is honoured while there's secure transport available.
>
>   I agree.
>
> > Regarding secure transport: The revised Diameter RFC says:
> > https://www.rfc-editor.org/rfc/rfc6733.html#section-1.1.3
> >    o  Simplified security requirements.  The use of a secured transport
> >       for exchanging Diameter messages remains mandatory.  However, TLS/
> >       TCP and DTLS/SCTP have become the primary methods of securing
> >       Diameter with IPsec as a secondary alternative.  See Section 13
> >       for details.  The support for the End-to-End security framework
> >       (E2E-Sequence AVP and 'P'-bit in the AVP header) has also been
> >       deprecated.
> >
> > The obsoleted RFC 3588 defined 'P'-bit as:
> >       The 'P' bit indicates the need for encryption for end-to-end
> security.
> >
> > A quick search didn't tell why the above changes were done, but if
> secure transport flag is considered, it might be useful to see what
> happened in Diameter's case.
>
>   Hmm... I don't recall following that discussion or why it happened.  But
> if Diameter doesn't see a need for an end-to-end security flag, then I'm
> happy to leave it out of RADIUS.
>
>   Alan DeKok.
>
> _______________________________________________
> radext mailing list
> radext@ietf.org
> https://www.ietf.org/mailman/listinfo/radext
>