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

On Tue, Jan 5, 2021 at 8:31 AM Alan DeKok wrote: > On Jan 5, 2021, at 11:13 AM, Mohit Sethi M > wrote: > > > > Hi Alan, > > > > Cleaning up the email. The current draft says the exporter should be > called once as: > > > >>Key_Material = TLS-Exporter("EXPORTER_EAP_TLS_Key_Material", > >>

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

On Tue, Jan 5, 2021 at 8:14 AM Mohit Sethi M wrote: > Hi Alan, > Cleaning up the email. The current draft says the exporter should be > called once as: > >Key_Material = TLS-Exporter("EXPORTER_EAP_TLS_Key_Material", >Type-Code, 128) > > and then split the 128

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

On Mon, Jan 4, 2021 at 6:08 AM Alan DeKok wrote: > On Jan 3, 2021, at 10:44 PM, Martin Thomson wrote: > > # Key Schedule > > > > The other thing I observe is the way that this slices up the exporter > output. This was something that old versions of TLS did, but TLS 1.3 did > away with. Though

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

Hi Martin, Thanks for taking a look at this, some comments below: On Sun, Jan 3, 2021 at 7:45 PM Martin Thomson wrote: > Hi All, > > Ben asked me to take a look at this draft and I think that the general > gist of Ben's comments need some careful consideration. > > # Commitment Message > > I

Re: [Emu] Revised resolution for TEAP erratum 5127

ength of 32 octets with zeros if it is less than 32 octets. Cheers, Joe On Thu, Oct 29, 2020 at 10:05 PM Joseph Salowey wrote: > I think this erratum is done. I've also started a GH repo to track the > changes in the document which might help show them in context a bit better. > The

Re: [Emu] Proposed Resolution for TEAP errata 5768

C fields zeroed out. 2 The EAP Type sent by the other party in the first TEAP message. This is a single octet encoded as (0x37) > Jorge Vergara > > > > *From:* Oleg Pekar > *Sent:* Saturday, October 24, 2020 4:30 PM > *To:* Joseph Salowey > *Cc:* EMU WG ; Joun

[Emu] Working Group Last Call for draft-ietf-emu-eap-noob-02

At IETF 109 meeting there was support for moving EAP-NOOB forward. The chairs and authors believe the document is ready to progress so this starts the working group last call for EAP-NOOB [1]. Please review the document and send comments to the list by December 11, 2020. Statements of support

[Emu] EMU at IETF 109

If you are presenting at IETF 109 tomorrow please send your slides to the chairs. Friday, November 20, 2020 12:00 - 14:00 (+07) Agenda Meeting Information 1. Participants Guide

Re: [Emu] Proposed Resolution to TEAP Errata 5844

s "An Intermediate-Result TLV indicating success MUST be accompanied by a Crypto-Binding TLV." Maybe it should say: "Upon receiving the response, the server MUST indicate the success or failure of the exchange using an Intermediate-Result TLV accompanied by a Crypto-Binding

Re: [Emu] Agenda Items for virtual IETF 109

t; On 11/4/20 7:33 AM, Joseph Salowey wrote: > > At the virtual IETF 100 meeting, we will have a 2 hour session on > Friday, November 20, between 12:00 - 14:00 UTC. > > ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu

[Emu] Agenda Items for virtual IETF 109

At the virtual IETF 100 meeting, we will have a 2 hour session on Friday, November 20, between 12:00 - 14:00 UTC. 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

[Emu] Proposed TEAP Errata Resolution Summary

Below is the summary of the TEAP errata resolutions. The text that will be sent to the AD is in the linked emails. The GitHub PR is provided to make it easier to review the revision in context. Anything that is marked for final review will be sent to the AD next week if there are no objections

Re: [Emu] Proposed Resolution for Errata 5845

tion 3.3.1 text: >> >> >Section 3.3.1 >> > >> >It should say: >> >> > EAP method messages are carried within EAP-Payload TLVs defined in >> > Section 4.2.10. Upon completion of each EAP authentication method in >> > the tunnel, t

Re: [Emu] Proposed Resolution to TEAP Errata 5844

hods. 4.2.11 should note Intermediate-Result TLV is used with both inner EAP and basic password auth. On Mon, Oct 26, 2020 at 8:44 PM Joseph Salowey wrote: > > > On Mon, Oct 26, 2020 at 8:39 PM Joseph Salowey wrote: > >> >> >> On Mon, Oct 26, 2020 at 1:27 AM Oleg

[Emu] Revised TEAP Erratum 5770

This revision removes the modification to section 5.4 to erratum 5775. It also leaves the discussion of the 0 MSK to a separate paragraph to be revised in 5770. I think this revision is ready. Please comment on the list or the PR if you do not think it is ready. PR for section 5:

[Emu] Revised Erratum for 5775

The section 5 revision is rewritten to reflect handling of the case where no MSK is generated and text on handling the 0 MSK is moved from errata 5770. this erratum could use more review. Please comment on the list or in the PR. Section 4 PR - https://github.com/emu-wg/teap-errata/pull/12

[Emu] Revised Resolution for TEAP erratum 5768

This revision has small changes to the text in the length field and changes the text that describes what j represents to the last successfully generated IMCK. I think this revision is ready. Please comment on the list or the PR if you do not think it is ready. PR for section 5 is:

Re: [Emu] Proposed resolution for TEAP errata 5765

On Fri, Oct 23, 2020 at 9:20 AM Jouni Malinen wrote: > On Thu, Oct 22, 2020 at 05:44:33PM +0300, Oleg Pekar wrote: > > The Authority-ID TLV is used by the client to identify the TEAP server it > > is talking to. If the same client talks to more than one TEAP server - it > > can keep PACs or

Re: [Emu] Consensus Call on OCSP usage in draft-ietf-emu-eap-tls13-11

On Fri, Oct 30, 2020 at 4:44 AM Michael Richardson wrote: > > Joseph Salowey wrote: > >> I suggest: > >> > >> “EAP-TLS servers supporting TLS 1.3 that use OCSP to do certificate > >> recovation checks, MUST implement Certificate Stat

[Emu] Revised resolution for Erratum 5128

I think this one is also done. PR is here https://github.com/emu-wg/teap-errata/pull/4. Please comment on this thread or PR if you think it still needs work: Errata 5128: https://www.rfc-editor.org/errata/eid5128 Proposed State: Verified Revision: Section 5.2. says S-IMCK[0] =

Re: [Emu] Consensus Call on OCSP usage in draft-ietf-emu-eap-tls13-11

On Thu, Oct 29, 2020 at 3:12 PM Michael Richardson wrote: > > Joseph Salowey wrote: > > 2. Require Servers to Implement and Recommended to Use OCSP with text > > similar to the following: > > I don't think that this text is quite right. > > I note t

Re: [Emu] Consensus Call on OCSP usage in draft-ietf-emu-eap-tls13-11

gt; > *From: *Emu on behalf of Eliot Lear 40cisco@dmarc.ietf.org> > *Date: *Thursday, October 29, 2020 at 10:53 AM > *To: *Joseph Salowey > *Cc: *EMU WG > *Subject: *Re: [Emu] Consensus Call on OCSP usage in > draft-ietf-emu-eap-tls13-11 >

[Emu] Consensus Call on OCSP usage in draft-ietf-emu-eap-tls13-11

An issue was raised in a review of draft-ietf-emu-eap-tls13-11 on the mandatory requirement for OCSP stapling [1]. The document makes the use of OCSP mandatory in section 5.4 [2]. Several folks have pointed out that this may not be feasible in all deployments. This is a quick consensus call for

Re: [Emu] Proposed Resolution to TEAP Errata 5770

On Tue, Oct 27, 2020 at 12:23 AM Eliot Lear wrote: > Hi, > > > > > [Joe] Yes I think it is fine to say EAP authentication method. I have > been convinced that the spec requires crypto-binding with the basic > password authentication. I'll need to add this in. > > > > Keep in mind that there

Re: [Emu] draft-ietf-emu-eap-tls13-11: OCSP Stapling

ing)? Would the recommendations also apply > to EAP methods that use TLS under the hood, such as TEAP, EAP-FAST, or > EAP-TTLS? Would they apply to methods like EAP-IKEv2 or the recently > suggested EAP-EDHOC, which are also methods that use certificates? > [Joe] the document under

