Re: [Dime] Dime WG at IETF 113 / Vienna ??

Rick van Rein <rick@openfortress.nl> Fri, 11 March 2022 07:28 UTC

Return-Path: <vanrein@vanrein.org>
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 133DE3A00E4 for <dime@ietfa.amsl.com>; Thu, 10 Mar 2022 23:28:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.659
X-Spam-Level:
X-Spam-Status: No, score=-6.659 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.248, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kpnmail.nl
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iQtt0oJ2gvzN for <dime@ietfa.amsl.com>; Thu, 10 Mar 2022 23:28:39 -0800 (PST)
Received: from ewsoutbound.kpnmail.nl (ewsoutbound.kpnmail.nl [195.121.94.185]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 889093A00E0 for <dime@ietf.org>; Thu, 10 Mar 2022 23:28:35 -0800 (PST)
X-KPN-MessageId: d3e9fb00-a10c-11ec-8338-005056999439
Received: from smtp.kpnmail.nl (unknown [10.31.155.5]) by ewsoutbound.so.kpn.org (Halon) with ESMTPS id d3e9fb00-a10c-11ec-8338-005056999439; Fri, 11 Mar 2022 08:28:20 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kpnmail.nl; s=kpnmail01; h=content-type:mime-version:message-id:subject:to:from:date; bh=VXRiWxOIZYXg8mpW6JePGjqCAf6iAknKrAJFdx9Uk5I=; b=MG6e1j+KJH4fAJAUI3StUc+ayrJfSRKRIHOYfJdO867ZKBGh0u4XgL7Hi1SUQdYDEowDlKm0nETFS Gq9XXzPSp3nbhXoyBZbSOa7HdWkPNPOt/yBGOHM039/k7cN48McPkmoyXRpjujtMZcqcPhaQj1m19C g+UCTL3CNXlWtzI0=
X-KPN-VerifiedSender: No
X-CMASSUN: 33|NHxe3z/DHsrEcFgzZ3JnngLikjp/bCdNDxrXqDOqYMATnqbz18gH2L8b7Y+Qtag EZm0s2eYMADGMpBm7LQMXCg==
X-Originating-IP: 83.161.146.46
Received: from fame.vanrein.org (phantom.vanrein.org [83.161.146.46]) by smtp.xs4all.nl (Halon) with ESMTPSA id da8dd761-a10c-11ec-807e-00505699b758; Fri, 11 Mar 2022 08:28:32 +0100 (CET)
Received: by fame.vanrein.org (Postfix, from userid 1000) id E7C1F3007A; Fri, 11 Mar 2022 07:28:31 +0000 (UTC)
Date: Fri, 11 Mar 2022 07:28:31 +0000
From: Rick van Rein <rick@openfortress.nl>
To: Alan DeKok <aland@deployingradius.com>
Cc: Diameter Maint/Ext <dime@ietf.org>, adriaan@cnossos.nl, henri@mansoft.nl
Message-ID: <20220311072831.GC28768@openfortress.nl>
References: <20220310070355.GC24851@openfortress.nl> <4ADABF6A-51D7-4018-99B6-D4A42C0A9777@deployingradius.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <4ADABF6A-51D7-4018-99B6-D4A42C0A9777@deployingradius.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dime/s2zYC-jxhyj1hPQ07MKAhc7sxRg>
Subject: Re: [Dime] Dime WG at IETF 113 / Vienna ??
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dime/>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Mar 2022 07:28:45 -0000

Hello Alan,

Thanks!

>   Section 3 says:
> 
>    However, the NAI
>    defaults to realm-internal use but BYOID always needs to express the
>    domain, so the root of the grammar tree is different:
> 
>  The "realm-internal" phrase isn't defined anywhere.  From what I can guess, this claim isn't correct.

Ah, the term was used informally.  I am talking of a name without
domain, like "fred".  I will clarify this in the text:

   However, the NAI can be just utf8-username whereas BYOID always
   needs to express the domain, so the root of the grammar tree is
   different:

>   RFC 7542 forbids the use of non-domain NAIs, e.g. "fred@sales".

Yes.

>   RFC 7542 allows for the use of domain names which can be resolved publicly (example.com), or ones which don't need to be resolved publicly (internal.example.com).  It's up to the domain to control which one is used.

Yes.

>   RFC 7542 Section 3 explicitly allows for routing to be done on a portion of the the domain name, a system gets "fred@internal.example.com", and has a route for "example.com".  The users request is then routed to "example.com".

Yes.

>   So there appears to be no need for any new definitions.  Just use the format and methods which have already been defined.  Inter-domain auth routing is a solved problem.

The only reason for the change is to _require_ inter-domain auth routing,
and avoid intra-domain routing.

>  The problem which isn't solved is *why* people would do it.

Every site that says "login with your Google / Facebook account"
shows that it is tempting to use an identity provider to avoid
local accounts.  We'd rather facilitate things from a domain
under our own control than to delegate decisions on account access
to such data-hungry parties.

>   Section 3 of your document also says:
> 
>    The utf8-username and utf8-realm are both considered to be case-
>    insensitive, 
> 
>   This is not correct.  The utf8-realm is case sensitive,

Autch, really?  I know that Kerberos5 does that, and it is terribly
confusing because DNS does not.  I need to look into that, I did not
even check it (as you can tell).  Thanks for pointing it out!

>   i.e. the uff8-username is explicitly defined to be site-local.  See Section 2.4:

Yes, for the utf8-username that is true.  We define a more specific
example and can add that notion for the use in Realm Crossover.  This
is a _profile_ of a NAI, not a copy of what's been written.

>    Interpretation of the username part of the NAI depends on the realm
>    in question.  Therefore, the utf8-username portion SHOULD be treated
>    as opaque data when processed by nodes that are not a part of the
>    home domain for that realm.

...in general software, yes.  In Realm Crossover we add information.


Thanks,
 -Rick