Re: [Emu] EAP TLS 1.3 backward compatibility with RFC 5216

Your suggestion looks good to me. I added a commit to RR #83 https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pull/83 From: Bernard Aboba Date: Saturday, 19 June 2021 at 16:47 To: John Mattsson Cc: Joseph Salowey , EMU WG Subject: Re: [Emu] EAP TLS 1.3 backward compatibility with RFC 5216 I

Re: [Emu] EAP TLS 1.3 backward compatibility with RFC 5216

es. The EAP-TLS implementation needs > to know which version of TLS that was negotiated. > > > > Cheers, > > John > > > > > > *From: *Emu on behalf of Joseph Salowey < > j...@salowey.net> > *Date: *Monday, 14 June 2021 at 01:54 > *To: *B

Re: [Emu] EAP TLS 1.3 backward compatibility with RFC 5216

, John From: Emu on behalf of Joseph Salowey Date: Monday, 14 June 2021 at 01:54 To: Bernard Aboba Cc: EMU WG Subject: Re: [Emu] EAP TLS 1.3 backward compatibility with RFC 5216 On Sun, Jun 13, 2021 at 2:44 PM Bernard Aboba mailto:bernard.ab...@gmail.com>> wrote: draft-ietf-emu-eap-tl

Re: [Emu] EAP TLS 1.3 backward compatibility with RFC 5216

On Sun, Jun 13, 2021 at 2:44 PM Bernard Aboba wrote: > draft-ietf-emu-eap-tls13-16 Section 2.1 contains the following text: > >EAP-TLS 1.3 remains backwards compatible with EAP-TLS 1.2 [RFC5216] . TLS > version >negotiation is handled by the TLS layer, and thus outside of the >scope

[Emu] EAP TLS 1.3 backward compatibility with RFC 5216

draft-ietf-emu-eap-tls13-16 Section 2.1 contains the following text: EAP-TLS 1.3 remains backwards compatible with EAP-TLS 1.2 [RFC5216] . TLS version negotiation is handled by the TLS layer, and thus outside of the scope of EAP-TLS. Therefore so long as the underlying TLS implementat

Re: [Emu] EAP-TLS 1.3 - few more comments

, 17 May 2021 at 16:25 To: Joseph Salowey Cc: EMU WG Subject: Re: [Emu] EAP-TLS 1.3 - few more comments Thanks Joe, one comment regarding item #16 is inline below. On Sun, May 16, 2021 at 9:52 PM Joseph Salowey mailto:j...@salowey.net>> wrote: Hi Oleg, thanks for the review, comments belo

Re: [Emu] EAP-TLS 1.3 Section 2.2 text

y Verification" needs to match current deployments and uses of EAP-TLS. But if EAP-TLS does not even mandate server authentication, does it really make sense to mandate revocation? Cheers, John From: Emu on behalf of Oleg Pekar Date: Monday, 31 May 2021 at 17:46 To: Joseph Salowey Cc: s

Re: [Emu] EAP-TLS 1.3 Section 2.2 text

This version is fine. Just the term "EAP servers for the network" still looks confusing to me. Maybe we can use instead the more detailed explanation that you provided above. On Tue, May 25, 2021 at 7:45 AM Joseph Salowey wrote: > I made some changes to the pull request to address some of the co

Re: [Emu] EAP-TLS 1.3 Section 2.2 text

On Tue, 25 May 2021 at 07:45, Joseph Salowey wrote: > I made some changes to the pull request to address some of the comments > and make the text clearer: > One note about the TOFU mechanism: What we've seen is that certificate renewal also triggers server certificate re-trust query/prompt/other

Re: [Emu] EAP-TLS 1.3 Section 2.2 text

I think that's good. > On May 25, 2021, at 12:45 AM, Joseph Salowey wrote: > > I made some changes to the pull request to address some of the comments and > make the text clearer: > > The EAP peer identity provided in the EAP-Response/Identity is not >authenticated by EAP-TLS. Unauthent

Re: [Emu] EAP-TLS 1.3 Section 2.2 text

I made some changes to the pull request to address some of the comments and make the text clearer: The EAP peer identity provided in the EAP-Response/Identity is not authenticated by EAP-TLS. Unauthenticated information MUST NOT be used for accounting purposes or to give authorization. The

Re: [Emu] EAP-TLS 1.3 Section 2.2 text

On Wed, May 19, 2021 at 5:58 AM Alan DeKok wrote: > On May 19, 2021, at 8:37 AM, Oleg Pekar wrote: > > After thinking a bit more about it - for the sake of the client > implementation clarity, would it be better if we provide the strict > algorithm for server identity check or maybe reference RF

Re: [Emu] EAP-TLS 1.3 Section 2.2 text

