[Emu] Call for Agenda items for IETF 119

Please let the chairs know if you have any agenda items for the EMU meeting at IETF 119. Thanks, Joe and Peter ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu

[Emu] RFC 7170 bis

We are nearing completion of RFC7170bis. There are a few open issues in github - https://github.com/emu-wg/rfc7170bis/issues Issue 21 - links to the errata to verify that they have been addressed in the draft and provides text for resolving the

Re: [Emu] Q: TEAP and inner-method challenges

On Mon, Jun 5, 2023 at 9:23 PM Alan DeKok wrote: > In TTLS, any inner method challenge (CHAP / MS-CHAP) is tied to the TLS > session: > > https://www.rfc-editor.org/rfc/rfc5281.html#section-11.2.3 > > ... Upon receipt of these AVPs from the client, the TTLS server MUST >verify that the

[Emu] Working group Last Call for RFC 7170bis

This is the working group last call for draft-ietf-emu-rfc7170bis-05 [1]. Please review the draft and send comments to the list or open issues in GitHub [2]. Further discussion on the open issues will be considered as part of the last call. The last call ends March 24, 2023. The chairs would

Re: [Emu] Roman Danyliw's No Objection on draft-ietf-emu-tls-eap-types-12: (with COMMENT)

Thanks Alan, your text looks good. On Thu, Feb 16, 2023 at 5:48 AM Alan DeKok wrote: > On Feb 16, 2023, at 1:28 AM, Joseph Salowey wrote: > > [Joe] I think having a separate section in the security considerations > for Session Resumption is a good idea. A few comments on th

Re: [Emu] Roman Danyliw's No Objection on draft-ietf-emu-tls-eap-types-12: (with COMMENT)

On Wed, Feb 15, 2023 at 7:29 PM Alan DeKok wrote: > On Feb 15, 2023, at 9:53 PM, Roman Danyliw via Datatracker < > nore...@ietf.org> wrote: > > ** Section 2.4 > > It is therefore RECOMMENDED that EAP servers always send a TLS > > NewSessionTicket message, even if resumption is not

Re: [Emu] RFC7170bis and lack of identities

On Thu, Feb 2, 2023 at 11:17 AM Alan DeKok wrote: > On Feb 2, 2023, at 1:52 PM, Alexander Clouter > wrote: > >> I'm not clear how that would happen. Nothing in the doc discusses > >> how a client may choose authentication methods. > > > > The documentation does not but I did see Appendix C.9

[Emu] Canceling January 18 EMU interim

I don't think we have much to discuss this week, so I am going to cancel this week's interim. Please continue to discuss issues on the list and suggest PRs on github. We will likely have another interim in February. Thanks, Joe ___ Emu mailing list

Re: [Emu] Question about rfc7170bis && PAC

On Sun, Jan 15, 2023 at 7:40 AM Alan DeKok wrote: > One of the questions which came up at the interim call was about the > PAC. The discussion there was that PAC support was in hostap, but no other > implementations support it. > > Even more, there didn't seem to be much support for

Re: [Emu] Question about rfc7170bis && PAC

On Mon, Jan 16, 2023 at 7:36 AM Alan DeKok wrote: > On Jan 16, 2023, at 9:53 AM, Alexander Clouter > wrote: > > I was wondering what to do with A-ID[1] (and everything around PAC-Info) > but starting to figure that as you can stuff anything you want into the > opaque SessionTicket it really

[Emu] Agenda for EMU interim on January 11

EMU Interim - Wednesday 2023-01-11 09:00 PST https://meetings.conf.meetecho.com/interim/?short=18b67a69-dc0a-498c-90b5-4ddd9dbfb5e4 https://datatracker.ietf.org/meeting/interim-2023-emu-02/session/emu Agenda: 1. Errata 5770 and 5775. 2. Other technical issues with RFC 7170 Cheers, Joe

[Emu] Proposed resolution for TEAP errata 5767

