On Nov 19, 2019, at 10:40 PM, Owen Friel (ofriel) wrote:
>
> Assuming that NAIRealm is a registered domain as per RFC 7542, and thus
> public CAs can verify ownership, the goal / where we want to get to is:
>
> - CA may be a public CA and thus public CAs can be enabled by default in
>
practices for supplicants and authenticators
After the meeting earlier today, I made some notes on best practices for
supplicants and authenticators. I think it would be useful to have an official
WG document which gives guidance.
Background:
a) the current practice in TLS-based EAP methods
On Nov 18, 2019, at 11:01 AM, Cappalli, Tim (Aruba) wrote:
>
> So you’re saying an NAIRealm must be a publicly registered domain name? I
> agree, but just want to be crystal clear.
Yes. See RFC 7542. It defines the NAI in some detail.
Alan DeKok.
So you’re saying an NAIRealm must be a publicly registered domain name? I
agree, but just want to be crystal clear.
tim
From: Alan DeKok
Date: Monday, November 18, 2019 at 10:57 AM
To: Cappalli, Tim (Aruba)
Cc: EMU WG
Subject: Re: [Emu] Best practices for supplicants and authenticators
configuration, that
doesn’t change the requirement to manually configure the supplicant. So what
are we actually trying to improve here?
From: Alan DeKok
Date: Monday, November 18, 2019 at 10:43 AM
To: Cappalli, Tim (Aruba)
Cc: EMU WG
Subject: Re: [Emu] Best practices for supplicants
On Nov 18, 2019, at 10:37 AM, Cappalli, Tim (Aruba) wrote:
>
> If the goal is not to improve identity assurance of an EAP server then what
> is this best practice change actually for?
I have been *explicit* in my statements that my goal *is* to improve
validation of the EAP server identity.
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
Date: Monday, November 18, 2019 at 10:34 AM
To: Cappalli, Tim (Aruba)
Cc: EMU WG
Subject: Re: [Emu] Best practices for supplicants and authenticators
> On Nov 18, 2019, at 10:22 AM, Cappalli, Tim (Aruba) 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
On 18.11.19 16:22, Cappalli, Tim (Aruba) wrote:
> So again, if NAIRealm is not bound to an organization’s public domain
> name, how does a public CA prove ownership of an NAIRealm? How is this
> different than ESSID?
It must not be a public domain name, but it can be.
Speaking of eduroam this is
Subject: [Emu] Best practices for supplicants and authenticators
After the meeting earlier today, I made some notes on best practices for
supplicants and authenticators. I think it would be useful to have an official
WG document which gives guidance.
Background:
a) the current practice
After the meeting earlier today, I made some notes on best practices for
supplicants and authenticators. I think it would be useful to have an official
WG document which gives guidance.
Background:
a) the current practice in TLS-based EAP methods is to use certificates with
11 matches
Mail list logo