On May 19, 2021, at 8:37 AM, Oleg Pekar wrote: > After thinking a bit more about it - for the sake of the client > implementation clarity, would it be better if we provide the strict algorithm > for server identity check or maybe reference RFC 6125. Given the time frame and what we know, I th

Re: [Emu] EAP-TLS 1.3 Section 2.2 text

+Peter After thinking a bit more about it - for the sake of the client implementation clarity, would it be better if we provide the strict algorithm for server identity check or maybe reference RFC 6125. On Mon, May 17, 2021 at 11:58 PM Oleg Pekar wrote: > To section: 2.2. Identity Verificatio

Re: [Emu] EAP-TLS 1.3 Section 2.2 text

To section: 2.2. Identity Verification 1) If server name matching is not used, then peers may end up trusting servers for EAP authentication that are not intended to be EAP servers for the network. -- comment: What is meant by "EAP server for the network"? 2) EAP peer implementations SHOU

Re: [Emu] EAP-TLS 1.3 Section 2.2 text

Nit: RFC 5280 (see Section 4.2.1.6) talks about the subject alternative name extension, which as an ASN.1 definition for SubjectAltName. So, please do not refer to subjectAlternativeName. Russ > On May 15, 2021, at 8:21 PM, Joseph Salowey wrote: > > I proposed a PR#72 >

Re: [Emu] EAP-TLS 1.3 - few more comments

Thanks Joe, one comment regarding item #16 is inline below. On Sun, May 16, 2021 at 9:52 PM Joseph Salowey wrote: > Hi Oleg, > > thanks for the review, comments below: > > On Sun, May 16, 2021 at 1:55 AM Oleg Pekar > wrote: > >> Hi, few more comments on the draft #15 >> https://datatracker.ietf

Re: [Emu] EAP-TLS 1.3 Section 2.2 text

Let this be the biggest argument on this list ;-) > On 17 May 2021, at 14:44, Alan DeKok wrote: > > > This is just a personal preference, but "MUST NOT" is clearer to me than > SHALL NOT. It's also more used, IIRC. signature.asc Description: Message signed with OpenPGP ___

Re: [Emu] EAP-TLS 1.3 Section 2.2 text

On May 15, 2021, at 8:21 PM, Joseph Salowey wrote: > I proposed a PR#72 based on this suggestion. The resulting text for the > section is below. Please review to see if it is OK. It looks good, subject to minor comments. >The EAP peer identity provided in the EAP-Response/Identity is n

Re: [Emu] EAP-TLS 1.3 - few more comments

Hi Oleg, thanks for the review, comments below: On Sun, May 16, 2021 at 1:55 AM Oleg Pekar wrote: > Hi, few more comments on the draft #15 > https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tls13/15/: > > 1) > > 2.1.1. Authentication > > The full handshake in EAP-TLS with TLS 1.3 always >

[Emu] EAP-TLS 1.3 - few more comments

Hi, few more comments on the draft #15 https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tls13/15/: 1) 2.1.1. Authentication The full handshake in EAP-TLS with TLS 1.3 always provide forward secrecy by exchange of ephemeral "key_share" extensions in the ClientHello and ServerHello (e.g.

Re: [Emu] EAP-TLS 1.3 Section 2.2 text

I proposed a PR#72 based on this suggestion. The resulting text for the section is below. Please review to see if it is OK. Thanks, Joe 2.2. Identity Verification This section updates Section 2.2 of [RFC5216]. The EAP peer id

Re: [Emu] EAP-TLS 1.3 Section 2.2 text

On May 9, 2021, at 9:16 PM, Joseph Salowey wrote: > [Joe] This is a good question. There are multiple ways this could be > addressed. All servers should have one of their list of SANs that matches > the name used for EAP servers. Another option is for supplicants to allow > for the configur

[Emu] EAP-TLS 1.3 Section 2.2 text

Alan's review made the following comments: > Section 2.2 has substantial new text which was not previously discussed on the WG mailing list. > The EAP server identity in the TLS server certificate is typically a > fully qualified domain name (FQDN). EAP peer implementations SHOULD > allow u

[Emu] EAP-TLS 1.3 Success result indications resolution

We have two options for protected Success 1) a single byte of application data set to 0 or 2) use close notify. We have two implementation reports to indicate that both of these options should be implementable in most cases. However, it seems that we have more implementation experience with the a

[Emu] EAP-TLS 1.3 Hackathon at IETF 110

In order to better validate existing implementations of EAP-TLS 1.3, we will be organizing an EAP-TLS 1.3 Hackathon at IETF 110. The goal of the hackathon is to test operating system client implementations (Android, iOS, Mac OS X, Windows) with server implementations over the Internet. If you are

[Emu] EAP-TLS 1.3 and KeyUpdate

