Re: [Emu] Re-Charter Considerations

From: Emu On Behalf Of Dr. Pala Sent: Friday 20 July 2018 23:21 To: emu@ietf.org Subject: [Emu] Re-Charter Considerations Hi Emu-ers, I wanted to follow up the discussion from today's meeting. In particular, there is some work that has been proposed that might require re-chartering as indic

Re: [Emu] Comments on draft-lear-eap-teap-brski

Thanks Alan. These suggestions make sense and will help clear up the confusion. They can be incorporated in draft-01. -Original Message- From: Emu On Behalf Of Alan DeKok Sent: Saturday 21 July 2018 15:12 To: emu@ietf.org Subject: [Emu] Comments on draft-lear-eap-teap-brski One of the

Re: [Emu] teap-brski

-Original Message- From: Emu On Behalf Of Dan Harkins Sent: 06 June 2019 15:13 To: an...@ietf.org; emu@ietf.org Subject: [Emu] teap-brski Hello, In a private thread on teap-brski the topic of co-location of the TEAP server and the BRSKI registrar was brought up. It was sug

Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

> -Original Message- > From: Emu On Behalf Of Alan DeKok > Sent: 12 September 2019 16:28 > To: John Mattsson > Cc: draft-ietf-emu-eap-tl...@ietf.org; EMU WG > Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13 > > On Sep 12, 2019, at 10:55 AM, John Mattsson > wrote: > >

Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

> -Original Message- > From: Alan DeKok > Sent: 18 September 2019 14:40 > To: John Mattsson > Cc: Owen Friel (ofriel) ; draft-ietf-emu-eap- > tl...@ietf.org; EMU WG > Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13 > > > > &g

Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

And one other draft of interest: https://tools.ietf.org/html/draft-ietf-tls-external-psk-importer-00 > -Original Message- > From: Emu On Behalf Of Owen Friel (ofriel) > Sent: 18 September 2019 22:42 > To: Alan DeKok ; John Mattsson > > Cc: draft-ietf-emu-eap-tl..

Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

> -Original Message- > From: Jim Schaad > Sent: 19 September 2019 07:28 > To: 'Alan DeKok' ; Owen Friel (ofriel) > > Cc: draft-ietf-emu-eap-tl...@ietf.org; 'EMU WG' > Subject: RE: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13 > >

Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

> -Original Message- > From: John Mattsson > Sent: 19 September 2019 11:04 > To: Owen Friel (ofriel) ; Jim Schaad > ; 'Alan DeKok' > Cc: draft-ietf-emu-eap-tl...@ietf.org; 'EMU WG' > Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls

Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

From: Emu On Behalf Of John Mattsson Sent: 10 October 2019 09:30 To: Mohit Sethi M ; Eliot Lear Cc: draft-ietf-emu-eap-tl...@ietf.org; John Mattsson ; EMU WG Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13 Mohit Sethi M mohit.m.se...@ericsson.com

[Emu] EAP questions (RE: POST WGLC Comments draft-ietf-emu-eap-tls13)

> -Original Message- > From: Emu On Behalf Of Joseph Salowey > Sent: 03 November 2019 18:31 > To: Alan DeKok > Cc: draft-ietf-emu-eap-tl...@ietf.org; EMU WG ; John > Mattsson ; Michael > Richardson > Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13 > > > On Fri, Nov 1,

[Emu] TLS1.3 and TEAP (RE: POST WGLC Comments draft-ietf-emu-eap-tls13)

> -Original Message- > From: Emu On Behalf Of Alan DeKok > Sent: 01 November 2019 11:08 > To: John Mattsson > Cc: draft-ietf-emu-eap-tl...@ietf.org; Michael Richardson > ; John Mattsson > ; EMU WG > Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13 > > On Nov 1, 2019, at

Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

> -Original Message- > From: Emu On Behalf Of Joseph Salowey > Sent: 31 October 2019 04:45 > To: Alan DeKok > Cc: draft-ietf-emu-eap-tl...@ietf.org; John Mattsson > ; Michael Richardson > ; EMU WG > Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13 > > > > On Wed, Oct 3

Re: [Emu] EAP questions (RE: POST WGLC Comments draft-ietf-emu-eap-tls13)

