If the goal is not to improve identity assurance of an EAP server then what is this best practice change actually for?
From: Alan DeKok <al...@deployingradius.com> Date: Monday, November 18, 2019 at 10:34 AM To: Cappalli, Tim (Aruba) <t...@hpe.com> Cc: EMU WG <emu@ietf.org> Subject: Re: [Emu] Best practices for supplicants and authenticators > On Nov 18, 2019, at 10:22 AM, Cappalli, Tim (Aruba) <t...@hpe.com> wrote: > > So again, if NAIRealm is not bound to an organization’s public domain name, I never suggested that or implied it. I'm not sure why it's relevant. > how does a public CA prove ownership of an NAIRealm? How is this different > than ESSID? I had hoped that my point was clear. The requirement would be for the NAIReam to be in the same domain as rest of the certificate. Anything else makes zero sense. i.e. if the certificate is from "example.org", then the NAIRealm should be "example.org", or any other name within that domain. Such as "radius.example.org" > I don’t see how this improves assurance of a server identity. No one proposed the position you're opposing, so the conclusion above is irrelevant. On the other hand, if the requirement is that the NAIRealm be the domain name, then it makes perfect sense, and it's useful. We can't use existing fields to derive the NAIRealm. The common name is typically an email address and *not* a domain name. The various DNS fields are DNS host names (FQDNs), and not domain names. We can *suggest* that supplicants can check these fields. But it involves parsing them, and deriving *implicit* meaning from them. In contrast, an NAIRealm field is *explicit* meaning, that doesn't require additional derivation. I think that explicit statements of intent are useful. I don't see why there's any controversy about this. Alan DeKok.
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