Re: [Emu] draft-ietf-emu-eap-tls13-11: OCSP Stapling

iscuss revocation issues. It seems there are several questions that need to be answered: 1. Should the document mandate that OCSP stapling be used? 2. Should the document mandate that OCSP stapling be implemented? 3. What should the document say in the security sections with respect to OCSP stapling and o

Re: [Emu] Proposed Resolution to TEAP Errata 5770

username and password > authentication so I don’t have any prior experience here. > > [Joe] Yes I think it is fine to say EAP authentication method. I have been convinced that the spec requires crypto-binding with the basic password authentication. I'll need to add this in. > &

Re: [Emu] Proposed Resolution to TEAP Errata 5844

or acknowledged intermediate Success and Failure messages for inner EAP authentication methods or basic password authentication. > > On Sun, Oct 25, 2020 at 9:10 PM Joseph Salowey wrote: > >> Errata 5844: https://www.rfc-editor.org/errata/eid5844 >> Status: Verified >&g

Re: [Emu] Proposed Resolution for Errata 5845

; > EAP method messages are carried within EAP-Payload TLVs defined in > > Section 4.2.10. Upon completion of each EAP authentication method in > > the tunnel, the server MUST send an Intermediate-Result TLV > > indicating the result. > > [Joe] Yes, I think you are correct.

