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

Hi Zahed, Thanks for reviewing. Answers in-line. --Mohit On 10/7/21 3:08 PM, Zaheduzzaman Sarker via Datatracker wrote: > Zaheduzzaman Sarker has entered the following ballot position for > draft-ietf-emu-eap-tls13-20: No Objection > > When responding, please keep the subject line intact and

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

Hi Francesca, Thanks for reviewing. Answers in-line. --Mohit On 10/6/21 12:10 AM, Francesca Palombini via Datatracker wrote: > Francesca Palombini has entered the following ballot position for > draft-ietf-emu-eap-tls13-20: No Objection > > When responding, please keep the subject line intact

[Emu] Minutes from EMU @ IETF 111

Dear all, Thank you for participating in the EMU session at IETF 111. Minutes from the EMU session at IETF 111 have now been uploaded: https://datatracker.ietf.org/meeting/111/materials/minutes-111-emu-00 Please report

Re: [Emu] Éric Vyncke's No Objection on draft-ietf-emu-eap-noob-04: (with COMMENT)

Hi Éric, Thanks for the review. Answers below. --Mohit On 4/20/21 4:29 PM, Éric Vyncke via Datatracker wrote: > Éric Vyncke has entered the following ballot position for > draft-ietf-emu-eap-noob-04: No Objection > > When responding, please keep the subject line intact and reply to all > email

Re: [Emu] Francesca Palombini's Discuss on draft-ietf-emu-eap-noob-04: (with DISCUSS and COMMENT)

Hi Francesca, We have submitted a new version ( https://datatracker.ietf.org/doc/html/draft-ietf-emu-eap-noob-05 ) which hopefully addresses your comments. Here is the diff for your convenience: https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eap-noob-05.txt See our answers below. --Mohit

Re: [Emu] Erik Kline's No Objection on draft-ietf-emu-eap-noob-04: (with COMMENT)

Hi Erik, Thanks for the review. Answers below. --Mohit On 4/19/21 1:32 AM, Erik Kline via Datatracker wrote: > Erik Kline has entered the following ballot position for > draft-ietf-emu-eap-noob-04: No Objection > > When responding, please keep the subject line intact and reply to all > email

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

Hi Oleg, Joe, all, On 7/8/21 8:06 AM, Joseph Salowey wrote: On Tue, Jul 6, 2021 at 10:08 PM Joseph Salowey mailto:j...@salowey.net>> wrote: On Mon, Jun 28, 2021 at 8:11 AM Oleg Pekar mailto:oleg.pekar.2...@gmail.com>> wrote: I still see unclearness in Section "2.2. Identity Verification",

[Emu] Call for agenda items - EMU @ IETF 111

EMU @ IETF 111 will be on Thursday, July 29, 2021, from 23:30  to 00:30 (+1) 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 time needed. We have already

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

Hi Alan, Response in-line. On 6/11/21 4:38 PM, Alan DeKok wrote: >Some comments have been addressed, others not. The majority of the issues > raised in my review have been silently ignored. Some issues are nits, some > affect interoperability and security. > >Until these issues are

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

/11/21 5:17 PM, Alan DeKok wrote: On Jun 11, 2021, at 9:56 AM, Mohit Sethi M <mailto:mohit.m.se...@ericsson.com> wrote: I guess you know that there are several implementations of the draft some of which are already deployed. While that's a nice comment telling me what I alread

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

021, at 9:08 AM, Mohit Sethi M > wrote: >> Hi Chair/AD/EMU: >> >> We have submitted a new version of draft-ietf-emu-eap-tls13 based on the >> extensive feedback from Alan Dekok, Heikki Vatiainen, and Oleg Pekar. >> >> Can we somehow prioritize this document

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

Hi Chair/AD/EMU: We have submitted a new version of draft-ietf-emu-eap-tls13 based on the extensive feedback from Alan Dekok, Heikki Vatiainen, and Oleg Pekar. Can we somehow prioritize this document and move it forward? The authors have received several offline emails inquiring about the

[Emu] Agenda items for EMU @ IETF 111

Dear all, We have a requested a 1 hour session for EMU @ IETF 111. 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. Even if you don't have all the

Re: [Emu] Resolving EAP-TLS issues

Updates on the actions thus far: On 3/29/21 12:20 AM, Joseph Salowey wrote: 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

Re: [Emu] Call with 3GPP on draft-ietf-emu-rfc5448bis

the editorial comments are addressed). 3GPP has several different options for updating their own specifications and those discussions will continue in SA3. --Mohit On 3/16/21 9:57 PM, Mohit Sethi M wrote: Reminder: Jari mentioned during the EMU session @ IETF 110 about a conference call between

