Re: [Emu] Adoption call for EAP-DPP

[Owen Friel (ofriel)]

Thanks Michael.

Ok, we can look at a relay out and consider moving some of the EAP motivations 
in section 3 earlier in the document.

And agree, I think we can do a better job of linking the use of 
draft-ietf-tls-external-psk-importer to identify BSKs with the EAP handshake! 
We can fix that up in the next draft too.

Inline for more.

-Original Message-
From: Emu  On Behalf Of Michael Richardson
Sent: Tuesday 13 September 2022 12:13
To: Peter Yee ; emu@ietf.org
Subject: Re: [Emu] Adoption call for EAP-DPP


I have read draft-friel-tls-eap-dpp-05.
I have no objection to the WG working on such a thing, but I think that there 
is actually quite a lot of work left to do.

I think that the section 3, which explains the EAP connection (and the 
motivation for the work) should probably come before the extension and the 
cryptographic explanation!

I find the document quite weak even in section 3.
I think that the EAP server (Authentication Server) is meant to use the OOB 
public key to authenticate the new device.

I'm rather vague as to how the Authentication Server knows what identity to use 
to look the public key up, and how the privacy of this identity is preserved.

[ofriel] the draft-ietf-tls-external-psk-importer external_identity is HKDF 
derived from the BSK public key as outlined in 
https://datatracker.ietf.org/doc/html/draft-friel-tls-eap-dpp-05#section-2.1. 
This is included in the ImportedIdentity struct which is serialized into 
PskIdentity.identity in the PSK extension, all as per 
draft-ietf-tls-external-psk-importer. Only a server that knows the 
raw/cleartext BSK public key can complete the TLS PSK handshake. 


Does the device get any indication that it has been plugged into the correct 
network?  Is there any authenticatin of the Authentication Server?

[ofriel] The device and server are afforded the same levels of identity 
guarantees and authentication as Wi-Fi DPP. The network gets a guarantee that 
the device connecting knows the BKS private key. The device gets a guarantee 
that the network knows its BSK public key. Similar to Wi-Fi Easy Connect / DPP, 
proof of knowledge of the BSK public key is proof of ownership of the device.



While I acknowledge you are not trying to implement BRSKI (RFC8995) or SZTP 
(RFC8572), it would be good if your Security Considerations addressed some of 
the same issues that those documents deal with.



--
Michael Richardson , Sandelman Software Works  -= IPv6 
IoT consulting =-



___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Adoption call for EAP-DPP

[Owen Friel (ofriel)]

If necessary we can add clarifying text to the next draft to explain why Wi-Fi 
Easy Connect 2.0 section 2.3.5 “Wired-Only DPP” does not solve this wired 
onboarding problem. Hopefully there is no longer any confusion on this point as 
Dan has clarified here, and previously: 
https://mailarchive.ietf.org/arch/msg/emu/lboE_o4OfJJtUL_LA6psIpSuHZs/

Regards,
Owen

From: Emu  On Behalf Of Dan Harkins
Sent: Friday 9 September 2022 07:29
To: sarik...@ieee.org
Cc: emu@ietf.org
Subject: Re: [Emu] Adoption call for EAP-DPP


  Hi Behcet,
On 9/8/22 8:43 AM, Behcet Sarikaya wrote:
Hi Peter, Joe,

We made it clear that DPP R2 has already been published  with a name change:






 Wi-Fi Easy Connect™

Specification

Version 2.0


Wi-Fi Easy Connect is the new DPP, which the authors seemingly did not know 
about.

  Wi-Fi Easy Connect is the name of a certification program at the Wi-Fi 
Alliance
for devices that implement the DPP protocol.

  I am well aware of Wi-Fi Easy Connect (having invented the protocols that are 
used
in it and have contributed to development of the test plan). It seems that you 
aren't.


Also the problem that this draft deals with and also Elliott mentioned in his 
mail, Wi-Fi Easy Connect already solves it.

  That is not correct, this draft deals with on-boarding of wired devices on 
networks
that enforce security. Such networks enforce 802.1x and as soon as a device is 
plugged
into such a switch an EAP Identity-Request will be sent. No packets other than 
EAPoL are
allowed. Certainly no TCP frames encapsulating DPP messages! So it is not 
possible to
do any DPP-over-TCP (or if you will "Wi-Fi Easy Connect over TCP") in such a 
situation.

  Wi-Fi Easy Connect, which is a certification program, does not solve this 
problem. Neither
does the DPP protocol which Wi-Fi Easy Connect certifies compliance to.

  The issue that IP connectivity cannot be established until authentication and 
DPP-over-TCP
requires IP connectivity to perform authentication. It's a classic catch-22. 
Why don't you
see this obvious problem?

  regards,

  Dan.


Regards,
Behcet



On Wed, Sep 7, 2022 at 11:57 PM Peter Yee 
mailto:pe...@akayla.com>> wrote:
In retrospect, sending the call for adoption at the height of August
vacation season may not have guaranteed the most responses. To be honest,
the level of responses to this call has been a little light, so Joe and I
have decided to extend the call for adoption for one week from today.

We would really like to hear from anyone else who is interested in reviewing
and/or contributing to this specification or anyone who feels that it should
not be adopted. Please speak up by the 14th either way. This specification
would seemingly fit within the WG's existing charter, so let your voice be
heard!

Thanks,

Peter and Joe

-Original Message-
From: Peter Yee mailto:pe...@akayla.com>>
Sent: Tuesday, August 16, 2022 1:12 PM
To: 'emu@ietf.org' mailto:emu@ietf.org>>
Subject: Adoption call for EAP-DPP

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