> -Original Message- > From: Alan DeKok > Sent: 07 November 2019 17:43 > To: Owen Friel (ofriel) > Cc: Joseph Salowey ; draft-ietf-emu-eap-tl...@ietf.org; > EMU WG ; John Mattsson > ; Michael Richardson > > Subject: Re: EAP questions (RE: [Emu] POST W

Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

> -Original Message- > From: Alan DeKok > Sent: 07 November 2019 17:48 > To: Owen Friel (ofriel) > Cc: Joseph Salowey ; draft-ietf-emu-eap-tl...@ietf.org; > John Mattsson ; Michael > Richardson ; EMU WG > Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu

Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

> -Original Message- > From: Emu On Behalf Of Alan DeKok > Sent: 08 November 2019 12:43 > To: Joseph Salowey > Cc: EMU WG > Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13 > > On Nov 7, 2019, at 11:08 PM, Joseph Salowey wrote: > > [Joe] How about > > "If an implementa

Re: [Emu] Idea: New X509 Extension for securing EAP-TLS

This is also related to ongoing anima discussions about RFC 8366, and how it can bootstrap trust when the pinned domain cert is a public PKI CA, and not a private CA, and hence additional domain (or realm or FQDN) info is also needed in order for the peer to verify the identity of the server. I

Re: [Emu] Idea: New X509 Extension for securing EAP-TLS

-Original Message- From: Emu On Behalf Of Michael Richardson Sent: 12 November 2019 09:20 To: emu@ietf.org Subject: Re: [Emu] Idea: New X509 Extension for securing EAP-TLS On 2019-11-12 7:15 a.m., Owen Friel (ofriel) wrote: > This is also related to ongoing anima discussions ab

Re: [Emu] Idea: New X509 Extension for securing EAP-TLS

-Original Message- From: Emu On Behalf Of Alan DeKok Sent: 12 November 2019 16:32 To: Jan-Frederik Rieckers Cc: emu@ietf.org Subject: Re: [Emu] Idea: New X509 Extension for securing EAP-TLS > > The Problem with dNSNames is that they are also used in other contexts > (mainly HTTPS)

Re: [Emu] Idea: New X509 Extension for securing EAP-TLS

The CA/Browser forum has concrete guidelines on address, email, domain verification outlined here. https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.6.6.pdf All public CAs should follow these, or face blacklisting. CAs don’t want to risk being the next Symantec. " 3.2.2.1. Identity

Re: [Emu] Idea: New X509 Extension for securing EAP-TLS

-Original Message- From: Alan DeKok Sent: 16 November 2019 14:29 To: Owen Friel (ofriel) Cc: Jan-Frederik Rieckers ; emu@ietf.org Subject: Re: [Emu] Idea: New X509 Extension for securing EAP-TLS On Nov 16, 2019, at 7:59 AM, Owen Friel (ofriel) wrote: > [ofriel] this seems l

Re: [Emu] Presentations for IETF 106

Joe, Mohit, Somewhat disorganised and late request: there appears to be time in the agenda at the end for a 10 min update on: Title: ACME Integrations Drafts: draft-friel-acme-integrations, draft-friel-acme-subdomains Time: 10 minutes Currently doing slides on the plane.. -Original Message

Re: [Emu] Best practices for supplicants and authenticators

Assuming that NAIRealm is a registered domain as per RFC 7542, and thus public CAs can verify ownership, the goal / where we want to get to is: - CA may be a public CA and thus public CAs can be enabled by default in supplicant config - supplicant checks NAI Realm in the EAP identity cert matche

[Emu] EAP/EMU recommendations for client cert validation logic

Hi, At ACME meeting at IETF106, the last discussion of the week was around EMU looking for recommendations for EAP client/peer/supplicant cert verification logic when the client is verifying the cert that the EAP server presents. Minutes here: https://datatracker.ietf.org/doc/minutes-106-acme/

Re: [Emu] [lamps] EAP/EMU recommendations for client cert validation logic

Thanks for the detailed reply Ryan. See line. > -Original Message- > > If an EAP server operator wants to use a public CA identity cert on their EAP > server, what recommendations should we give to EAP clients so that the > supplicant code can handle public or private CA issued EAP serve

Re: [Emu] [lamps] EAP/EMU recommendations for client cert validation logic

If the PKI community as a whole (vendors, standards bodies, consortia, CAs) has managed to engineer a situation where, according to the strict letter of the law, CAs would have no choice but to revoke operators identity certificates for many of their services if Alan was actually mean and wrote

[Emu] FW: New Version Notification for draft-friel-tls-eap-dpp-00.txt

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

Re: [Emu] Late WGLC Comment on draft-ietf-emu-eap-tls13

Alan, How should we interpret this in RFC 5216 https://tools.ietf.org/html/rfc5216#section-2.1.1: If the EAP server is not resuming a previously established session, then it MUST include a TLS server_certificate handshake message, and a server_hello_done handshake message MUST be the las

Re: [Emu] Short review of draft-friel-tls-eap-dpp-01

-Original Message- From: Emu On Behalf Of Alan DeKok Sent: 19 July 2021 00:40 To: EMU WG Subject: [Emu] Short review of draft-friel-tls-eap-dpp-01 No major notes here. There's still a lot of TBD in the document. :) NITS: Section 3 says: ... For unprovisioned devices that

[Emu] FW: New Version Notification for draft-friel-tls-eap-dpp-05.txt

-00. -Original Message- From: internet-dra...@ietf.org Sent: Thursday 26 May 2022 21:02 To: Dan Harkins ; Owen Friel (ofriel) Subject: New Version Notification for draft-friel-tls-eap-dpp-05.txt A new version of I-D, draft-friel-tls-eap-dpp-05.txt has been successfully submitted by

Re: [Emu] Adoption call for EAP-DPP

If necessary we can add clarifying text to the next draft to explain why Wi-Fi Easy Connect 2.0 section 2.3.5 “Wired-Only DPP” does not solve this wired onboarding problem. Hopefully there is no longer any confusion on this point as Dan has clarified here, and previously: https://mailarchive.ie

Re: [Emu] Adoption call for EAP-DPP

Thanks Michael. Ok, we can look at a relay out and consider moving some of the EAP motivations in section 3 earlier in the document. And agree, I think we can do a better job of linking the use of draft-ietf-tls-external-psk-importer to identify BSKs with the EAP handshake! We can fix that up

Re: [Emu] draft-ietf-emu-bootstrapped-tls

Thanks Hannes. These all make sense and are now all addressed in github and I will include in draft-02 And yes, the intention is that DPP is recommended for Wi-Fi as it also addresses the Wi-Fi SSID discovery problem. TLK-POK is recommended for wired. I have clarified this in the introduction.

Re: [Emu] More TEAP issues

There are a few useful TLVs defined in https://datatracker.ietf.org/doc/html/draft-lear-eap-teap-brski-06 CSR Attributes as Eliot has mentioned, as well as e.g. Retry-After TLV which could be useful if the TEAP server has to communicate with a backend CA to get a PKCS#10 CSR signed. There is a

Re: [Emu] I-D Action: draft-ietf-emu-bootstrapped-tls-02.txt

This fixes a broken reference and cleans up some nits. It also tightens up the language about how the TLS handshake operates. It does not introduce any changes to the core algorithm at all. Regards, Owen -Original Message- From: Emu On Behalf Of internet-dra...@ietf.org Sent: Friday 10 Fe

Re: [Emu] draft-ietf-emu-bootstrapped-tls

Yep thanks Hannes for the review. That optimizes the solution and removes the unnecessary hashing of the BSK. Looking at the history, that BSK hashing was there since a very early version of the draft before we incorporated RFC 9258, and it never occurred to us to optimize that out once we start

Re: [Emu] draft-ietf-emu-bootstrapped-tls

rkins ; emu ; Owen Friel (ofriel) Subject: Re: [Emu] draft-ietf-emu-bootstrapped-tls Hi Owen, Hi Dan, thanks for the response and for the clarification. Here is my proposal for improving the wording of the document. First, there is a little bit of inconsistency in the terminology. The Bootstra

Re: [Emu] I-D Action: draft-ietf-emu-bootstrapped-tls-03.txt

This version removed the redundant HKDF as discussed here https://mailarchive.ietf.org/arch/msg/emu/AYPFwb_fkSIY5Y2IoNFAbvgHQ3s/ And also incorporates much of Hannes' feedback here: https://mailarchive.ietf.org/arch/msg/emu/CR_deZDEQ7wsV6Gx9uyW-rUVCi0/ Thanks, Owen -Original Message- F

[Emu] eap.arpa domain in draft-ietf-emu-bootstrapped-tls

Hi EMU Chairs, I was looking to see if any minor updates are needed to draft-ietf-emu-bootstrapped-tls-03 before IETF 118 and WGLC. There was one outstanding action from IETF 117: Do we want to say there is an eap.arpa domain? Yes, but not clear this draft is place to do that. Chairs to ask IAB

[Emu] Experimental RFC 8773 normative reference in draft-ietf-emu-bootstrapped-tls

Hi EMU Chairs, draft-ietf-emu-bootstrapped-tls is proposed Standards Track and depends on RFC 8773 which is Experimental. Do we need to talk to TLS WG about changing RFC 8773 from Experimental? How does this process work? Thanks, Owen+Dan ___ Emu mai

Re: [Emu] I-D Action: draft-ietf-emu-bootstrapped-tls-04.txt

This has two updates: 1. reference https://datatracker.ietf.org/doc/html/draft-dekok-emu-eap-arpa-00 and defines the username "tls-pok-dpp" 2. reference https://datatracker.ietf.org/doc/html/draft-ietf-tls-8773bis-01 instead of https://datatracker.ietf.org/doc/html/rfc8773 Thanks, Owen+Dan --

[Emu] ietf-emu-eap-arpa and ietf-emu-bootstrapped-tls

Hi Alan, all I'm updating https://datatracker.ietf.org/doc/html/draft-ietf-emu-bootstrapped-tls-05#section-4 to use the latest guidelines in https://datatracker.ietf.org/doc/html/draft-ietf-emu-eap-arpa-01 and am a bit confused about the username to use. https://datatracker.ietf.org/doc/html/d

[Emu] Re: I-D Action: draft-ietf-emu-bootstrapped-tls-06.txt

Minor updates to reference ietf-emu-eap-arpa and latest guidelines instead of dekok-emu-eap-arpa. Owen+Dan -Original Message- From: internet-dra...@ietf.org Sent: Monday, August 19, 2024 2:07 PM To: i-d-annou...@ietf.org Cc: emu@ietf.org Subject: [Emu] I-D Action: draft-ietf-emu-bootstr