Re: [Emu] Proposed resolution for TEAP errata 5775

On Mon, Oct 26, 2020 at 1:25 AM Oleg Pekar wrote: > It Should say: >> >> S-IMCK[j] = first 40 octets of IMCK[j] >> CMK[j] = last 20 octets of IMCK[j] >> where TLS-PRF is the PRF negotiated as part of TLS handshake [RFC5246]. >> If no inner EAP method has been run the S-IMCK and CMK are

[Emu] Proposed Resolution for TEAP Errata 6157

Errata 6157: https://www.rfc-editor.org/errata/eid6157 Proposed Status: Verified Revision: Section 4.2.9 says: Status The Status field is one octet. This indicates the result if the server does not process the action requested by the peer. It should say: Status The

[Emu] Proposed Resolution for Errata 5845

Errata 5845: https://www.rfc-editor.org/errata/eid5845 Proposed Status: Verified Revision: Section 3.3.1 says: EAP method messages are carried within EAP-Payload TLVs defined in Section 4.2.10. If more than one method is going to be executed in the tunnel, then upon method completion,

[Emu] Proposed Resolution to TEAP Errata 5844

Errata 5844: https://www.rfc-editor.org/errata/eid5844 Status: Verified Revision: Section 3.3.2 says: Upon receiving the response, the server indicates the success or failure of the exchange using an Intermediate-Result TLV. It Should say: Upon receiving the response, the server MUST

[Emu] Proposed resolution for TEAP errata 5775

Errata 5775: https://www.rfc-editor.org/errata/eid5775 Proposed Status: Verified Revision: Section 5.2 Says: S-IMCK[j] = first 40 octets of IMCK[j] CMK[j] = last 20 octets of IMCK[j] where TLS-PRF is the PRF negotiated as part of TLS handshake [RFC5246]. It Should say: S-IMCK[j] =

Re: [Emu] Proposed Resolution for TEAP errata 5768

ut we certainly can include this information in the errata notes. > On Sun, Oct 25, 2020 at 12:45 AM Joseph Salowey wrote: > >> Errata 5768: https://www.rfc-editor.org/errata/eid5768 >> Proposed State: Verified >> Revision: >> >> Section 4.2.13. Says: >> >&g

[Emu] Proposed Resolution to TEAP Errata 5770

Errata 5770: https://www.rfc-editor.org/errata/eid5770 Proposed Status: Verified Revision: Section 5.2 Says: On the sender of the Crypto-Binding TLV side: If the EMSK is not available, then the sender computes the Compound MAC using the MSK of the inner method. If the EMSK is

[Emu] Proposed Resolution for TEAP errata 5768

Errata 5768: https://www.rfc-editor.org/errata/eid5768 Proposed State: Verified Revision: Section 4.2.13. Says: Length 76 It should say: Length 36 plus the length of the 2 MAC fields Section 4.2.13. Says: EMSK Compound MAC The EMSK Compound MAC field is 20 octets. This

