On Jul 28, 2021, at 12:26 PM, Dan Harkins wrote:
> Assuming everything can be assigned a username and a password is what is
> wrong.
Yes. That was intended to be just an example, though.
> If you're concerned about *standard* EAP methods being used in *standard* ways
> then think about wha
On Jul 28, 2021, at 12:16 PM, Dan Harkins wrote:
> I think you're reading a bit too much into "provisioning mode" here. There
> was never an intention in TEAP to allow for the PKCS10/PKCS7 exchange to be
> done after an anonymous Phase 1. The anonymous Phase 1 was used to get a
> tunnel up in or
On 7/28/21 5:06 AM, Alan DeKok wrote:
On Jul 27, 2021, at 1:50 PM, Alan DeKok wrote:
We are trying to avoid wheel reinvention. The novel bit here is the mutual
authentication in the TLS stack based on the already defined Wi-Fi Alliance DPP
bootstrap key.
The novel bit in the EAP-DPP dra
Hi Alan,
On 7/27/21 10:50 AM, Alan DeKok wrote:
On Jul 27, 2021, at 1:23 PM, Owen Friel (ofriel) wrote:
[ofriel] the goal here is to push the provisioning info (e.g. CA roots, peer
identity certs) inside TEAP using existing TEAP mechanisms e.g. Trusted Server
Root, PKCS#7 TLVs.
That p
On Jul 27, 2021, at 1:50 PM, Alan DeKok wrote:
>> We are trying to avoid wheel reinvention. The novel bit here is the mutual
>> authentication in the TLS stack based on the already defined Wi-Fi Alliance
>> DPP bootstrap key.
The novel bit in the EAP-DPP draft, yes.
My leaning is more and
