Subject: [IPP] Fwd: [TLS] FW: New Version Notification for draft-friel-tls-eap-dpp-00.txt

From: Ira McDonald via ipp <[email-masked]>
Date: Sat, 7 Mar 2020 10:09:35 -0500

FYI - Interesting cross-fertilization in TLS for wired networks from
the Wi-Fi Alliance Device Provisioning Profile

---------- Forwarded message ---------
From: Owen Friel (ofriel) <ofriel=[email-masked]>
Date: Fri, Mar 6, 2020 at 7:23 PM
Subject: [TLS] FW: New Version Notification for
draft-friel-tls-eap-dpp-00.txt
To: TLS List <[email-masked]>, EMU WG <[email-masked]>

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: [email-masked] <[email-masked]>
Sent: 07 March 2020 07:56
To: Dan Harkins <[email-masked]>; Owen Friel (ofriel) <
[email-masked]>
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

_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
ipp mailing list
[email-masked]
https://www.pwg.org/mailman/listinfo/ipp