[Emu] Minutes from EMU @ IETF 110

Dear all, Thank you for participating in the EMU session at IETF 110. And a big thank you to Watson Ladd for detailed meeting minutes. Minutes from the EMU session at IETF 110 have now been uploaded: https://datatracker.ietf.org/meeting/110/materials/minutes-110-emu-00 Please report any issues

[Emu] A big thank you to Watson Ladd

I'd like to give a big shout-out to Watson Ladd who took incredibly detailed meeting minutes: https://codimd.ietf.org/notes-ietf-110-emu Juggling between the chat, mic queue, and note taking; he has set an extremely high bar for others like me to follow. --Mohit

Re: [Emu] EAP-TLS key derivation resolution

FYI: the latest update of wolfSSL (February 16, 2021) now claims to implement RFC 5705: Keying Material Exporters for TLS. See: https://github.com/wolfSSL/wolfssl/blob/ef916df1b1f9f9678fe7787e3b864a4b015fe569/README.md#wolfssl-release-470-february-16-2021 The TLS 1.3 exporter here:

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

Bernard: RFC 4137 says: altAccept (boolean) Alternate indication of success, as described in [RFC3748]. altReject (boolean) Alternate indication of failure, as described in [RFC3748]. Is it

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

Hi all, I have now read both the papers. I am not sure the attacks in [2] are anymore possible: - The first attack described in section 4.1.1 shows that an EAP-Success leads to an unconditional transition to the Authenticated state irrespective of the current state. However, I am not sure

Re: [Emu] General EAP discussion of protected alternate indication of success, RFC 4137, and IEEE 802.1X

Hi all, I am catching up on all the discussion of protected indication of success. I think it is important to note that protected indication of success can be exchanged in both directions (i.e. peer to server and server to peer). For example, RFC 3748 says: For example, within EAP-TLS

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

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 because it has good context for making some broader points that I would

Re: [Emu] Alissa Cooper's No Objection on draft-ietf-emu-eap-tls13-13: (with COMMENT)

Hi Alissa, Thanks for your review. I think this commit should address your comments: https://github.com/emu-wg/draft-ietf-emu-eap-tls13/commit/69dab07b0b1c4dbb303e757c7e06ec6f4775e960 I have also explained the changes made in-line. --Mohit On 1/6/21 8:15 PM, Alissa Cooper via Datatracker

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

Hi Ben, On 1/7/21 9:21 AM, Benjamin Kaduk wrote: > On Tue, Jan 05, 2021 at 10:41:50AM -0500, Alan DeKok wrote: >> On Jan 5, 2021, at 4:47 AM, Mohit Sethi M wrote: >>> What I am gathering is that this commitment message should instead be >>> made into a confirmation m

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

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 into MSK (64) and EMSK (64). As said, from initial glance, it

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

Hi Joe, On 1/5/21 8:44 AM, Joseph Salowey wrote: On Mon, Jan 4, 2021 at 6:08 AM Alan DeKok mailto:al...@deployingradius.com>> wrote: On Jan 3, 2021, at 10:44 PM, Martin Thomson mailto:m...@lowentropy.net>> wrote: > # Key Schedule > > The other thing I observe is the way that this slices up

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

Hi again, The following issues are related but not exactly the same: 1. indication from the server that the handshake is complete and it is okay to tear down the tunnel 2. indication from the server that no more post-handshake messages (containing NewSessionTicket or something else) will be

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

Top posting to explain the need for a reliable notification of protocol completion: On 1/4/21 5:44 AM, Martin Thomson wrote: I have a much simpler one: the EAP layer has a signal that the protocol is complete: EAP-Success Alan Dekok explained in a separate email thread why this is not the

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