Re: [Emu] Proposed resolution for TEAP errata for 5128

I think we have agreement on what the derivation would be now it's a matter of clearly describing it. Here is a proposal: IMCK[j] = the first 60 bytes of TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", IMSK[j]) where "|" denotes concatenation and the TLS-PRF is defined in

Re: [Emu] Proposed resolution for TEAP errata 5127

On Fri, Oct 23, 2020 at 9:11 AM Jouni Malinen wrote: > On Wed, Oct 21, 2020 at 02:14:45PM -0700, Joseph Salowey wrote: > > On Wed, Oct 21, 2020 at 12:11 PM Jouni Malinen wrote: > > > > > On Wed, Oct 21, 2020 at 09:30:33AM -0700, Joseph Salowey wrote: > > &g

Re: [Emu] draft-ietf-emu-eap-tls13-11: OCSP Stapling

On Thu, Oct 22, 2020 at 8:08 AM Eliot Lear wrote: > +1. How does anyone even do OCSP without having first gotten onto the > network? > > [Joe] THat is what OCSP stapling is supposed to solve since the OCSP messages are sent in the TLS handshake. I believe there are some EAP-TLS

Re: [Emu] Proposed resolution for TEAP errata for 5128

= P_hash(S-IMCK[j], "Session Key Generating Function” | 0x00 | 0x00 | 0x40) I think 1 or 2 is what was probably originally intended, however it seems that 3 is what has been implemented. Do we have agreement on this is what current implementations do? > Jorge, please correct me if I misint

Re: [Emu] Proposed resolution for TEAP errata for 5128

tional data can be arbitrary content the null prevents two different lablels with specially crafted optional data from deriving the same key. > > Oleg > > > On Thu, Oct 22, 2020 at 2:54 AM Joseph Salowey wrote: > >> (I accidentally dropped this list from the conversation

[Emu] Resolution of TEAP Errata 5767

Errata 5767: https://www.rfc-editor.org/errata/eid5767 Status: Verified Revision: Section 3.3.1 says: EAP method messages are carried within EAP-Payload TLVs defined in Section 4.2.10. If more than one method is going to be executed in the tunnel, then upon method completion, the

Re: [Emu] Proposed resolution for TEAP errata for 5128

C then > certainly their comments would be welcome. > > > By the way, we’ve dropped the EMU group on our replies here – not sure if > intentional or not. > > > > Jorge Vergara > > > > *From:* Joseph Salowey > *Sent:* Wednesday, October 21, 2020 4:36 PM > *To

[Emu] Proposed resolution for TEAP errata 5765

Errata 5765: https://www.rfc-editor.org/errata/eid5765 Proposed Status: Verified Revision: (unmodified from original posting) Section 4.2.2 says: M Mandatory, set to one (1) It should say: M 0 (Optional) Notes: Authority-ID TLV is used only as an Outer TLV (in TEAP/Start)

[Emu] Proposed resolution for TEAP errata for 5128

Errata 5128: https://www.rfc-editor.org/errata/eid5128 Proposed State: Verified Revision: Section 5.2. says IMCK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", IMSK[j], 60) It should say: IMCK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", IMSK[j] | 60)

Re: [Emu] Proposed resolution for TEAP errata 5127

On Wed, Oct 21, 2020 at 12:11 PM Jouni Malinen wrote: > On Wed, Oct 21, 2020 at 09:30:33AM -0700, Joseph Salowey wrote: > > Errata 5127: https://www.rfc-editor.org/errata/eid5127 > > Proposed State: Verified > > Revision: > > Section 5.2. > > OLD > > >

[Emu] Proposed resolution for TEAP errata 5127

Errata 5127: https://www.rfc-editor.org/errata/eid5127 Proposed State: Verified Revision: Section 5.2. OLD IMSK = First 32 octets of TLS-PRF(EMSK, "teapbind...@ietf.org" | "\0" | 64) NEW IMSK = First 32 octets of TLS-PRF(EMSK, "teapbind...@ietf.org" | '/0', 64) Notes: According to

[Emu] Resolution of TEAP Errata

I'll be posting proposed errata revisions for a short, 1 week, final review before sending it off to the Area Director (Roman) who has the responsibility of the final action. For more information how errata are handled and the please see [1]. Please take a little time to review the errata

Re: [Emu] I-D Action: draft-ietf-emu-tls-eap-types-01.txt

On Wed, Sep 2, 2020 at 7:54 AM Alan DeKok wrote: > On Sep 2, 2020, at 3:30 AM, John Mattsson > wrote: > >> I can tell you what Windows is doing for TLS 1.2; and Windows interops > with all the TEAP implementations that I know of, so others are likely > doing the same. We're using the MAC

[Emu] Handling Large Certificates and Long Certificate Chains submitted for publication

Handling Large Certificates and Long Certificate Chains in TLS-based EAP Methods (draft-ietf-emu-eaptlscert-05) has been submitted to the IESG for publication. The shepherd write-up can be found here - https://datatracker.ietf.org/doc/draft-ietf-emu-eaptlscert/shepherdwriteup/ Cheers, Joe

[Emu] Publication has been requested for draft-ietf-emu-eaptlscert-05

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

Re: [Emu] Preparations for Friday

We will also need a note taker. If you are willing to take minutes, please contact the chairs. Link for notes (CodiMD) https://codimd.ietf.org/notes-ietf-108-emu Link to attend session (requires registration) https://meetings.conf.meetecho.com/ietf108/?group=emu==1 On Tue, Jul 28, 2020

Re: [Emu] TEAP - RFC 7170 - Errata ID 5768

> executed. What are your opinions on this? > > [Joe] I believe the original intent was that the same Compound MAC construction could be used in multiple protocols (EAP-FAST, PEAP, TEAP). Using the outer EAP method type would help protect against cross protocol attacks if this TLV wer

Re: [Emu] draft-dekok-emu-tls-eap-types discussion

d but not implemented. While it would be better if everyone implemented and used the EMSK, the MSK is better than using 0. I agree clients and servers will need some policy in this case. The policy does complicate the protocol and implementation. > > *From:* Joseph Salowey > *Sent:* Mo

Re: [Emu] draft-dekok-emu-tls-eap-types discussion

On Tue, Apr 21, 2020 at 11:02 AM Oleg Pekar wrote: > >And focusing on that "what to do here.." part and the unused IMCK-zero[j] >> in the previous paragraph.. >> >How is this supposed to work when an inner EAP authentication method >> does not derive either MSK or EMSK? >> >Intermediate result

Re: [Emu] Early allocation request for an EAP Method Type number for draft-ietf-emu-eap-noob

; in the early stages and will undergo many changes before it can be > considered for adoption by the working group. However, allocating a method > type number for EAP-NOOB now would ensure that EAP-TLS-PSK doesn't use the > same code point. > > --Mohit > On 5/26/20 6:56 AM, Joseph Sal

Re: [Emu] TEAP - RFC 7170 - Errata ID 5768

On Fri, May 22, 2020 at 1:18 PM Jorge Vergara wrote: > My review of this errata and the current responses from Oleg: > > > >1. I agree with this proposed resolution. I do think this is an >important omission that needs to be clarified in the RFC. Otherwise it is >somewhat guesswork

[Emu] Early allocation request for an EAP Method Type number for draft-ietf-emu-eap-noob

The authors of EAP-NOOB (draft-ietf-emu-eap-noob) have requested early allocation of the EAP type code value 56. If you object to the early code point assignment please let the list know why by June 14, 2020. The criteria for early assignment includes the following: A.The code points must

[Emu] Note Taker, Jabber Script and Slides EMU Virtual Interim on 5/22

The EMU virtual interim is Friday 2020-05-22 15:00 UTC. If you are presenting please send your slides to the chairs. We are also looking for Note Taker and Jabber Scribe Volunteers. Please send the chairs a note if you can help out. Cheers, Joe ___

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

Joseph Salowey has requested publication of draft-ietf-emu-eap-tls13-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-eap-tls13/ ___ Emu mailing list

Re: [Emu] WGLC for draft-ietf-emu-eap-tls13-09

The WGLC for this draft has been completed. Publication will be requested later this week. On Sun, Apr 19, 2020 at 3:37 PM Joseph Salowey wrote: > This is the second working group last call for EAP-TLS > (draft-ietf-emu-eap-tls13-09)[1]. The authors submitted a draft to address > t

[Emu] WGLC for draft-ietf-emu-eap-tls13-09

This is the second working group last call for EAP-TLS (draft-ietf-emu-eap-tls13-09)[1]. The authors submitted a draft to address the issues raised during the last working group last call. Please focus on the changes [2] in the latest draft and send any comments to the list by May 4, 2020.

[Emu] Working Group Call For adoption of draft-aura-eap-noob-08.txt

This is a call for adoption of draft-aura-eap-noob-08.txt [1] as a working group item. This draft has been discussed in several IETF meetings and would be the starting point for the working group deliverable for an EAP method based on "mutual authentication between a peer and a server that is

[Emu] EMU@IETF017: Agenda Topics

Please send any agenda requests to the chairs at emu-cha...@ietf.org. Thanks Joe ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu

[Emu] WGLC for draft-ietf-emu-eaptlscert (corrected)

Hi Folks, This is the working group last call for the "Large Certificates in TLS-based EAP Methods" draft available at https://datatracker.ietf.org/doc/draft-ietf-emu-eaptlscert/ ( https://tools.ietf.org/html/draft-ietf-emu-eaptlscert-00). Please review the document and send your comments to the

[Emu] WGLC for draft-davidben-tls13-pkcs1-00

Hi Folks, This is the working group last call for the "Large Certificates in TLS-based EAP Methods" draft available at https://datatracker.ietf.org/doc/draft-ietf-emu-eaptlscert/. Please review the document and send your comments to the list by 2359 UTC on 16 March 2020. Note the the GH repo for

Re: [Emu] Processing of TEWAP erratum 5127

> >> Could it be that this text refers to RFC 5295: >> >> If an inner method supports export of an Extended Master Session Key >> (EMSK), then the IMSK SHOULD be derived from the EMSK as defined in >> [*RFC5295*]. The usage label used is "teapbind...@ietf.org", and the >> length is 64 octets.

Re: [Emu] Processing of TEWAP erratum 5127

On Mon, Nov 25, 2019 at 5:43 AM Eliot Lear wrote: > Hi Juoni, > > Thanks for taking the time. I suspect this will take a few iterations to > get the actual text right, as I am drinking water from a fire hose here. > Please bear with me. > > On 24 Nov 2019, at 12:31, Jouni Malinen wrote: > > On

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

There has been a lot of discussion on this thread, but I do not see anything actionable for the EAP-TLS 1.3 specification. Joe On Wed, Jan 8, 2020 at 12:48 PM Alan DeKok wrote: > On Jan 8, 2020, at 3:00 PM, Michael Richardson > wrote: > > > > > > Alan DeKok wrote: > >alan> Many people

Re: [Emu] AD review of draft-ietf-emu-rfc5448bis-06

On Wed, Jan 15, 2020 at 2:24 PM Roman Danyliw wrote: > Hello! > > I conducted an AD review of draft-ietf-emu-rfc5448bis-06 and this document > is in good shape. Thanks for all of the work on it. I have minor > questions and editorial nits which can be addressed with the IETF Last Call >

[Emu] Publication has been requested for draft-ietf-emu-rfc5448bis-06

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

[Emu] Presentations for IETF 106

If you are on the agenda [1] for IETF 106 in Singapore please send your slides to emu-cha...@ietf.org as soon as possible as the meeting is on Monday. Failure to send your slides before the day of the meeting may result in your presentation being pushed to the end of the agenda. [1]

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

On Mon, Nov 11, 2019 at 11:41 AM Alan DeKok wrote: > On Nov 11, 2019, at 12:52 PM, Owen Friel (ofriel) > wrote: > > > > [ofriel] Is the primary reason they MUST NOT be copied because of > encoding differences? UTF-8 vs. TLS raw bytes? > > Yes. EAP Identities are UTF-8 encoded strings.

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

On Fri, Nov 1, 2019 at 4:08 AM Alan DeKok wrote: > On Nov 1, 2019, at 6:15 AM, John Mattsson > wrote: > > I strongly support working group adoption of > draft-dekok-emu-tls-eap-types. Can we make sure to get this document going, > I agree that this is a very needed draft. I think it should

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

On Wed, Oct 30, 2019 at 4:12 AM Alan DeKok wrote: > On Oct 30, 2019, at 5:02 AM, Eliot Lear wrote: > > A fair argument, if it can be made, and I am not convinced it has been > fully expressed, is the idea that there is no context by which one can > separate fast restart and initial

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

Hi Jorge, Thanks for joining the conversation. On Wed, Oct 30, 2019 at 6:11 PM Jorge Vergara wrote: > Hello - I am the primary maintainer of Microsoft's EAP implementation. I > am sorry for joining late to this conversation, but hope our input is > welcome. > > On the topic of

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

On Fri, Oct 11, 2019 at 7:34 AM Eliot Lear wrote: > > > > On 11 Oct 2019, at 16:09, Michael Richardson wrote: > > > > So, can wired just be a degenerate version of wifi, where there can be > only > > one "ESSID", and there are no beacons to consider? > > > On the whole that has been my thought.

Re: [Emu] TEAP errata 5770

On Tue, Oct 8, 2019 at 10:46 PM Joseph Salowey wrote: > Based on Jouni's analysis the derivation of the S-IMCKs is not well > specified. To me it looks like the solution to handle an arbitrary number > of methods that may or may not make an EMSK available would be fairly > complex.

[Emu] TEAP errata 5770

Based on Jouni's analysis the derivation of the S-IMCKs is not well specified. To me it looks like the solution to handle an arbitrary number of methods that may or may not make an EMSK available would be fairly complex. I think the most straight forward solution is to either always assume that

[Emu] TEAP Errata 5768

We need to come to resolution on how to resolve these errata. I hope there has been enough time for implementors to catch up with Jouni's implementation. The Crypto-Binding TLV is fixed at 20 octets and the draft does not say how to handle longer MACs. The discussion seems to indicate that we

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

There is a TLS working group draft on importing external PSKs for use with TLS - https://tools.ietf.org/html/draft-ietf-tls-external-psk-importer-01. This draft can mitigate some of the issues with using external PSKs. My suggesting is to leave the draft as is and deal with external PSKs as an

Re: [Emu] Call for adoption of draft-dekok-emu-eap-session-id-01

The for adoption has completed without any objection. Please submit the draft as draft-ietf-emu-eap-session-id. Thanks, Joe On Wed, Jul 31, 2019 at 8:48 PM Joseph Salowey wrote: > This is a call for adoption for draft-dekok-emu-eap-session-id-01 as a EMU > working group item. This

Re: [Emu] Call for adoption of draft-ms-emu-eaptlscert-03

This call has completed with no objection. Please submit the draft as draft -ietf-emu-eaptlscert-00. Thanks, Joe On Wed, Jul 24, 2019 at 12:47 PM Joseph Salowey wrote: > This is a call for adoption for draft-ms-emu-eaptlscert-03 as a EMU > working group item. This draft has had suppor

[Emu] Call for adoption of draft-dekok-emu-eap-session-id-01

This is a call for adoption for draft-dekok-emu-eap-session-id-01 as a EMU working group item. This draft had support at the working group meeting. If you object to adopting this work item please respond by August 12, 2019. Thanks, Joe ___ Emu

Re: [Emu] EAP-AKA' and Re: WG adoption call for draft-arkko-eap-aka-pfs

Based on the responses on this thread and in the IETF 105 EMU meeting we are going to accept this document as a working group item. Cheers, Joe On Thu, Jun 27, 2019 at 1:55 PM Alan DeKok wrote: > On Jun 27, 2019, at 12:51 PM, Joseph Salowey wrote: > > > > Significant

[Emu] Call for adoption of draft-ms-emu-eaptlscert-03

This is a call for adoption for draft-ms-emu-eaptlscert-03 as a EMU working group item. This draft has had support from the WG for the past 2 meeting. If you object to this call for adoption please respond by August 6, 2019. Thanks, Joe ___ Emu

Re: [Emu] RFC 7170 (TEAP) errata

On Mon, Jul 1, 2019 at 4:11 PM Jouni Malinen wrote: > > > (2) S-IMCK[j] derivation when inner EAP methods in the sequence derive > both MSK and EMSK (or even more complicated, if there are multiple inner > EAP authentication methods that have difference in whether they derive MSK > or EMSK): >

Re: [Emu] RFC 7170 (TEAP) errata

On Mon, Jul 1, 2019 at 4:11 PM Jouni Malinen wrote: > > > (1) Crypto-Binding TLV format for the cases where the negotiated TLS > cipher suite uses SHA256 (or SHA384, for that matter) instead of SHA-1 (and > I'd hope all deployments of TEAP would be recent enough to avoid use of > SHA-1..): >

[Emu] EMU Agenda and presentations

The agenda for the EMU meeting at IETF 105 has been posted ( https://datatracker.ietf.org/meeting/105/materials/agenda-105-emu). We have a pretty full schedule. The chairs have the following asks of presenters: 1. Slides for non-working group drafts should be sent to the chairs 48 hours before

Re: [Emu] [Technical Errata Reported] RFC7170 (5765)

This report looks to be valid and straight forward. Any objections to verifying and accepting this errata report? On Fri, Jun 28, 2019 at 1:16 AM RFC Errata System wrote: > The following errata report has been submitted for RFC7170, > "Tunnel Extensible Authentication Protocol (TEAP) Version

Re: [Emu] EAP-AKA' and Re: WG adoption call for draft-arkko-eap-aka-pfs

submission track. Do working group members still have objections to taking this draft into the working group? Please respond on this thread by July 5, 2019. Thanks, Joe On Wed, Apr 3, 2019 at 4:59 AM Alan DeKok wrote: > On Apr 3, 2019, at 1:37 AM, Joseph Salowey wrote: > > &

[Emu] WGLC completed for for draft-ietf-emu-eap-tls13-05

The Working Group last call has completed with no comments for draft-ietf-emu-eap-tls13-05. I would like to confirm that some working group members have reviewed the draft. If you have reviewed the draft please respond to this thread. THanks, Joe ___

[Emu] WGLC for draft-ietf-emu-eap-tls13-05

This is the working group last call for "Unsing EAP-TLS with TLS 1.3" - https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-05. Please review the document and send your comments to the list by June 18, 2019. Thanks, Joe ___ Emu mailing list

Re: [Emu] EAP-AKA' and Re: WG adoption call for draft-arkko-eap-aka-pfs

Thanks for reviving this thread. I agree this is important work, but we need to have consensus to bring the item into the working group. I think the IPR issue is the main sticking point. I'll note that RFC 5448 has a similar IPR declaration and both documents are targeted as informational.

[Emu] WGLC for RFC5448bis

This is the working group last call for draft-ietf-emu-rfc5448bis-04 . Please send your comments to the list by 3/1/2019. Thanks, Joe and Mohit ___ Emu mailing list Emu@ietf.org

Re: [Emu] WG adoption call for draft-arkko-eap-aka-pfs

Please note there are IPR disclosure for draft-arkko-eap-aka-pfs-03.txt <https://www.ietf.org/id/draft-arkko-eap-aka-pfs-03.txt> available at https://datatracker.ietf.org/ipr/search/?submit=draft=draft-arkko-eap-aka-pfs .. Thanks, Joe On Thu, Nov 8, 2018 at 10:13 AM Joseph Salowey

[Emu] WGLC for draft-ietf-emu-rfc5448bis

This is the working group last call for the draft revision of "Improved Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA')" available at https://datatracker.ietf.org/doc/draft-ietf-emu-rfc5448bis/ Please review the document and send your

[Emu] WG adoption call for draft-arkko-eap-aka-pfs

At the IETF 103 meeting there was support in the room to adopt draft-arkko-eap-aka-pfs-03.txt as a working group item as the basis to add perfect forward secrecy to EAP-AKA. This message is to confirm that consensus. If you do not support adoption of draft-arkko-eap-aka-pfs-03.txt as WG item

[Emu] Slides for the meeting

If you are going to present at the meeting on Friday please send me your slides. Thanks, Joe ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu

<    1   2   3   4   >