attachment
<div dir="ltr"><div>FYI - Interesting cross-fertilization in TLS for wired networks from</div><div>the Wi-Fi Alliance
Device Provisioning Profile</div><div><br>
</div><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">---------- Forwarded message ---------<br>From: <b class="gmail_sendername" dir="auto">Owen Friel (ofriel)</b> <span dir="auto"><ofriel=<a href="mailto:40cisco.com@dmarc.ietf.org">40cisco.com@dmarc.ietf.org</a>></span><br>Date: Fri, Mar 6, 2020 at 7:23 PM<br>Subject: [TLS] FW: New Version Notification for draft-friel-tls-eap-dpp-00.txt<br>To: TLS List <<a href="mailto:tls@ietf.org">tls@ietf.org</a>>, EMU WG <<a href="mailto:emu@ietf.org">emu@ietf.org</a>><br></div><br>All,<br>
<br>
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.<br>
<br>
There are changes required to the TLS key schedule, so part of this work overlaps with draft-jhoyla-tls-extended-key-schedule.<br>
<br>
We hope to remote present at both EMU and TLS.<br>
<br>
Owen<br>
<br>
-----Original Message-----<br>
From: <a href="mailto:internet-drafts@ietf.org" target="_blank">internet-drafts@ietf.org</a> <<a href="mailto:internet-drafts@ietf.org" target="_blank">internet-drafts@ietf.org</a>> <br>
Sent: 07 March 2020 07:56<br>
To: Dan Harkins <<a href="mailto:daniel.harkins@hpe.com" target="_blank">daniel.harkins@hpe.com</a>>; Owen Friel (ofriel) <<a href="mailto:ofriel@cisco.com" target="_blank">ofriel@cisco.com</a>><br>
Subject: New Version Notification for draft-friel-tls-eap-dpp-00.txt<br>
<br>
<br>
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.<br>
<br>
Name: draft-friel-tls-eap-dpp<br>
Revision: 00<br>
Title: Bootstrapped TLS Authentication<br>
Document date: 2020-03-06<br>
Group: Individual Submission<br>
Pages: 9<br>
URL: <a href="https://www.ietf.org/internet-drafts/draft-friel-tls-eap-dpp-00.txt" rel="noreferrer" target="_blank">https://www.ietf.org/internet-drafts/draft-friel-tls-eap-dpp-00.txt</a><br>
Status: <a href="https://datatracker.ietf.org/doc/draft-friel-tls-eap-dpp/" rel="noreferrer" target="_blank">https://datatracker.ietf.org/doc/draft-friel-tls-eap-dpp/</a><br>
Htmlized: <a href="https://tools.ietf.org/html/draft-friel-tls-eap-dpp-00" rel="noreferrer" target="_blank">https://tools.ietf.org/html/draft-friel-tls-eap-dpp-00</a><br>
Htmlized: <a href="https://datatracker.ietf.org/doc/html/draft-friel-tls-eap-dpp" rel="noreferrer" target="_blank">https://datatracker.ietf.org/doc/html/draft-friel-tls-eap-dpp</a><br>
<br>
<br>
Abstract:<br>
This document defines a TLS extension that enables a server to prove<br>
to a client that it has knowledge of the public key of a key pair<br>
where the client has knowledge of the private key of the key pair.<br>
Unlike standard TLS key exchanges, the public key is never exchanged<br>
in TLS protocol messages. Proof of knowledge of the public key is<br>
used by the client to bootstrap trust in the server. The use case<br>
outlined in this document is to establish trust in an EAP server.<br>
<br>
<br>
<br>
<br>
Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at <a href="http://tools.ietf.org" rel="noreferrer" target="_blank">tools.ietf.org</a>.<br>
<br>
The IETF Secretariat<br>
<br>
<br>
_______________________________________________<br>
TLS mailing list<br>
<a href="mailto:TLS@ietf.org" target="_blank">TLS@ietf.org</a><br>
<a href="https://www.ietf.org/mailman/listinfo/tls" rel="noreferrer" target="_blank">https://www.ietf.org/mailman/listinfo/tls</a><br>
</div></div></div>