Hi Ben, Thanks for the usual detailed feedback. I haven't yet addressed all the comments in your COMMENT section. Below, I copy the comments which have now been addressed in github: https://github.com/emu-wg/draft-ietf-emu-eap-tls13/commit/901a28578c65b8b483eecf6394cfc218b3d02f2b > Using

Re: [Emu] Erik Kline's No Objection on draft-ietf-emu-eap-tls13-13: (with COMMENT)

Hi Erik, Thanks. These are now fixed in github: https://github.com/emu-wg/draft-ietf-emu-eap-tls13/commit/094aacf6826e1edaa4dc102acd683011311aa548 --Mohit PS: Happy New Year 2021 to colleagues in EMU and IESG! On 12/31/20 8:11 AM, Erik Kline via Datatracker wrote: > Erik Kline has entered the

Re: [Emu] Éric Vyncke's No Objection on draft-ietf-emu-eap-tls13-13: (with COMMENT)

Hi Éric, Thank you for your review. Answers in-line: On 12/10/20 4:13 PM, Éric Vyncke via Datatracker wrote: > Éric Vyncke has entered the following ballot position for > draft-ietf-emu-eap-tls13-13: No Objection > > When responding, please keep the subject line intact and reply to all > email

Re: [Emu] [Ace] Proposed charter for ACE (EAP over CoAP?)

Hi ACE, I guess EMU is happy to see new deployments and uses of EAP. I think ACE is better suited for taking on this work if there is interest. EMU primarily deals with the base EAP protocol and various EAP authentication methods. We can obviously help with reviewing the document later on. I

[Emu] Minutes from EMU @ IETF109

Dear all, Thank you for participating in the EMU session at IETF 109. A special thank you to our AD Roman and others for taking notes. Minutes from the EMU session at IETF 109 have now been uploaded: https://datatracker.ietf.org/meeting/109/materials/minutes-109-emu-00.md Please report any

Re: [Emu] I-D Action: draft-ietf-emu-eaptlscert-07.txt

Hi John, On 11/20/20 7:33 AM, John Mattsson wrote: > Looking at the references in the document: > > "Suppressing Intermediate Certificates in TLS" has not been updated since > March 2019. It looks like the TLS working group is not working on this > extension. We should maybe ask Martin, if he

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

---Original Message----- > From: Emu On Behalf Of Mohit Sethi M > Sent: Monday, November 9, 2020 2:08 PM > To: emu@ietf.org > Subject: Re: [Emu] I-D Action: draft-ietf-emu-eap-tls13-12.txt > > Dear all, > > We had submitted a new version before the deadline. This version sho

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

Dear all, We had submitted a new version before the deadline. This version should address most of the comments received during the last call. Here is the diff for your convenience: https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eap-tls13-12. In particular: - we have removed some of text in

Re: [Emu] Benjamin Kaduk's Yes on draft-ietf-emu-eaptlscert-06: (with COMMENT)

Hi Ben, This should hopefully address your feedback: https://github.com/emu-wg/eaptls-longcert/commit/d39c1411c908844cc74bc0a6fa689a73ecd5b7a8 Answers in-line. --Mohit On 11/4/20 9:04 AM, Benjamin Kaduk via Datatracker wrote: > Benjamin Kaduk has entered the following ballot position for >

Re: [Emu] Agenda Items for virtual IETF 109

I think our slot is scheduled for 05:00 - 07:00 UTC. The times shown on the agenda: https://datatracker.ietf.org/meeting/109/agenda are in UTC + 7. --Mohit 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

Re: [Emu] draft-ietf-emu-eap-tls13-11: Updates RFC 5216

p and by the authors. My guess is that most implementers use the latest version of TLS 1.2 code already anyway, which comes with sensible defaults. Do you have a different experience? Ciao Hannes From: Mohit Sethi M <mailto:mohit.m.se...@ericsson.com> Sent: Monday, November 2, 2020 9:5

Re: [Emu] Making Security Practical ... was RE: Moving towards less security in 2020 - OCSP

Hi Hannes, On 11/2/20 11:42 AM, Hannes Tschofenig wrote: Hi Mohit, > Et voilà, we seem to be moving towards a consensus! That’s indeed exciting. > PS: I would certainly like to help with getting OCSP in mbed TLS. I guess its > high time. Looking forward to it. I would then add the other