Hi, TLS 1.3 (RFC 8446) Section 4.6.3 allows both client and server to send a KeyUpdate Post-Handshake message. Doing so directly after the handshake and without any application data being sent does not make that much sense, but is allowed. Should the draft say something about the KeyUpdate mes

Re: [Emu] EAP-TLS 1.3 - Session-Id and extended EAP types

On Mar 25, 2019, at 12:59 AM, John Mattsson wrote: > > Noticed the following: > > draft-ietf-emu-eap-tls13-04 defines the key hierarchy as > > Type-Code= 0x0D > Key_Material = TLS-Exporter("EXPORTER_EAP_TLS_Key_Material", > Type-Code, 128) > IV

[Emu] EAP-TLS 1.3 - Session-Id and extended EAP types

Noticed the following: draft-ietf-emu-eap-tls13-04 defines the key hierarchy as Type-Code= 0x0D Key_Material = TLS-Exporter("EXPORTER_EAP_TLS_Key_Material", Type-Code, 128) IV = TLS-Exporter("EXPORTER_EAP_TLS_IV",

Re: [Emu] EAP-TLS 1.3 TLS-Exporter context_value

On Jan 11, 2019, at 8:13 AM, John Mattsson wrote: > > The working group did never really discuss the context_value parameter. So > just to bring up the question: Is there any information from the EAP-Requests > and EAP-Responses that should (and could) be included in the context_value to > ens

[Emu] EAP-TLS 1.3 TLS-Exporter context_value

Hi, RFC 8446 defines the TLS-Exporter interface as: TLS-Exporter(label, context_value, key_length) draft-ietf-emu-eap-tls13 is using the exporter interface without context: Key_Material = TLS-Exporter("EXPORTER_EAP_TLS_Key_Material", "", 128) IV = TLS-Exporter("EXPORTER_EAP_T

Re: [Emu] EAP-TLS 1.3 - TLS extensions and mechanisms - Review

On Nov 14, 2018, at 9:04 AM, John Mattsson wrote: > > Hi all, > > I think the draft is now in quite good shape. It would be good to get some > reviews. A quick review, mostly NITs: Weaknesses found in previous versions of TLS, as well as new requirements for security, privacy, and re

Re: [Emu] EAP-TLS 1.3 - TLS extensions and mechanisms

I would be very hesitant to mandate RFC 7924. Most EAP-TLS implementations use existing TLS libraries rather than implementing their own TLS stack. And many popular TLS libraries don't provide support for RFC 7924. Please look at : https://github.com/openssl/openssl/issues/5040 for example. Us

Re: [Emu] EAP-TLS 1.3 - TLS extensions and mechanisms

On Nov 14, 2018, at 9:04 AM, John Mattsson wrote: > draft-ietf-emu-eap-tls13-03 adds: > > "The use of Certificate Status Requests to determine the current status of > the EAP server's certificate is RECOMMENDED." I think that's good. > For EAP-TLS where the peer often does not have internet

Re: [Emu] EAP-TLS 1.3 - TLS extensions and mechanisms

I think mandatory support and use of stapling is a great idea. There have been so many changes across platforms the past few years w.r.t. status checks during an EAP exchange which has caused significant admin and end user headache. This solves that by making it consistent while adding the secur

[Emu] EAP-TLS 1.3 - TLS extensions and mechanisms

Hi all, I think the draft is now in quite good shape. It would be good to get some reviews. One thing that I would like to discuss is what the draft should say about various extensions and mechanisms. In particular: - Revocation -- RFC 5216

Re: [Emu] EAP - TLS 1.3

The big question is "Why not create a new EAP method"? The overall intent seems to be to create an pre-shared key EAP method optimized for 5G, based on EAP-TLS v1.3. Since the protocol described will not interoperate with any of the existing 2+ billion EAP-TLS devices, why reuse the EAP-TLS code

Re: [Emu] EAP - TLS 1.3

I don’t want to push the decision in either direction without looking into the details. But I wanted to point out that there’s usually a third alternative between “no need for new documents” and “need a new RFC to describe the new version”. Explaining that the old protocol can be used and what

Re: [Emu] EAP - TLS 1.3

- RFC5216 is very much tied to the message flows and message formats in TLS 1.0 - 1.2. [BA] EAP-TLS encapsulates TLS within EAP so the basic protocol flow is not version dependent. The (non-normative) examples were designed to illustrate the EAP-TLS protocol flow, so though they are based o

[Emu] EAP - TLS 1.3

Hi Bernard, Coming back to our motivation for this draft. 3GPP has decided that authentication in 5G can be done with any type of credential that the operator accepts and that EAP will be used for authentication. The working assumption is that EAP-TLS will be used for mutual authentication wi