Subject: [Emu] TLS-pok for EAP

From: Dan Harkins <[email-masked]>
Date: Wed, 22 Jul 2020 13:59:49 -0700

Hello,

   Owen and I have a new draft out to introduce a new authentication
mechanism using out-of-band trust establishment (ala the DPP protocol)
into TLS for use with a TLS-based EAP method like TEAP or EAP-TLS.
This would enable zero touch provisioning for wired devices using the
same boostrapping methods that DPP uses for wireless.

   I'm on the agenda for Friday to do a brief presentation. Here's a
link to the draft if you're interested:

https://datatracker.ietf.org/doc/draft-friel-tls-eap-dpp/

   regards,

   Dan.

---

From: Josh Howlett <[email-masked]>
Date: Sat, 25 Jul 2020 16:50:53 +0100

This may be a stupid question, but I can’t find an explanation in the draft or figure it out myself... If the intended application for this TLS extension is network access, might it be simpler to define a new EAP method that used a similar key exchange? That would avoid touching implementations of TLS and those EAP methods using the extension.

Josh

From: Dan Harkins
Sent: 22 July 2020 21:59
To: emu
Subject: [Emu] TLS-pok for EAP

   Hello,

   regards,

   Dan.

_______________________________________________
Emu mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/emu

---

From: Dan Harkins <[email-masked]>
Date: Sat, 25 Jul 2020 10:49:33 -0700

Hi Josh,

   TLS-pok is a one-off. It's not for network access, it's to use a
trusted public key bootstrapped in any of the ways DPP has defined
to authenticate something like TEAP. TLS-pok authenticates the "outer"
TEAP tunnel and inside that tunnel a PKCS#10/PKCS#7 exchange happens
and the device gets provisioned for network access. The bootstrapped
key is never used again. Network access is accomplished using the
credentials provisioned by TEAP.

   regards,

   Dan.

On 7/25/20 8:50 AM, Josh Howlett wrote:
>
> This may be a stupid question, but I can’t find an explanation in the 
> draft or figure it out myself... If the intended application for this 
> TLS extension is network access, might it be simpler to define a new 
> EAP method that used a similar key exchange? That would avoid touching 
> implementations of TLS and those EAP methods using the extension.
>
> Josh
>
> *From: *Dan Harkins <mailto:[email-masked]>
> *Sent: *22 July 2020 21:59
> *To: *emu <mailto:[email-masked]>
> *Subject: *[Emu] TLS-pok for EAP
>
>   Hello,
>

---

From: Josh Howlett <[email-masked]>
Date: Sun, 26 Jul 2020 13:10:11 +0100

Thanks Dan, the penny has dropped.

It might be helpful to expand the discussion in paragraph 2 of section 3 to make this clearer. The use of language around device enrolment (“for instance [...] can [...] such as [...] RFC7170”) is a bit unspecific, whereas I believe its a key part of the overall design.

I have a further question about the operational model. I believe the absence of an NAI realm implies that the Authenticator (or its AAA server) will be unable to disambiguate between different EAP authentication servers. Therefore, there can only be single EAP server per network that is able to authenticate and enrol devices. Is this your understanding?

Josh

From: Dan Harkins
Sent: 25 July 2020 18:49
To: Josh Howlett; emu
Subject: Re: [Emu] TLS-pok for EAP

  Hi Josh,

  regards,

  Dan.
 
Josh
 
From: Dan Harkins
Sent: 22 July 2020 21:59
To: emu

  Hello,

 
 
  regards,
 
  Dan.