Hi Behcet,
On 8/19/22 8:22 AM, Behcet Sarikaya wrote:
Hi Dan,
On Thu, Aug 18, 2022 at 9:54 AM Dan Harkins <dhark...@lounge.org> wrote:
Hi Behcet,
On 8/17/22 2:36 PM, Behcet Sarikaya wrote:
Hi Peter,
I quickly read this short document and have some comments.
In the informative references section, DPP is listed as Device
Provisioning Profile while it should be Device Provisioning Protocol.
Actually, in the acronyms section the name is correctly given.
However, the DPP acronym is not properly expanded in the first
use of the acronym which is in Section 1. Also the same could be
said of the other acronyms
Good catch. We'll fix that.
Also the date of DPP document seems to be wrong, I think the
version 1.1 was dated 2018.
I think the Wi-Fi Alliance has released v2. I'll check and we'll
fix this if needed.
I think there is no v2.
DPP is actually in v3 right now so there is definitely a v2. We just
need to get
the reference correct.
Probably more seriously though, the document says DPP does not
support wired network access in Section 1 but maybe the authors
are not aware that there is something called wired only DPP which
is defined in another WiFi Alliance document in Section 2.3.5 of
Wi-i Easy ConnectTM Specification v2.0
This document is dated 2020, maybe the authors should reference
this document then the date will be correct 👍🏻.
The DPP-over-TCP solution will not work. DPP-over-TCP was added
to enable centralization
of DPP services in devices which might not have an 802.11
interface. Think of a central network
server that implements a DPP Configurator that is connected to
multiple access points in an ESS.
The APs will just de-capsulate the 802.11 frames they receive,
re-encapsulate them in TCP/IP
headers and send them to the central network server who processes
them and responds with
TCP packets to which the inverse operation is performed by the AP.
That said, it is certainly
possible for two entities to speak a complete DPP conversation
over TCP without the use of
802.11. But as I said this won't work here.
The reason this won't work is the "Onboarding Catch-22" where
you need a credential to get
on the network but need to get on the network to get a credential.
DPP-over-TCP requires an
IP address. How do you get an IP address? Well, after "link up" on
your wired connection you do
EAP and authenticate, and then do DHCP. But how do you do EAP?
Yes it is a good question but it is answered in detail in Section
2.3.5 of WiFi Easy Connect Specification. Fig. 9 there on page 40
shows the message flow.
The client there already has an IP address. The issue there is how
will the client get IP address of DPP controller. They propose
several solutions including DNS.
Authentication is based on these three messages exchanged: DPP Auth
Req/DPP Aut Res/DPP Auth Conf
I am well aware of section 2.3.5 of the DPP specification. And I'm
well aware
of the DPP authentication exchange because I invented it. Thing is, you
still
need an IP address to do DPP-over-TCP. It's not just figuring out the IP
address
of the controller, it's your own IP address. How do you get an IP
address to
query the DNS if the network is secured and you don't have a credential
to get
on the network?
The question is not answered in 2.3.5 of the DPP specification. In
fact, it's
not answered in any part of the DPP specification.
There is no EAP. EAP in DPP is used in 802.11X with EAP-OL Key message.
Yes, there is no EAP in DPP. That's what this proposal is doing!
Actually,
not really EAP in DPP more like DPP in EAP.
The use case is a wired device with no, or a limited, user interface.
How do
you get it on a secure network? Wired security is 802.1X and as soon as you
plug anything into such a port EAPoL starts. What does the device do? It
can't get an IP address to do DPP-over-TCP because it has to finish EAP
in order to get an IP address. So it's stuck.
We are proposing to solve that issue by using DPP bootstrapping to
authenticate the TLS connection used in TEAP and then use TEAP's existing
enrollment capabilities to provision the device. Make sense?
Dan.
Behcet
regards,
Dan.
Behcet
On Tue, Aug 16, 2022 at 3:12 PM Peter Yee <pe...@akayla.com> wrote:
This is an adoption call for EAP-DPP
(draft-friel-tls-eap-dpp-05)[1]. This
document aligns with the charter item to "Define mechanisms
by which EAP
methods can support creation of long-term credentials for the
peer based on
initial limited-use credentials." The latest revision
incorporates feedback
from both the TLS and EMU working groups. Please review and
respond to the
list if you think this document is or is not an appropriate
working group
item for EMU by September 1, 2022.
Thanks,
Peter and Joe
[1] https://datatracker.ietf.org/doc/draft-friel-tls-eap-dpp/
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
--
"The object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." -- Marcus Aurelius
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
--
"The object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." -- Marcus Aurelius
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
