[Emu] FW: New Version Notification for draft-friel-tls-eap-dpp-00.txt
All, Dan and I have a new draft that describes how a mechanism similar to the Wi-Fi Alliance Device Provisioning Profile can be used on wired networks via proposed new TLS extensions, with those extensions being leveraged in an EAP transaction. Importantly, the DPP bootstrap key format, and thus the DPP QR label, can be reused for bootstrapping a thing on both wired and Wi-Fi networks. There are changes required to the TLS key schedule, so part of this work overlaps with draft-jhoyla-tls-extended-key-schedule. We hope to remote present at both EMU and TLS. Owen -Original Message- From: internet-dra...@ietf.org Sent: 07 March 2020 07:56 To: Dan Harkins ; Owen Friel (ofriel) Subject: New Version Notification for draft-friel-tls-eap-dpp-00.txt A new version of I-D, draft-friel-tls-eap-dpp-00.txt has been successfully submitted by Owen Friel and posted to the IETF repository. Name: draft-friel-tls-eap-dpp Revision: 00 Title: Bootstrapped TLS Authentication Document date: 2020-03-06 Group: Individual Submission Pages: 9 URL: https://www.ietf.org/internet-drafts/draft-friel-tls-eap-dpp-00.txt Status: https://datatracker.ietf.org/doc/draft-friel-tls-eap-dpp/ Htmlized: https://tools.ietf.org/html/draft-friel-tls-eap-dpp-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-friel-tls-eap-dpp Abstract: This document defines a TLS extension that enables a server to prove to a client that it has knowledge of the public key of a key pair where the client has knowledge of the private key of the key pair. Unlike standard TLS key exchanges, the public key is never exchanged in TLS protocol messages. Proof of knowledge of the public key is used by the client to bootstrap trust in the server. The use case outlined in this document is to establish trust in an EAP server. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] EMU@IETF017: Agenda Topics
Please send any agenda requests to the chairs at emu-cha...@ietf.org. Thanks Joe ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] EAP-NOOB: request for optional message pair to configure EAP Peer
Hi, I am Philip Ginzboorg from Huawei Finland. Together with my colleague Sandeep Tamrakar we are working on IoT security-related project and had a look at EAP-NOOB. Here is our comment on the EAP-NOOB draft version 7: - In addition to the functionality that EAP-NOOB already provides, we would like to have the possibility for the EAP server to configure the EAP Peer. For instance, the EAP Server could provision long-term credentials to the EAP Peer. - For that purpose, we would like to have one optional message pair in the EAP-NOOB protocol exchanged, just before the Completion Exchange (Section 3..2.4) ends. - The first additional message, from EAP Server to EAP Peer, could be of a separate Command message type (e.g., type=10). It should be send only during the Completion exchange, after the server verifies the correctness of the received MAC (i.e. MACp) from the EAP Peer, and before EAP-Success message. - Upon receiving this message, the EAP Peer will configure itself as instructed by the EAP Server, if MACs is correct. Then, the EAP Peer will respond with configuration success message. - For example, in Fig 6 (https://tools.ietf.org/html/draft-aura-eap-noob-07) after 4th message (Type=4,PeerId,MACp) and before EAP-Success message, there would be a possibility of sending additional message (e.g., Type=10, say, a configuration Command message) to the EAP Peer, and expect back a response. Philip ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
