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
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 presumes everyone uses TEAP, all of the time. This
-Original Message-
From: Emu On Behalf Of Alan DeKok
Sent: 19 July 2021 00:40
To: EMU WG
Subject: [Emu] Short review of draft-friel-tls-eap-dpp-01
No major notes here. There's still a lot of TBD in the document. :)
NITS:
Section 3 says:
... For
unprovisioned de
No major notes here. There's still a lot of TBD in the document. :)
NITS:
Section 3 says:
... For
unprovisioned devices that desire to take advantage of TLS-POK, there
is no initial realm in which to construct an NAI (see [RFC4282]) so
the initial EAP Identity response SHOULD co
