-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[PW_SID:790210] RFC: PKEX support for DPP #240
base: workflow
Are you sure you want to change the base?
Conversation
This is taken care of by the individual cache items and if none exist, tar fails.
PKEX is part of the WFA EasyConnect specification and is an additional boostrapping method (like QR codes) for exchanging public keys between a configurator and enrollee. PKEX operates over wifi and requires a key/code be exchanged prior to the protocol. The key is used to encrypt the exchange of the boostrapping information, then DPP authentication is started immediately aftewards. This can be useful for devices which don't have the ability to scan a QR code, or even as a more convenient way to share wireless credentials if the PSK is very secure (i.e. not a human readable string). This only documents the DBus API for now to get an idea of how and where this module would live. The current plan is to keep it in dpp.c. This module is getting rather large but all the infrastructure exists for offchannel/frame callbacks and state so it makes sense to keep it there. The plan is to add some additional states to dpp for PKEX which would happen prior to AUTHENTICATION and allow the PRESENCE state to be skipped. PKEX would be used via the two DBus APIs. PkexConfigure would start listening and wait for an Enrollee to send a PKEX exchange request. The enrollee would be started with PkexEnroll and initiate the exchange. PKEX would proceed and once done DPP Authentication would start using the boostrapping keys exchanged. For convenience/security the PKEX key could be specified in the IWD provisioning file (part of the Security group). This would allow IWD to encrypt it and avoid the need for some other entity to store the key in order to call PkexConfigure (e.g. if not initiated by a human entering the key).
Fetch PR Make Distcheck Output:
Build - Configure Make Check Output:
Make Check w/Valgrind Output:
Incremental Build with patches |
Fetch PR GitLint Make Distcheck Output:
Build - Configure Make Check Output:
Make Check w/Valgrind Output:
Incremental Build with patches Autotest Runner Output:
Clang Build Output:
|
c94e205
to
0505d54
Compare
a9a4ef7
to
eac1598
Compare
bcfe88e
to
d7f439f
Compare
d7f439f
to
92a4b1e
Compare
68c71d2
to
43f4327
Compare
4170bb4
to
c067bc7
Compare
f10f2fc
to
c2be9ec
Compare
ebbbc93
to
089fa9a
Compare
2192e98
to
43a07cc
Compare
2c7b52e
to
58d64d4
Compare
68d5156
to
953fb5e
Compare
a123040
to
568d50f
Compare
PKEX is part of the WFA EasyConnect specification and is
an additional boostrapping method (like QR codes) for
exchanging public keys between a configurator and enrollee.
PKEX operates over wifi and requires a key/code be exchanged
prior to the protocol. The key is used to encrypt the exchange
of the boostrapping information, then DPP authentication is
started immediately aftewards.
This can be useful for devices which don't have the ability to
scan a QR code, or even as a more convenient way to share
wireless credentials if the PSK is very secure (i.e. not a
human readable string).
This only documents the DBus API for now to get an idea of how
and where this module would live. The current plan is to keep
it in dpp.c. This module is getting rather large but all the
infrastructure exists for offchannel/frame callbacks and
state so it makes sense to keep it there. The plan is to add
some additional states to dpp for PKEX which would happen
prior to AUTHENTICATION and allow the PRESENCE state to be
skipped.
PKEX would be used via the two DBus APIs. PkexConfigure would
start listening and wait for an Enrollee to send a PKEX
exchange request. The enrollee would be started with PkexEnroll
and initiate the exchange. PKEX would proceed and once done
DPP Authentication would start using the boostrapping keys
exchanged.
For convenience/security the PKEX key could be specified in the
IWD provisioning file (part of the Security group). This would
allow IWD to encrypt it and avoid the need for some other entity
to store the key in order to call PkexConfigure (e.g. if not
initiated by a human entering the key).
doc/device-provisioning-api.txt | 44 +++++++++++++++++++++++++++++++++
1 file changed, 44 insertions(+)