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

From: Rick van Rein <[email-masked]>
Date: Thu, 10 Mar 2022 07:03:55 +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: Alan DeKok <[email-masked]>
Date: Thu, 10 Mar 2022 08:39:38 -0500

On Mar 10, 2022, at 2:03 AM, Rick van Rein <[email-masked]> wrote:

  So far as I know DIME is mostly done.  There's no new work being planned.

> https://datatracker.ietf.org/doc/html/draft-vanrein-internetwide-realm-crossover

  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.

  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 "[email-masked]", 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, 

  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: Rick van Rein <[email-masked]>
Date: Fri, 11 Mar 2022 07:28:31 +0000

Hello Alan,

Thanks!

>  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

>   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 contro…

Yes.

>   RFC 7542 Section 3 explicitly allows for routing to be done on a portion of the the domain name, a system gets "[email-masked]", and has a route for "example.com".  The users request is then rout…

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.

>   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.

>    home domain for that realm.

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

Thanks,
 -Rick

---

From: Alan DeKok <[email-masked]>
Date: Fri, 11 Mar 2022 08:48:33 -0500

> 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.

>   needs to express the domain, so the root of the grammar tree is

  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.

> 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.

> Autch, really?

  Sorry, typo. The utf8-realm is a domain name, which is case INsensitive.   Please ignore the typo.

  Alan DeKok.