Re: [Emu] draft-ietf-emu-eap-tls13-11: Conformance with the TLS 13 Spec

spec. See https://github.com/hannestschofenig/draft-ietf-emu-eap-tls13/pull/1 Ciao Hannes From: Mohit Sethi M <mailto:mohit.m.se...@ericsson.com> Sent: Monday, November 2, 2020 9:58 AM To: Hannes Tschofenig <mailto:hannes.tschofe...@arm.com>; Mohit Sethi M <mailto:mohit.m.se.

Re: [Emu] draft-ietf-emu-eap-tls13-11: Updates RFC 5216

those because they are hidden in the document. 3. You are referencing the wrong documents. If you look at this case as a working group chair then you might see the points I am trying to get across. Ciao Hannes From: Mohit Sethi M <mailto:mohit.m.se...@ericsson.com> Sent: Saturday, October 31

Re: [Emu] draft-ietf-emu-eap-tls13-11: Conformance with the TLS 13 Spec

this case, the “SHOULD” statement gives an implementer absolutely not idea when or when it would be good to implement this feature. Besides this, I don’t even believe that the TLS 1.3 spec gives you that freedom for this specific feature anyway. Ciao Hannes From: Mohit Sethi M <mailto

Re: [Emu] Making Security Practical ... was RE: Moving towards less security in 2020 - OCSP

. “ This sounds like a good compromise for me. Ciao Hannes PS: Mohit, maybe you can help implement OCSP to EAP-TLS in Mbed TLS. I am looking forward to see OCSP supported added to EDHOC by John. From: Emu <mailto:emu-boun...@ietf.org> On Behalf Of Mohit Sethi M Sent: Saturday, October 31, 202

Re: [Emu] Moving towards less security in 2020 - OCSP

icateEntry (except the trust anchor) without a valid CertificateStatus extension as invalid and abort the handshake with an appropriate alert. --Mohit On 11/1/20 6:48 PM, Michael Richardson wrote: Mohit Sethi M <mailto:mohit.m.sethi=40ericsson@dmarc.ietf.org> wrote: > So we

Re: [Emu] draft-ietf-emu-eap-tls13-11: Updates RFC 5216

Hi Hannes, This text and guidance was specifically requested by working group members like Alan. Unless the text is wrong, I don't see any point in removing it. Other TLS-based EAP methods are obviously free to use parts of this text relevant to them. Note that their resumption and

Re: [Emu] draft-ietf-emu-eap-tls13-11: Conformance with the TLS 13 Spec

Hi Hannes, Jim Schaad had asked for this: https://mailarchive.ietf.org/arch/msg/emu/XpRkNN-mh5BuiTD1O8iEfz9sM4M/ It is still optional to use. The figure only shows what the exchange would look like if a HRR was sent by the server. --Mohit On 10/21/20 12:16 PM, Hannes Tschofenig wrote: Hi

Re: [Emu] Secdir last call review of draft-ietf-emu-eaptlscert-06

using locally stored data. If used in a local corporate context, a cache mechanism could be provided with pre-loaded relevant certs. But I don’t know how this may or may not interoperate with deployed base of EAP implementations. Stefan Santesson On 2020-10-30, 14:48, "Mohit Se

[Emu] Moving towards less security in 2020 - OCSP

Dear all, Sorry for the radio silence. I have over-committed myself to too many things. I think I have now read the entire discussion on OCSP. EAP-TLS with TLS 1.3 is a working group document so the text will reflect whatever the working group wants. The authors and contributors are at the

Re: [Emu] Secdir last call review of draft-ietf-emu-eaptlscert-06

