From nobody Wed Mar 9 23:04:15 2022 Return-Path: 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 668D23A080A for ; Wed, 9 Mar 2022 23:04:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.659 X-Spam-Level: X-Spam-Status: No, score=-1.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_MSPIKE_H5=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=no 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 iUk1YOhrjvNG for ; Wed, 9 Mar 2022 23:04:02 -0800 (PST) Received: from ewsoutbound.kpnmail.nl (ewsoutbound.kpnmail.nl [195.121.94.168]) (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 033C53A07EC for ; Wed, 9 Mar 2022 23:03:57 -0800 (PST) X-KPN-MessageId: 3e4e73c4-a040-11ec-8f5a-005056aba152 Received: from smtp.kpnmail.nl (unknown [10.31.155.38]) by ewsoutbound.so.kpn.org (Halon) with ESMTPS id 3e4e73c4-a040-11ec-8f5a-005056aba152; Thu, 10 Mar 2022 08:03:52 +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=IAQXfFKdvLsZNhIHSLixHTX48VqgIxswmLyMc5lc9nk=; b=Q3HDI4w4hpqJyet8yQEgoQ9qFP5ep6ld/Woa8tSiiblW87+SpbahaWWUSbYkQDv+7XCW7Tp8vJQIy 6YVQIVtF2GbqyHD7u5EwAtwhGeyYXLryGH9YPgge43/b4gaK56u1iwj60OYebhYBEYZT8MXiZ8k+nV xEOyAxIqQt96vL5I= X-KPN-VerifiedSender: No X-CMASSUN: 33|gYPrq8AqwIVE1XWUH7KwLE6O38HulzuMIsSHgnl5C2z4dwHp+e6eyf4atqObkY4 BztRMepyNwqKls2p8zq/xZw== 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 3ff23c75-a040-11ec-9256-005056abf0db; Thu, 10 Mar 2022 08:03:55 +0100 (CET) Received: by fame.vanrein.org (Postfix, from userid 1000) id 35A7D2FB81; Thu, 10 Mar 2022 07:03:55 +0000 (UTC) Date: Thu, 10 Mar 2022 07:03:55 +0000 From: Rick van Rein To: Diameter Maint/Ext Cc: henri@mansoft.nl, adriaan@cnossos.nl Message-ID: <20220310070355.GC24851@openfortress.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Archived-At: Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2022 07:04:13 -0000 Hello Dime WG, I have defined a Diameter Extension, and need af RFC to acquire global AVP Codes. Is the Dime WG [remotely] present in Vienna? I have proposed the SASL embedding in Diameter at the Kitten WG, but the content may also be of interest to the Dime WG. Since the latter does not appear to be active anymore (?) my first inclination is to process this via Kitten WG, but not without at least mentioning it to Dime, of course. If you would like to [also] discuss this, please let me know! Cheers, Rick van Rein Henri Manson Adriaan de Groot Documents: https://datatracker.ietf.org/doc/html/draft-vanrein-internetwide-realm-crossover https://datatracker.ietf.org/doc/draft-vanrein-diameter-sasl/ Related: https://datatracker.ietf.org/doc/draft-vanrein-httpauth-sasl/06/ From nobody Thu Mar 10 05:39:54 2022 Return-Path: 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 AE3273A089C for ; Thu, 10 Mar 2022 05:39:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 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 FceealrOpRLS for ; Thu, 10 Mar 2022 05:39:47 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB97C3A0854 for ; Thu, 10 Mar 2022 05:39:46 -0800 (PST) Received: from smtpclient.apple (24-52-251-6.cable.teksavvy.com [24.52.251.6]) by mail.networkradius.com (Postfix) with ESMTPSA id 277354EF; Thu, 10 Mar 2022 13:39:39 +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 15.0 \(3693.60.0.1.1\)) From: Alan DeKok In-Reply-To: <20220310070355.GC24851@openfortress.nl> Date: Thu, 10 Mar 2022 08:39:38 -0500 Cc: Diameter Maint/Ext , adriaan@cnossos.nl, henri@mansoft.nl Content-Transfer-Encoding: quoted-printable Message-Id: <4ADABF6A-51D7-4018-99B6-D4A42C0A9777@deployingradius.com> References: <20220310070355.GC24851@openfortress.nl> To: Rick van Rein X-Mailer: Apple Mail (2.3693.60.0.1.1) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2022 13:39:53 -0000 On Mar 10, 2022, at 2:03 AM, Rick van Rein wrote: So far as I know DIME is mostly done. There's no new work being = planned. > Documents: > = https://datatracker.ietf.org/doc/html/draft-vanrein-internetwide-realm-cro= ssover 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. =46rom what I can = guess, this claim isn't correct. RFC 7542 forbids the use of non-domain NAIs, e.g. "fred@sales". 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. 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". 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 problem which isn't solved is *why* = people would do it. Section 3 of your document also says: The utf8-username and utf8-realm are both considered to be case- insensitive,=20 This is not correct. The utf8-realm is case sensitive, but RFC 7542 = Section 3 says: As noted earlier, intermediate nodes may not have access to the same locale information as the system that injected the NAI into the AAA routing systems. Therefore, almost all "case insensitive" comparisons can be wrong. i.e. the uff8-username is explicitly defined to be site-local. See = Section 2.4: 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. i.e. suggesting any content for the utf8-username is likely to not = succeed. > https://datatracker.ietf.org/doc/draft-vanrein-diameter-sasl/ I already commented on the feasibility of a Diameter-bases global = routing system in EMU a while ago. My opinions haven't changed since = then. If your proposal requires every domain to run a Diameter server, then = it's dead in the water. It's just not going to happen. Many people were pushing business-to-business roaming in the late = 1990s. It still hasn't happened. For ISPs and Telcos, it's taken them = ~15 years of work to see the value of something like OpenRoaming. History shows that no one sees a value in B2B roaming. I would = suggest concentrating on convincing people it has value, and also to = switch to technologies which have a hope of being deployed. Alan DeKok. From nobody Thu Mar 10 23:28:48 2022 Return-Path: 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 ; 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 ; 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 ; 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 To: Alan DeKok Cc: Diameter Maint/Ext , 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 From nobody Fri Mar 11 05:48:48 2022 Return-Path: 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 F31613A13AD for ; Fri, 11 Mar 2022 05:48:45 -0800 (PST) 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, 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 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 BRV6-FfwMQJI for ; Fri, 11 Mar 2022 05:48:40 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E83653A13B3 for ; Fri, 11 Mar 2022 05:48:39 -0800 (PST) Received: from smtpclient.apple (24-52-251-6.cable.teksavvy.com [24.52.251.6]) by mail.networkradius.com (Postfix) with ESMTPSA id 0F4A03A2; Fri, 11 Mar 2022 13:48:34 +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 15.0 \(3693.60.0.1.1\)) From: Alan DeKok In-Reply-To: <20220311072831.GC28768@openfortress.nl> Date: Fri, 11 Mar 2022 08:48:33 -0500 Cc: Diameter Maint/Ext , adriaan@cnossos.nl, henri@mansoft.nl Content-Transfer-Encoding: quoted-printable Message-Id: <3F7435B6-DE96-4963-BEAF-094CA1B7EAAC@deployingradius.com> References: <20220310070355.GC24851@openfortress.nl> <4ADABF6A-51D7-4018-99B6-D4A42C0A9777@deployingradius.com> <20220311072831.GC28768@openfortress.nl> To: Rick van Rein X-Mailer: Apple Mail (2.3693.60.0.1.1) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2022 13:48:46 -0000 On Mar 11, 2022, at 2:28 AM, Rick van Rein wrote: > Ah, the term was used informally. I am talking of a name without > domain, like "fred". I will clarify this in the text: OK. If the identity doesn't have a realm, then it can't be routed. > 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: Sure. It may be sufficient to just say "don't do that". RFC 7542 = allows NAIs without realms for historical purposes. But makes it clear = that if there's any AAA routing, the realm has to exist. > 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. While I agree, I've been fighting this battle for a long time. I've = moved on to other work. >> This is not correct. The utf8-realm is case sensitive, >=20 > Autch, really? Sorry, typo. The utf8-realm is a domain name, which is case = INsensitive. Please ignore the typo. Alan DeKok.