Since this errata is about aligning terminology throughout the document I propose that this resolution would be "Hold for Update" since it would require editorial changes throughout the document. We would still need to resolve this issue in 7170bis. Any objection to this errata resolution?

[Emu] Resolution for TEAP Errata 5128

I think we still have an open issue with 5128. The following resolutions differ from what is currently in RFC7170bis. Please review the text changes below and indicate if it aligns with implementation and discussion. Thanks, Joe The definition of the TLS-PRF is given in 5246 as: PRF(secret,

[Emu] Resolution of TEAP Errata 5127

According to the discussion in the interim last week and previous discussions the resolution of errata 5127 should be as below. Please review the text change below and indicate if it aligns with discussion and implementation. It is intended that it matches the current draft of RFC7170bis draft

Re: [Emu] TEAP erratum 5775

On Tue, Jan 3, 2023 at 9:14 AM Alexander Clouter wrote: > On Tue, 3 Jan 2023, at 14:16, Eliot Lear wrote: > > My expectation is that you use the EMSK from the outer-TLS authentication > to do this calculation. > > However, I now understand your point about the *value* of doing this. > Generating

[Emu] Reminder EMU WG Virtual Interim 2023-01-04

The EAP Method Update (emu) WG will hold a virtual interim meeting on 2023-01-04 from 09:00 to 10:00 America/Los_Angeles (17:00 to 18:00 UTC). Upcoming interim meetings are listed here - https://datatracker.ietf.org/meeting/upcoming Agenda: 1. TEAP Errata a.

[Emu] EMU TEAP Interims

Not everyone could make it at the same time so I attempted to set up a series of meetings to go over the TEAP Errata and work on a revision in January. Wed January 4: 9:00-10:00 AM PT Wed January 11: 9:00-10:00 AM PT Wed January 18: 9:00-10:00 AM PT Joe

[Emu] EMU Interim Dates

We would like to hold an EMU interim to resolve TEAP errata and other TEAP issues. Here is a link for a doodle poll to find a date early next year where folks can make it: https://doodle.com/meeting/participate/id/bq79gK2e. If you plan on attending the interim please fill out the poll by

Re: [Emu] [EXTERNAL] Re: More TEAP issues

It sounds like we are gaining consensus to create a revision of TEAP. The emphasis would be (in priority order): - Aligning specification with current implementations - Clarifying the existing specification - Adding missing TLVs to make existing use cases work better The goal is to get

Re: [Emu] More TEAP issues

On Tue, Nov 29, 2022 at 2:35 PM Alan DeKok wrote: > Based on interoperability testing, it looks like implementations > followed EAP-FAST for derivation of the MS-MPPE keys, and not RFC 7170: > > http://lists.infradead.org/pipermail/hostap/2022-July/040639.html > >

[Emu] Presentations for Monday's meeting

The EMU meeting (Agenda ) is scheduled for Monday Afternoon (GMT). If you are presenting please either propose your slides in the data tracker or send them to the chairs. Thanks, Joe

[Emu] Publication has been requested for draft-ietf-emu-tls-eap-types-09

Joseph Salowey has requested publication of draft-ietf-emu-tls-eap-types-09 as Proposed Standard on behalf of the EMU working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-emu-tls-eap-types/ ___ Emu mailing

Re: [Emu] WG last call for draft-ietf-emu-tls-eap-types ?

I also notice that the document header says it updates RFC 5247 instead of RFC 4851. On Tue, Sep 20, 2022 at 12:50 PM Alan DeKok wrote: > On Sep 10, 2022, at 3:59 AM, Alexander Clouter > wrote: > > I have both implemented EAP-FAST and TEAP, and also slogged through the > interoperability

Re: [Emu] WG last call for draft-ietf-emu-tls-eap-types ?

On Sat, Sep 10, 2022 at 1:40 AM Alexander Clouter wrote: > Hello, > > On Fri, Sep 09, 2022 at 05:35:26PM -0400, Alan DeKok wrote: > > > >> I guess the argument is that those are the labels that are used in TEAP > (without exporter) and the same labels are used by EAP-FAST (with different >

Re: [Emu] Working Group Last Call For EAP-AKA'-PFS

Hi Folks, I realize this call coincided with the end of summer vacation for some. We need some review of this document before we can move it forward. Can a few people commit to reviewing? Thanks, Joe On Tue, Aug 16, 2022 at 1:41 PM Joseph Salowey wrote: > This is the working group l

Re: [Emu] WG last call for draft-ietf-emu-tls-eap-types ?

ey seed, session key generating function) which might lead to confusion. Cheers, Joe On Wed, Sep 7, 2022 at 6:54 AM Alan DeKok wrote: > On Sep 7, 2022, at 12:57 AM, Joseph Salowey wrote: > > I think we need to have some review of the EAP-FAST and TEAP sections > before publicat

Re: [Emu] WG last call for draft-ietf-emu-tls-eap-types ?

On Fri, Aug 12, 2022 at 1:24 PM Alan DeKok wrote: > On Aug 12, 2022, at 4:00 PM, Joseph Salowey wrote: > > [Joe] The chairs are reviewing the status and will have an update next > week. > > Thanks. > > > [Joe] Is the statement in the draft about lack of implementation

[Emu] Working Group Last Call For EAP-AKA'-PFS

This is the working group last call for EAP-AKA’ PFS (draft-ietf-emu-aka-pfs-07)[1]. Please note that the document is targeted at the informational track and has IPR declarations[2]. Please review the document and respond to the list indicating if you think the document is ready or not for

Re: [Emu] WG last call for draft-ietf-emu-tls-eap-types ?

On Thu, Aug 11, 2022 at 4:07 AM Alan DeKok wrote: > Can we make some progress on the document? There have been no > substantive comments for a while now. > > [Joe] The chairs are reviewing the status and will have an update next week. > The document is finished, the code is interoperable

Re: [Emu] IETF 114

You can also propose slides through the datatracker - https://datatracker.ietf.org/meeting/114/session/emu On Mon, Jul 25, 2022 at 9:38 AM Joseph Salowey wrote: > Please send your presentations for EMU at IETF 114 to the chairs. > > Thanks

[Emu] IETF 114

Please send your presentations for EMU at IETF 114 to the chairs. Thanks, Joe ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu

[Emu] Draft EMU Agenda for IETF 114

Draft EMU agenda is available here: https://datatracker.ietf.org/meeting/114/materials/agenda-114-emu And copied Below: IETF 114 - EMU Agenda (draft) Wednesday Session III Wednesday, July 27, 2022 15:00-17:00 EDT Philadelphia, Sheraton Downtown, Independence A/B --

Re: [Emu] Call for EMU agenda Items for IETF 114

The EMU meeting is scheduled for 15:00-17:00 Wednesday Session III. Please let the chairs know if you would like to present. It would be good to get updates from authors for the current working group items. Thanks, Joe On Tue, May 31, 2022 at 9:10 AM Joseph Salowey wrote: > Please

[Emu] Working Group Last Call for draft-ietf-emu-tls-eap-types

This is the working group last call for draft-ietf-emu-tls-eap-types. You can find the document here: https://datatracker.ietf.org/doc/html/draft-ietf-emu-tls-eap-types Please respond to the list with comments by June 24, 2022. Responses that indicate that you have read the draft and think it

[Emu] Call for EMU agenda Items for IETF 114

Please let the chairs know if you have items for discussion for the upcoming meeting in Philadelphia. Thanks, Joe ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Call for Adaption for draft-chen-emu-eap-tls-ibs

to get a draft published and codepoints assigned. Thanks, Joe and Mohit On Sun, Apr 10, 2022 at 8:35 PM Joseph Salowey wrote: > This is an adoption call for EAP-IBS ( > https://datatracker.ietf.org/doc/draft-chen-emu-eap-tls-ibs/ > <https://eur01.safelinks.protection.outlook.com/?url

[Emu] Call for Adaption for draft-chen-emu-eap-tls-ibs

This is an adoption call for EAP-IBS ( https://datatracker.ietf.org/doc/draft-chen-emu-eap-tls-ibs/

[Emu] Note taker for IETF 113

We have a packed agenda so we would like to have some volunteers for note taking to avoid awkward delays at the beginning of the meeting. If you would like to volunteer for notetaker, let the chairs know. Thanks, Joe ___ Emu mailing list Emu@ietf.org

[Emu] Presentations for IETF 113

Presenters please provide slides ASAP. You can propose new slides through the datatracker or you can send them to the chairs. Thanks, Joe ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu

[Emu] Agenda Items for EMU at IETF 113

EMU has been scheduled for a 1 hour slot on Tuesday, March 22 at 13:00-14:00 UTC+1. The chairs would like to solicit input from the WG for agenda topics. Please send your agenda topics request and an estimate for how much time you will need to emu-cha...@ietf.org. Please note that we will

Re: [Emu] draft-ietf-emu-tls-eap-types

Thanks for the nudge on this. We just issued the WGLC for this document. Please send your reviews on that thread. On Thu, Feb 17, 2022 at 5:40 AM Alan DeKok wrote: > There has been nothing preventing anyone from reviewing the document at > any time in the last year. Since all of the

[Emu] Working Group Last Call for TLS-based EAP types and TLS 1.3

This is a working group last call for TLS-based EAP types and TLS 1.3. The document is available here: https://datatracker.ietf.org/doc/draft-ietf-emu-tls-eap-types/ Please review the document and provide comments by March 4, 2022 Thanks, Joe and Mohit

Re: [Emu] EMU Meetings

We are requesting a session at IETF 113. There has not been a whole lot of discussion on the list of any topic. Before scheduling an interim we would like to understand what the topics would be. Do we need an interim for EAP-Types or is it ready for last call? What is the working group

Re: [Emu] Francesca Palombini's No Objection on draft-ietf-emu-eap-tls13-20: (with COMMENT)

Thanks Francesca, We'll take a look at the reference substitution. It would be better to be accurate with the section. A quick check suggests that this shouldn't be too hard. It's also possible that some of the references may be in text that is updated. Cheers, Joe On Tue, Oct 5, 2021 at

Re: [Emu] Benjamin Kaduk's No Objection on draft-ietf-emu-eap-tls13-20: (with COMMENT)

Thanks for your review. Comments inline below: On Thu, Oct 7, 2021 at 4:17 PM Benjamin Kaduk via Datatracker < nore...@ietf.org> wrote: > Benjamin Kaduk has entered the following ballot position for > draft-ietf-emu-eap-tls13-20: No Objection > > When responding, please keep the subject line

[Emu] EMU Meetings

Mohit and I discussed some options for meetings this year. We think it would be better not to meet at IETF 112 and instead schedule some focused virtual interim meetings where we can address specific issues. These interims will most likely take place after IETF 112. If you have a topic you would

Re: [Emu] The EMU WG has placed draft-aviram-tls-deprecate-obsolete-kex in state "Call For Adoption By WG Issued"

Issued (entered by Joseph Salowey) > > The document is available at > https://datatracker.ietf.org/doc/draft-aviram-tls-deprecate-obsolete-kex/ > > > ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu

[Emu] Publication has been requested for draft-ietf-emu-eap-tls13-18

Joseph Salowey has requested publication of draft-ietf-emu-eap-tls13-18 as Proposed Standard on behalf of the EMU working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tls13/ ___ Emu mailing list

Re: [Emu] WG Last Call for Using EAP-TLS with TLS 1.3 (draft-ietf-emu-eap-tls13-17)

eg, Joe, all, >> On 7/8/21 8:06 AM, Joseph Salowey wrote: >> >> >> >> On Tue, Jul 6, 2021 at 10:08 PM Joseph Salowey wrote: >> >>> >>> >>> On Mon, Jun 28, 2021 at 8:11 AM Oleg Pekar >>> wrote: >>> >>>&g

Re: [Emu] WG Last Call for Using EAP-TLS with TLS 1.3 (draft-ietf-emu-eap-tls13-17)

On Thu, Jul 8, 2021 at 6:11 AM Alan DeKok wrote: > On Jul 8, 2021, at 2:52 AM, tom.ri...@securew2.com wrote: > > Maybe this has been discussed already, but we often see the need for > multiple root cas when people are migrating the root CA of their RADIUS > server. They would then configure both

Re: [Emu] WG Last Call for Using EAP-TLS with TLS 1.3 (draft-ietf-emu-eap-tls13-17)

On Tue, Jul 6, 2021 at 10:08 PM Joseph Salowey wrote: > > > On Mon, Jun 28, 2021 at 8:11 AM Oleg Pekar > wrote: > >> I still see unclearness in Section "2.2. Identity Verification", I'm >> trying to look from the implementer's perspective. >> >>

Re: [Emu] WG Last Call for Using EAP-TLS with TLS 1.3 (draft-ietf-emu-eap-tls13-17)

since > the peer may end up trusting servers for EAP authentication that are not > intended to be EAP servers for the network." > > [Joe] Thanks, I think that is better wording. > Regards, > Oleg > > On Mon, Jun 28, 2021 at 2:26 AM Joseph Salowey wrote: > &g

[Emu] WG Last Call for Using EAP-TLS with TLS 1.3 (draft-ietf-emu-eap-tls13-17)

This is the working group last-call (WGLC) for draft-ietf-emu-eap-tls13. Please review the draft, focus on the changes since the last WGLC and submit your comments to the list by July 8, 2021. The IETF datatracker status page for this draft is:

Re: [Emu] Minor PR on eap-tls13

On Thu, Jun 24, 2021 at 4:43 PM Joseph Salowey wrote: > > > On Tue, Jun 22, 2021 at 6:02 AM Alan DeKok > wrote: > >> https://github.com/emu-wg/draft-ietf-emu-eap-tls13/issues/86 >> >> I didn't see anything on cross-protocol use of certs. >> >&g

Re: [Emu] Minor PR on eap-tls13

On Tue, Jun 22, 2021 at 6:02 AM Alan DeKok wrote: > https://github.com/emu-wg/draft-ietf-emu-eap-tls13/issues/86 > > I didn't see anything on cross-protocol use of certs. > > i.e. Section 2.2 suggests that the certs contain an FQDN. But it's > likely bad practice to allow the same cert to

Re: [Emu] draft-ietf-emu-eap-tls13-16.txt

On Thu, Jun 17, 2021 at 9:55 AM Alan DeKok wrote: > On Jun 17, 2021, at 12:04 PM, John Mattsson > wrote: > > I have made a single PR addressing all the currently listed issues in > the way suggested by Joe. > > > > https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pull/83/files > > > > - Does

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

Re: [Emu] draft-ietf-emu-eap-tls13-16.txt

On Fri, Jun 11, 2021 at 11:29 AM Alan DeKok wrote: > On Jun 11, 2021, at 2:12 PM, Mohit Sethi M > wrote: > > The comment here says adding text about "TLS version negotiation". There > > is a comment from you below saying: "I don't understand why it's > > necessary to include discussion of TLS

Re: [Emu] I-D Action: draft-ietf-emu-eap-tls13-16.txt

Hi Folks, I realize that there is frustration with the current document and process. I ask that we all focus on finishing off the current document so that we can move it forward. This does require that we consider the issues on the table. I think we are close to the finish line. I am asking

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

does not allow for the server certificate to change without out-of-band validation of the certificate and is therefore not suitable for many deployments including ones where multiple EAP servers are deployed for high availability. On Thu, May 20, 2021 at 10:23 PM Joseph Salowey wrote

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

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 >

Re: [Emu] WG Last Call for Using EAP-TLS with TLS 1.3

On Thu, May 6, 2021 at 12:11 PM Alan DeKok wrote: > > > > On May 5, 2021, at 11:33 AM, Joseph Salowey wrote: > > > > This is the working group last-call for draft-ietf-emu-eap-tls13. > Please review the draft, focus on the recent changes and submit your > commen

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 &g

Re: [Emu] Consensus call on EAP-TLS key derivation

s are repeated below for simplicity: > > > >MSK = Key_Material(0, 63) > >EMSK = Key_Material(64, 127) > [Joe] how about "are derived from Key_Material in the same manner as with EAP_TLS... " > > > John > > > > *From: *Emu on beha

[Emu] Consensus call on EAP-TLS key derivation

We had discussion on the list on whether to include context in the key derivation, but we never closed on the issue of separating out the MSK and EMSK derivation. As a result several implementers have gone down the path of implementing what is in draft 13 and not separating out the derivation.

Re: [Emu] WG Last Call for Using EAP-TLS with TLS 1.3

AP method implementation from scratch. The more guidance toward > this goal that can be included in the document the better, in my opinion. > > [Joe] Thanks, having a more voices chime in on issues can help resolve them more quickly and satisfactorily. > Jorge > > -Original Me

[Emu] WG Last Call for Using EAP-TLS with TLS 1.3

This is the working group last-call for draft-ietf-emu-eap-tls13. Please review the draft, focus on the recent changes and submit your comments to the list by May 20, 2021. Thanks, Joe The IETF datatracker status page for this draft is:

Re: [Emu] Issue 59 - Key Update

On Mon, Apr 12, 2021 at 4:58 AM Alan DeKok wrote: > On Apr 11, 2021, at 10:40 PM, Joseph Salowey wrote: > > This does seem to require some more specification. Here is a proposal. > > > > "TLS 1.3 introduced the Post-Handshake KeyUpdate message which is not > usefu

Re: [Emu] Issue 47 Certificate identity checks

On Mon, Apr 12, 2021 at 6:02 AM Eliot Lear wrote: > Hi Alan, > > On 12 Apr 2021, at 14:52, Alan DeKok wrote: > > > EAP TLS peer implementations MUST allow for configuration of a unique > trust root to validate the server's certificate. > > > This statement seems independent of the previous one,

Re: [Emu] Issue 47 Certificate identity checks

On Mon, Apr 12, 2021 at 5:48 AM Alan DeKok wrote: > On Apr 11, 2021, at 11:19 PM, Joseph Salowey wrote: > > RFC 5216 lacks guidance on how to validate the EAP server's certificate > especially with respect to identities. > > Yes. :) > > > RFC 5216 recommends vali

[Emu] Issue 61 Clarifying NAI handling during resumption

Please review and discuss the following on this thread. Alan's review raised the issue that the text allows for different identities to be used for the initial handshake and subsequent resumption. Instead the proposal is to always use the same NAI for resumption as for the initial handshake.

[Emu] Issue 47 Certificate identity checks

Please review the following proposal and discuss it on this thread. RFC 5216 lacks guidance on how to validate the EAP server's certificate especially with respect to identities. RFC 5216 recommends validating the certificate path is valid and that the extended key usage attributes are either

[Emu] Issue 59 - Key Update

Please review the following proposal and discuss issues on this thread. Alan's review pointed out the following Section 2.1.1 says: >TLS 1.3 introduced the Post-Handshake KeyUpdate >message which is not useful and not expected in EAP-TLS. > Q: What does it mean that the message is "not

Re: [Emu] Review of draft-ietf-emu-eap-tls13

I went through the review and created issues for the ones that were not covered by existing issues or PRs. Some issues, such as Issue 58 on nits contain several of the comments below. Issues may be discussed on the list or in github issues, however resolutions for any normative or substantial

[Emu] Resolving EAP-TLS issues

The authors have been working on the draft-ietf-emu-eap-tls13 in the GitHub Repo (https://github.com/emu-wg/draft-ietf-emu-eap-tls13). Below is a brief summary of the Issues and PRs that have recently been merged or ready to be merged. If you are aware of issues that are not currently tracked in

[Emu] Github repo for EAP-TLS 1.3 document

Hi Folks, I want to make the working group aware that there is a github repo for EAP-TLS 1.3. https://github.com/emu-wg/draft-ietf-emu-eap-tls13 I've asked the authors not to update the document directly, but rather use issues and PRs that can be discussed. I encourage other members of the

[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

[Emu] EAP-TLS key derivation resolution

The current draft test specifies the following for key derivation: Type-Code = 0x0D MSK= TLS-Exporter("EXPORTER_EAP_TLS_MSK_"+Type-Code, "",64) EMSK = TLS-Exporter("EXPORTER_EAP_TLS_EMSK_"+Type-Code, "",64)

[Emu] Call for Agenda Items for IETF 110

The EMU meeting at IETF 110 will be on Monday, March 8, 2021, from 13:00-15:00 CET. Please send the chairs (emu-cha...@ietf.org) requests for presentation slots. Don't forget to include the title of your presentation, related drafts, and the approximate amount of time needed. Joe and Mohi

Re: [Emu] Consensus call for result indicators in EAP-TLS 1.3

On Fri, Feb 19, 2021 at 3:32 AM Alan DeKok wrote: > On Feb 19, 2021, at 12:26 AM, Joseph Salowey wrote: > > I'd like to hear from implementers about their experience with this > mechanism: > > Was this both Peer and server implementation? > > > 1. Have yo

Re: [Emu] Consensus call for result indicators in EAP-TLS 1.3

o cause the message to be sent for the server or determine that the message was received for the peer/supplicant? c. Did you run into any issues with this mechanism? Joe On Sat, Feb 6, 2021 at 5:22 PM Joseph Salowey wrote: > There is growing support for mandating result indicators for EAP-TLS 1.3. >

Re: [Emu] Protected Result Indicators in EAP-TLS 1.3

On Sun, Feb 14, 2021 at 6:47 PM Benjamin Kaduk wrote: > On Wed, Feb 10, 2021 at 10:48:10AM +, John Mattsson wrote: > > With Alan's comments, I think we are down to 3 alternatives: > > > > (1a). Use close_notify alert as protected success. > > Use error alerts as protected failure. > >

[Emu] Publication has been requested for draft-ietf-emu-eap-noob-03

Joseph Salowey has requested publication of draft-ietf-emu-eap-noob-03 as Proposed Standard on behalf of the EMU working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-emu-eap-noob/ ___ Emu mailing list Emu

[Emu] Key Derivation for EAP-TLS 1.3

I'd like to get feedback from the working group on the EAP-TLS 1.3 key derivation. Does this improve the security of the system? Are there any implementation barriers? The key derivation for TLS 1.3 uses the key exporters defined for TLS 1.3. A few reviews have pointed out that the exporter

[Emu] Consensus call for result indicators in EAP-TLS 1.3

There is growing support for mandating result indicators for EAP-TLS 1.3. The result indicators help protect the EAP protocol exchange in the many different types of environments EAP-TLS is used and make the integration with the EAP state machine clearer. This has the impact of adding a round

[Emu] Way Forward for EAP-TLS 1.3

Based on John's email [1] and a few other discussions I've had offline I'm proposing the following series of consensus calls to find a path forward: 1. Consensus on requiring result indicators using a 4.5 roundtrip protocol. I think this is a conservative approach that could move forward

Re: [Emu] EAP-TLS protected result indications

On Tue, Feb 2, 2021 at 11:41 AM Bernard Aboba wrote: > Joe Salowey said: > > "[Joe] Based on RFC 5216 the server could fail the finished message or as > > section 2.1.3 shows it could send the finish and then it can send an Alert > and result in EAP-Failure. In this case it would be possible

Re: [Emu] Underspecification of EAP-TLS 1.3 State Machine

On Tue, Feb 2, 2021 at 2:10 PM Alan DeKok wrote: > On Feb 2, 2021, at 4:42 PM, John Mattsson 40ericsson@dmarc.ietf.org> wrote: > > 4. was something I thought was clear. The -13 version states that “The > EAP-TLS server commits to not send any more handshake messages”. This was > according

Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

On Mon, Feb 1, 2021 at 8:23 PM Benjamin Kaduk wrote: > On Mon, Feb 01, 2021 at 07:09:14AM -0500, Alan DeKok wrote: > > On Jan 31, 2021, at 9:16 PM, Benjamin Kaduk wrote: > > > That's a scenario that I was starting to puzzle over this weekend as > well > > > -- with EAP-Success "completely

Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

On Mon, Feb 1, 2021 at 12:04 PM Alan DeKok wrote: > On Feb 1, 2021, at 3:00 PM, Joseph Salowey wrote: > > [Joe] What purpose is the CloseNotify serving? RFC 5216 does not require > CloseNotify. > > With TLS 1.2, the server sends TLS Finished to the client *after* it >

Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

On Mon, Feb 1, 2021 at 11:55 AM Alan DeKok wrote: > On Feb 1, 2021, at 2:32 PM, Joseph Salowey wrote: > > > > > > > > On Mon, Feb 1, 2021 at 11:25 AM Alan DeKok > wrote: > > On Feb 1, 2021, at 11:26 AM, Eric Rescorla wrote: > > > Yes, this is wha

Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

On Mon, Feb 1, 2021 at 11:25 AM Alan DeKok wrote: > On Feb 1, 2021, at 11:26 AM, Eric Rescorla wrote: > > Yes, this is what I have in mind. So, maybe there's never any need for > the server to say "I won't say anything more" after just one round trip? > > I think so, yes. > > That means of

Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

On Mon, Feb 1, 2021 at 9:12 AM Benjamin Kaduk wrote: > Hi Alan, > > I'll second the thanks for putting this together; I think it covers the > important open points. > > I did belatedly remember one more thing that is perhaps not critical, but > would also be good to get an answer for: > > On

Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

On Sun, Jan 31, 2021 at 6:17 PM Benjamin Kaduk wrote: > On Sun, Jan 31, 2021 at 09:20:57AM -0500, Alan DeKok wrote: > > On Jan 29, 2021, at 5:00 PM, Joseph Salowey wrote: > > > DISCUSS: the EAP-TLS draft should also explain that session tickets > may be sent either bef

Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

HI Alan, THanks for this message, comments inline below: On Fri, Jan 29, 2021 at 12:02 PM Alan DeKok wrote: > This is a new message to summarize history, requirements, etc. for > EAP-TLS and TLS 1.3. The focus here is the requirements for EAP-TLS, and > how the 0x00 commitment message

Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

On Fri, Jan 29, 2021 at 11:34 AM Mohit Sethi M wrote: > Hi Ben, > On 1/29/21 8:32 PM, Benjamin Kaduk wrote: > > Hi Alan, > > I see that the thread is continuing and that perhaps my reply will even > become stale as I write it, but I'm replying to your note instead of the > tip of the thread

Re: [Emu] NewSessionTicket, Resumption, close_notify, and number of round-trips

On Wed, Jan 27, 2021 at 7:17 AM Alan DeKok wrote: > On Jan 27, 2021, at 10:09 AM, John Mattsson 40ericsson@dmarc.ietf.org> wrote: > > > > Looking at the GitHub version after the latest changes. I don't think > the tradeoffs make sense anymore. > > > > - Full handshake is now 4.5 round-trips

Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

different EAP methods all loosely based on EAP-TLS. I don't see this usage as too far outside the intended use of the context field (the value should match on both sides) and I think including the type value in the context value would help avoid some potential implementation problems if the key derivation

[Emu] Fwd: [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

Forwarded this conversation from the TLS list. The question is about changing the key derivation. Joe -- Forwarded message - From: Joseph Salowey Date: Tue, Jan 5, 2021 at 10:24 PM Subject: Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13

  1   2   3   4   >