Hi Stefan, Thank you for the review. I have updated the draft in github (https://github.com/emu-wg/eaptls-longcert). Here is the diff for your convenience:

Re: [Emu] Barry Leiba's No Objection on draft-ietf-emu-eaptlscert-06: (with COMMENT)

Hi Barry, Thank you for the careful review. I have updated the draft in github (https://github.com/emu-wg/eaptls-longcert). Here is the diff for your convenience:

Re: [Emu] Genart last call review of draft-ietf-emu-eaptlscert-05

Hi Elwyn, Thank you for the careful review. We have updated the draft based on your feedback. Here is the diff for you convenience: https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eaptlscert-06. See our responses in-line. --Mohit On 10/24/20 1:44 PM, Elwyn Davies via Datatracker wrote: >

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

Dear all, This version includes additional clarifications on resumption suggested by Terry Burton. Based on the mailing list discussion, we still use 1-byte of encrypted application data as the commitment message: https://mailarchive.ietf.org/arch/msg/emu/6f36UTSysJ_xzGdkOtC4TDNTZbI/. --Mohit

Re: [Emu] Appropriate AAA/EAP response to a peer's NAK when there are no overlapping methods

Hi again, On 8/23/20 7:12 PM, Alan DeKok wrote: > On Aug 23, 2020, at 9:48 AM, Mohit Sethi M wrote: >> Sorry, but you are missing context here. The discussion was no longer >> about sending an EAP failure when no suitable EAP methods are available. >> Terry and I were dis

Re: [Emu] Appropriate AAA/EAP response to a peer's NAK when there are no overlapping methods

Hi Alan, On 8/21/20 3:50 PM, Alan DeKok wrote: > On Aug 21, 2020, at 3:27 AM, Mohit Sethi M > wrote: >> Sorry for nitpicking here. But it is important to distinguish the two >> components that comprise a AAA server: RADIUS server and EAP server. RFC >> 3579 briefly al

Re: [Emu] Appropriate AAA/EAP response to a peer's NAK when there are no overlapping methods

Hi Terry, On 8/20/20 5:41 PM, Terry Burton wrote: > On Thu, 20 Aug 2020 at 14:54, Mohit Sethi M > wrote: >> It would be a misinterpretation to say that everything from the >> authenticator is an EAP-Request hence EAP-Failure is also a Request. >> It's an EAP packet wit

Re: [Emu] Appropriate AAA/EAP response to a peer's NAK when there are no overlapping methods

erver. Sending a NAK in the other direction would be a violation of RFC 3748 and is not supported or implemented. --Mohit On 8/20/20 4:26 PM, Terry Burton wrote: > On Thu, 20 Aug 2020 at 13:34, Mohit Sethi M > wrote: > <...snip...> >> It's also contrary to... >> >>

Re: [Emu] Appropriate AAA/EAP response to a peer's NAK when there are no overlapping methods

Hi Terry, On 8/20/20 3:02 PM, Terry Burton wrote: On Thu, 20 Aug 2020 at 10:00, Mohit Sethi M <mailto:mohit.m.sethi=40ericsson@dmarc.ietf.org> wrote: I surely must be missing something here: Packet 6 is an EAP-Response from the peer. Packet 7 contains another EAP-Response

Re: [Emu] Appropriate AAA/EAP response to a peer's NAK when there are no overlapping methods

Hi Terry, I surely must be missing something here: Packet 6 is an EAP-Response from the peer. Packet 7 contains another EAP-Response inside a RADIUS Access-Request? That doesn't make sense. EAP is lock-step request-response protocol. The conversation you describe is incorrect. My reading of

Re: [Emu] draft-ietf-emu-eap-tls13: Client re-validation of server authority information during resumption

AM, Terry Burton wrote: >> On Tue, 11 Aug 2020 at 09:11, Mohit Sethi M >> wrote: >>> Section 5.7 "Resumption" says: >>> >>>> When resumption occurs, it is based on cached information at the TLS >>>>layer. To perform resumptio

Re: [Emu] draft-ietf-emu-eap-tls13: Client re-validation of server authority information during resumption

Hi Terry, Section 5.7  "Resumption" says: > When resumption occurs, it is based on cached information at the TLS >    layer.  To perform resumption in a secure way, the EAP-TLS peer and >    EAP-TLS server need to be able to securely retrieve authorization >    information such as certificate

Re: [Emu] Commitment Message handling in EAP-TLS 1.3

I seem to agree with the consensus around the usage of close_notify instead of a byte of 0x00. In fact, I can't even remember the reason for that choice anymore. The draft is now updated in github to specify the usage of close_notify: https://github.com/emu-wg/draft-ietf-emu-eap-tls13 Here is

[Emu] Commitment Message handling in EAP-TLS 1.3

Dear all, Thanks all for the discussion on the commitment message. draft-ietf-emu-eap-tls13-10 (https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-10) in figure 2 shows the ticket establishment and commitment message: EAP Peer EAP Server

[Emu] Minutes from EMU @ IETF108

Dear all, Thank you for participating in the EMU session at IETF 108. A special thank you to Aleksi Peltonen for serving as the note taker. Minutes from the EMU session at IETF 108 have now been uploaded: https://datatracker.ietf.org/doc/minutes-108-emu/ Please report any issues by August 10,

[Emu] Preparations for Friday

Dear all, Instead of the usual 120 minutes, we have a 50 minute session for EMU @ IETF 108 on Friday, July 31st. Here is our current agenda for the meeting: https://datatracker.ietf.org/doc/agenda-108-emu/ As you notice, the agenda is rather packed. There is no possibility to extend the

[Emu] Finishing draft-ietf-emu-eap-tls13 - Commitment Message handling

Dear all, draft-ietf-emu-eap-tls13 is currently in the state "AD Evaluation::AD Followup". Our AD (Roman) had done an excellent review (https://mailarchive.ietf.org/arch/msg/emu/k6K98OhuOQmbzSAgGWCtSIVv3Qk/), which I addressed in version 10

Re: [Emu] [Iot-directorate] Iotdir early review of draft-ietf-emu-eap-noob-01

Thanks Carsten. This is very valuable input for the working group before it makes a critical decision. --Mohit On 7/11/20 4:40 PM, Carsten Bormann wrote: > Hi Mohit, > > >> On 2020-07-11, at 15:27, Mohit Sethi M >> wrote: >> >> Hi Michael, >> >> T

Re: [Emu] [Iot-directorate] Iotdir early review of draft-ietf-emu-eap-noob-01

Hi Michael, Thanks for the input. This is indeed something we should discuss at the upcoming virtual EMU meeting. Some colleagues (Ingles Sanchez et al.) have also investigated and documented the savings that might result from the use of CBOR in EAP-NOOB:

Re: [Emu] I-D Action: draft-ietf-emu-aka-pfs-04.txt

Arghh. I feel very protected with unreadable URLs of fireeye. Fixed pointer to the reference: https://www.secg.org/SEC2-Ver-1.0.pdf The relevant section is 2.7.1. --Mohit On 7/9/20 9:45 AM, Mohit Sethi M wrote: Rene, Russ, and I had an offline email exchange about this issue. I think we

Re: [Emu] I-D Action: draft-ietf-emu-aka-pfs-04.txt

lusion is that the current draft is correct: * For P-256, the length of this value is 32 bytes, encoded in binary as specified in [FIPS186-4]. Russ On Jun 24, 2020, at 1:10 AM, Mohit Sethi M <mailto:mohit.m.sethi=40ericsson@dmarc.ietf.org> wrote: Hi all, I am

[Emu] Agenda Items for IETF 108

Dear all, At the virtual IETF 108 meeting, we will have a 50 minute session on Friday, July 31, between 13:00 - 13:50 UTC. Please send Joe and I (emu-cha...@ietf.org) requests for presentation slots. Don't forget to include the title of your presentation, related drafts, and the approximate

Re: [Emu] draft-ietf-emu-eap-noob-01 incorrect curve name in example messages

Hi Max, Good catch. This will be fixed in the next version! --Mohit On 7/3/20 12:21 PM, Max Crone wrote: > Hi, > > I noticed that the examples messages in Appendix F > (https://tools.ietf.org/html/draft-ietf-emu-eap-noob-01#appendix-F) > use the curve name "Curve25519" in the JWK object.

Re: [Emu] Secdir early review of draft-ietf-emu-eap-noob-01

Hi Steve, I have answered each question in-line. On 6/29/20 2:54 AM, Steve Hanna via Datatracker wrote: > Reviewer: Steve Hanna > Review result: Not Ready > > Reviewer: Steve Hanna > Review result: Not Ready > > I have reviewed this document as part of the security directorate's ongoing > effort

Re: [Emu] I-D Action: draft-ietf-emu-aka-pfs-04.txt

Hi all, I am not a crypto expert and my knowledge of public key encodings is based on my work with Rene Struik for a different draft. The current text in draft-ietf-emu-aka-pfs-04 says "For P-256, the length of this value is 32 bytes, encoded in binary". Shouldn't this be 33 bytes? And

Re: [Emu] Commitment Message in draft-ietf-emu-eap-tls13

to an unauthenticated peer in this case is fine. I wonder how others feel about this change. --Mohit On 6/16/20 1:43 PM, Hannes Tschofenig wrote: Hi Mohit, See below. Thanks for your super quick response. *From:* Mohit Sethi M *Sent:* Tuesday, June 16, 2020 12:25 PM *To:* Hannes

Re: [Emu] Commitment Message in draft-ietf-emu-eap-tls13

are to be expected. --Mohit The current solution in the draft, for example, does not work with Mbed TLS because you cannot tell the stack to suddenly bypass the encryption layer (after successfully establishing it) to send a plaintext message. Ciao Hannes *From:* Mohit Sethi M *Sent

Re: [Emu] Commitment Message in draft-ietf-emu-eap-tls13

Hi Hannes, Unfortunately you are wrong here. The design decision was in fact taken to avoid changes to the underlying TLS implementation while also avoiding changes to RFC 3748. To summarize: Jouni Malinen pointed out that mapping session resumption of TLS 1.3 to EAP-TLS is non-trivial. See

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

Hi Hannes, On 6/12/20 11:29 AM, Hannes Tschofenig wrote: A short follow-up on my own review: I wrote: " Pre-Shared Key (PSK) authentication SHALL NOT be used except for resumption. " What you want to say that that EAP-TLS MUST NOT use external PSKs. I wonder why you want to rule that use

Re: [Emu] draft-ietf-emu-eaptlscert-04

Hi Hannes, Thanks for the follow up. I have submitted a new version which should address your concerns. Here is a diff for your convenience: https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eaptlscert-05 Please see in-line for details. I believe that the draft is now ready for publication.

Re: [Emu] My review ... was RE: I-D Action: draft-ietf-emu-eaptlscert-02.txt

d these since they are still in early phases of development. However, I have now added a section titled "New Certificate Types and Compression Algorithms". Hope this is sufficient. > > Ciao > Hannes > > -Original Message- > From: Mohit Sethi M > Sent: Saturday,

Re: [Emu] AD review of draft-ietf-emu-eap-tls13-09

Hi Roman, Thanks for your usual careful review. I have submitted a new version that hopefully addresses all the issues. Here is the diff for your convenience: https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eap-tls13-10 Please see in-line for details on how we have handled each issue.

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

I would add that there is also an early implementation of EAP-TLS-PSK: https://github.com/rohitshubham/EAP-TLS-PSK We had agreed that external PSK authentication for EAP-TLS will use a new method type number. The draft for EAP-TLS-PSK

[Emu] Minutes and bluesheets from EMU virtual interim

Dear all, Thank you for participating in the EMU virtual interim on Friday. A special thank you to Max Crone for volunteering as the minute taker. Meeting minutes and bluesheets from the virtual interim have now been uploaded. Minutes:

[Emu] Request for presentations during virtual interim

and Mohit JOIN WEBEX MEETING https://ietf.webex.com/ietf/j.php?MTID=mc9df4dccd3859204bde061bde4848491 Meeting number (access code): 618 538 077 Meeting password: Sx2edf4mWU3 On 5/5/20 11:38 AM, Mohit Sethi M wrote: > The poll is now closed. We will have a 90-minute virtual interim meeting > f

Re: [Emu] My review ... was RE: I-D Action: draft-ietf-emu-eaptlscert-02.txt

Hi Hannes, I have submitted a new version of the draft which I believe addresses your concerns. Here is a diff for your convenience: https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eaptlscert-03 While Alan and Jouni have already provided excellent answers to most of your comments, in-line

[Emu] Fwd: Reminder: Survey on planning for possible online IETF meetings

You have a chance to influence how the upcoming IETF meetings for this year are organized. Please answer the survey if you haven't already. See the details below. Here is the link for your convenience: https://www.surveymonkey.com/r/5328FFJ --Mohit Begin forwarded message: From: IETF

Re: [Emu] Poll for virtual interim

Sethi M wrote: > Dear all, > > Reminder: please respond to the poll for a potential virtual interim in > May: https://doodle.com/poll/vxy5vc4g3cnegpdr > > Joe and Mohit > > On 4/20/20 2:11 AM, Mohit Sethi M wrote: >> Dear all, >> >> We did not have a face

Re: [Emu] draft-aura-eap-noob-08 NAI

Hi Eliot, On 4/24/20 4:22 PM, Eliot Lear wrote: Hi Mohit On 24 Apr 2020, at 15:02, Mohit Sethi M <mailto:mohit.m.sethi=40ericsson@dmarc.ietf.org> wrote: Hi Max, Tuomas can give you a definite answer. My understanding is that error 1001 should be sent by the server if the re

Re: [Emu] draft-aura-eap-noob-08 NAI

Hi Max, Tuomas can give you a definite answer. My understanding is that error 1001 should be sent by the server if the received identity does not follow the requirements of draft-aura-eap-noob. Besides, implementing the stricter checks of this draft is easier than validating the ABNF of

Re: [Emu] Poll for virtual interim

Dear all, Reminder: please respond to the poll for a potential virtual interim in May: https://doodle.com/poll/vxy5vc4g3cnegpdr Joe and Mohit On 4/20/20 2:11 AM, Mohit Sethi M wrote: > Dear all, > > We did not have a face-to-face meeting in Vancouver for IETF 107. At > this point,

[Emu] Poll for virtual interim

Dear all, We did not have a face-to-face meeting in Vancouver for IETF 107. At this point, the IETF 108 meeting in Madrid is also uncertain. We are therefore considering a virtual interim meeting for EMU during middle/end of May 2020. Here are some proposed dates and time slots:

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

Hi Alan, On 4/19/20 7:18 PM, Alan DeKok wrote: > >> On Apr 18, 2020, at 4:13 PM, Joseph Salowey wrote: >> >> 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

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

No hat! I support the adoption of this document! --Mohit On 4/3/20 11:48 PM, Alan DeKok wrote: > https://tools.ietf.org/html/draft-dekok-emu-tls-eap-types-01 > >I haven't seen much discussion on the document. There are still some open > questions: > > * should it be published

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

Thank you Russ. We have updated the text as suggested: https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eaptlscert-02 --Mohit On 3/9/20 11:09 PM, Russ Housley wrote: I read the document, and I think it is read to go after one editorial fix. The term "trust anchor" is used many times in the

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

Hi Russ, You can listen here: https://youtu.be/YJLG4JUftqI?t=1144 We plan to support it in EAP-TLS-PSK instead: https://tools.ietf.org/html/draft-mattsson-emu-eap-tls-psk-00. We have already added a reference to draft-ietf-tls-tls13-cert-with-extern-psk and plan to use it. I think using an

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

Hi Alan, Thanks for your careful and detailed reviews. They are extremely helpful. We have submitted a new version addressing your feedback. Please see in-line for specific actions taken. Here you can see the diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eaptlscert-01. --Mohit On

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

On 1/16/20 6:07 AM, Benjamin Kaduk wrote: > Is there anything better for implementations to actually do (as distinct > from what we write down as recommendations) than to start setting up a > parallel (purpose-specific) PKI now and trusting that in parallel with what > they're currently doing,

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

Hi Alan, On 12/28/19 3:29 PM, Alan DeKok wrote: > On Dec 27, 2019, at 1:54 PM, internet-dra...@ietf.org wrote: >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eap-tls13-08 >Which adds some text about identities: > > It is

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

Hi Alan, On 12/28/19 3:29 PM, Alan DeKok wrote: > On Dec 27, 2019, at 1:54 PM,internet-dra...@ietf.org wrote: >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eap-tls13-08 >Which adds some text about identities: > > It is

[Emu] Minutes from EMU @ IETF106

Hi all, Thank you for participating in the EMU session at IETF 106. A special thank you to Eliot for volunteering as the minute taker. Meeting minutes from the EMU session at IETF 106 have now been uploaded: https://datatracker.ietf.org/meeting/106/materials/minutes-106-emu-00 Please report

  1   2   >