I just sent an email explaining the updates.
You are lightening fast with your reviews and feedback. :)
--Mohit
On 3/5/20 5:04 PM, Alan DeKok wrote:
On Mar 5, 2020, at 9:56 AM, internet-dra...@ietf.org wrote:
A New Internet-Draft is available from the on-line Internet-Drafts directories
Hi Hannes,
Thanks. I have opened several issues on github based on your review:
https://github.com/emu-wg/draft-ietf-emu-eap-tls13/issues
--Mohit
On 10/21/20 11:55 AM, Hannes Tschofenig wrote:
Hi all,
Roman asked me to look at draft-ietf-emu-eap-tls13-11.
I have carefully read through
on Monday. We hope to ship this soon.
--Mohit
On 10/8/21 2:17 AM, Benjamin Kaduk via Datatracker 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 intact and reply to all
email addresses
decided to write a generic EAP method for
out-of-band authentication.
The draft is available here:
https://tools.ietf.org/html/draft-aura-eap-noob-00
Please see if you can make use of it. We look forward to your feedback
and comments.
Regards
/--Mohit
Forwarded Message
on and the
added security, the deployment of such NAS would increase in general.
/--Mohit
PS: Let's keep the future discussion for this draft on the SAAG mailing
list for now.
On 02/19/2016 09:31 AM, Stefan Winter wrote:
Hi,
Of course, the benefits of EAP-NOOB will be greater in orga
hack
together or just to have a look at the demo.
Thanks
/--Mohit
Forwarded Message
Subject:New Version Notification for draft-aura-eap-noob-01.txt
Date: Mon, 04 Jul 2016 01:01:38 -0700
From: internet-dra...@ietf.org
To: Tuomas Aura , Mohit Sethi
A new
mailing list.
--Mohit
Forwarded Message
Subject:New Version Notification for draft-aura-eap-noob-02.txt
Date: Thu, 25 May 2017 12:52:46 -0700
From: internet-dra...@ietf.org
To: Tuomas Aura , Mohit Sethi
A new version of I-D, draft-aura-eap-noob-02.txt
has
and other can refer to.
John and Mohit
On 10/30/2017 10:37 AM, Bernard Aboba wrote:
RFC 5216 only insists on support (not use) of TLS 1.0 and its
mandatory ciphersuites in order to ensure interoperability with legacy
implementations and avoid an Internet-wide “flag day” requiring
millions o
ink the session identifier for fast
re-authentication in EAP-AKA' would be part of the rfc5448bis document.
A separate document would only be needed for EAP-SIM and EAP-AKA session
identifiers.
--Mohit
On 02/02/2018 07:02 PM, Kathleen Moriarty wrote:
Kathleen Moriarty has entered
large with long certificate chains)? And is the problem
only the number of EAP messages/packets, or also the duration of a
single authentication run (i.e. AP implementations drop EAP session if
not completed within x seconds/minutes)?
--Mohit
On 12/21/2017 04:01 PM, Alan DeKok wrote:
On Dec 21
to your contributions. The project description is also
available in the hackathon wiki:
https://trac.ietf.org/trac/ietf/meeting/wiki/101hackathon
<https://trac.ietf.org/trac/ietf/meeting/wiki/101hackathon>
--Mohit
___
Emu mailing list
Emu@ie
in deployments often? Are we missing something? Do
you have some numbers on the size of the certificate chain and the EAP
fragment_size from your deployment experience?
--Mohit
On 02/05/2018 12:41 PM, Alan DeKok wrote:
On Feb 5, 2018, at 4:03 AM, Mohit Sethi wrote:
Thanks for raising this
Dear all,
As a co-author, I do think that this work is needed and I would support
the adoption of this draft.
Thanks to everyone who has already provided comments and feedback on the
draft.
--Mohit
On 03/28/2018 07:51 PM, Joseph Salowey wrote:
At the IETF 101 EMU meeting in London there
I will review it as well.
--Mohit
On 05/28/2018 11:59 PM, Alan DeKok wrote:
I will review it.
On May 28, 2018, at 4:58 PM, Joseph Salowey wrote:
I didn't see any objections, but I want to make sure we have some folks willing
to review the draft. Please respond to this thread i
-or-off the list in the coming months.
--Mohit
On 07/20/2018 09:43 AM, Eric Rescorla wrote:
I am pleased to announce that Mohit Sethi has agreed to serve as
co-chair for EMU.
Thanks to Mohit!
-Ekr
___
Emu mailing list
Emu@ietf.org
https
I
am eager to work with the group in the coming months.
--Mohit
On 07/20/2018 05:33 PM, Dr. Pala wrote:
Congratulations Mohit!
Now you can do more work for free :D
Cheers,
Max
On 7/20/18 9:43 AM, Eric Rescorla wrote:
I am pleased to announce that Mohit Sethi has agreed to serve as
co-chair
l be EAP-AKA'. "
- In Section 2: " This specification is an initial proposal for ensuring
SIM-based authentication in EAP makes attacks difficult. Comments and
suggestions are much appreciated, including design improvements. "
perhaps can be removed now?
--Mohit
/minutes-102-emu-00
Please report any issues by August 10, 2018.
Joe and Mohit
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
on how not to shoot yourself in the foot
with PKI (pick shorter OIDs if possible etc.).
This is an experiment so we look forward to your feedback (and pull
requests).
Joe and Mohit
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman
("EXPORTER_EAP_TLS_Method-Id", "", 64)
Session-Id = 0x0D || Method-Id
where 0x0D is the type code. IANA had allocated type code 13 for EAP-TLS.
Please let us know if we still missed something.
--Mohit
___
Emu mailing lis
issues by April 8, 2022.
Joe and Mohit
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
Dear all,
The minutes have been updated based on a clean up by Jan-Frederik:
https://datatracker.ietf.org/meeting/113/materials/minutes-113-emu-01.
Thank you once again for your diligence.
The deadline for reporting any issues is still April 8, 2022.
Joe and Mohit
On 3/23/22 21:45, Mohit
cess and Failure messages are sent by the EAP server?
4. Section 4 says:
If either peer or server instead
initiates an inner tunnel method
I thought you have mandated the use of an inner tunnel method? So why
the 'if'?
--Mohit
On 6/8/22 19:16, Joseph Salowey wrote:
This is the wo
Hi:
On 7/4/22 22:28, Alan DeKok wrote:
On Jul 4, 2022, at 2:56 PM, Mohit Sethi wrote:
Some late last call comments:
1. For PEAP and TTLS, it is no longer possible to use client certificates
without phase 2 authentication. Does the same restriction apply to TEAP. I
think it would make
author and help drive
this document to the RFC editor queue.
Also, at some later point, if volunteers are needed for the IANA expert
registry or something else, I'd be available.
--Mohit
PS: There was also an issue that the current draft recommends Expert
Review for assignment of new
, the recursive resolvers provided by
that domain will be able to answer queries for subdomains of 'home.arpa.'"
We are taking a more conservative approach where subdomains need expert
review and registration before they are allocated and can be used in
deployments.
--Mohit
On
productive
week in Brisbane. Safe travels!
--Mohit
On 3/22/24 11:24, Michael Richardson wrote:
Mohit Sethi wrote:
> As far as I can tell, we will not be the first ones using such a
> scheme. ".home.arpa." defined in RFC 8375
> (https://www.rfc-editor.org/rfc/rfc
t;0..2^24-1>;
} Certificate;
--Mohit
On 9/4/24 18:24, RFC Errata System wrote:
The following errata report has been submitted for RFC9190,
"EAP-TLS 1.3: Using the Extensible Authentication Protocol with TLS 1.3".
--
You may revie
d the approximate amount of time that you need.
Please also let us know if you plan to present remotely.
Joe and Mohit
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
November 21, 2018.
Joe and Mohit
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
Hi Russ,
Thanks for reporting this. I have now fixed the nit and updated the
missing sentence after checking the audio recording. The updated meeting
minutes are here:
https://datatracker.ietf.org/meeting/103/materials/minutes-103-emu-01
--Mohit
On 11/14/18 10:02 AM, Russ Housley wrote
+1 on making OCSP stapling mandatory.
--Mohit
On 11/14/18 4:04 PM, John Mattsson wrote:
> Hi all,
>
> I think the draft is now in quite good shape. It would be good to get some
> reviews. One thing that I would like to discuss is what the draft should say
> about various extension
privacy. What NAI would
such peers use if they rely solely on TLS based resumption?
As a co-author of draft-ietf-emu-eap-tls13, I don't think we should
support such cross method resumption. If anything, this should be
discouraged/forbidden.
--Mohit
On 2/1/19 7:49 PM, Alan DeKok wrote:
>
Hi Alan,
Thanks for bringing this up. I agree that we should take this
opportunity to fix other EAP methods which rely on TLS for the outer
tunnel. I think that these updates merit a separate document. But I am
not certain why the two documents need to be published simultaneously?
--Mohit
On
Hi John, Alan, and others,
The recommendations in this document may be used by all TLS-based EAP
methods. However, fragmenting large certificates and certificate chains
into many small messages is less of a problem when only one side
(server) is authenticating with certificates.
--Mohit
On 2
Hi Alan,
On 2/5/19 3:13 PM, Alan DeKok wrote:
> On Feb 5, 2019, at 12:19 AM, Mohit Sethi M wrote:
>> Do you have experience with such cross method resumption? Are there any
>> deployments that make use of this?
>There are no deployments that make use of it. It'
lable).
--Mohit
On 2/5/19 3:16 PM, Alan DeKok wrote:
> On Feb 5, 2019, at 12:25 AM, Mohit Sethi M wrote:
>> Thanks for bringing this up. I agree that we should take this
>> opportunity to fix other EAP methods which rely on TLS for the outer
>> tunnel. I think that these updates
Hi Alan,
On 2/5/19 5:48 PM, Alan DeKok wrote:
> On Feb 5, 2019, at 10:18 AM, Mohit Sethi M wrote:
>> But session resumption is not simply about changing one byte in the EAP
>> conversation. If you look at Figure 2 of draft-ietf-emu-eap-tls13-03
>> (https://tools.ietf.org/ht
don't want EAP-TLS to lie around for that long.
Modular independent specs are better in my opinion.
--Mohit
On 2/5/19 5:46 PM, Alan DeKok wrote:
> On Feb 5, 2019, at 10:40 AM, Mohit Sethi M wrote:
>> One could use the same argument. Those only interested in implementing
>> EA
rver should not only refuse resumption if a client
was not authenticated, it should also refuse resumption if the client
was authenticated with other methods than certificates (such as passwords).
Do you agree?
--Mohit
>
>Alan DeKok.
>
> __
start by looking at existing mechanisms used by EAP-Pwd/EAP-TTLS.
--Mohit
Further thinking let me to my second question: the method we are going to
propose requires some form of authentication for the server, therefore I can
see its use mainly as a tunneled method where the communication with the s
pointing out L bit ambiguity in EAP-TLS. We should indeed fix
this.
--Mohit
On 2/14/19 3:27 PM, slon v sobstvennom palto wrote:
Hi all,
These are my first steps in this group so please correct me if I don't follow
the rules.
Per my experience the existing fragmentation method described in EAP-TL
ssels.
Don't forget to include the title of your presentation, related drafts,
and the approximate amount of time that you need.
Please also let us know if you plan to present remotely.
Joe and Mohit
___
Emu mailing list
Emu@ietf.org
https://ww
://homepage.divms.uiowa.edu/~comarhaider/publications/LTE-torpedo-NDSS19.pdf
It might make sense to mention them in the security considerations section with
text explaining how they affect AKA, and whether any updates to address them
would also require changes to EAP-AKA'?
Joe and Mohit
On 2/14/19 3:
morning before the session begins.
Joe and Mohit
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
-emu-00
Please report any issues by April 9, 2019.
Joe and Mohit
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
. The draft currently defines
Session-Id for EAP-PEAP as:
Session-Id = 0x19 || client.random || server.random).
Do you plan to update this for TLS 1.3 and use TLS-Exporter in your other
draft: draft-dekok-emu-tls-eap-types? Do we need to do this twice in separate
drafts?
--Mohit
On 5/22
do at the IETF. It would be sad to
ship documents to the IESG with limited or no review/feedback from the working
group!
--Mohit
On 6/27/19 7:16 AM, Joseph Salowey wrote:
The Working Group last call has completed with no comments for
draft-ietf-emu-eap-tls13-05. I would like to confirm that
In addition to my previous comment on this draft:
https://mailarchive.ietf.org/arch/msg/emu/eJ_xCqn7Eq2fzx6tuDS0PDdBwkI
I think that the title should be made more explicit to something along the
lines: Session-Id derivation for EAP-SIM, EAP-AKA and EAP-PEAP.
--Mohit
On 7/3/19 2:35 PM, IETF
send it to the IESG for review.
Joe and Mohit
The Extensible Authentication Protocol (EAP) [RFC 3748] is a network access
authentication framework used, for instance, in VPN and mobile networks. EAP
itself is a simple protocol and actual authentication happens in EAP
Hi Michael,
On 8/22/19 10:46 PM, Michael Richardson wrote:
Mohit Sethi M <mailto:mohit.m.se...@ericsson.com>
wrote:
> At the same time, some new use cases for EAP have been identified. EAP
> is now more broadly in mobile network authentication. The group will
> upda
Hi Rene,
Thank you for the suggestion. It makes sense. I will update the text
accordingly.
--Mohit
On 8/26/19 6:25 PM, Rene Struik wrote:
Hi Mohit:
I read the proposed recharter text and suggest a tiny change in the dashed work
item below: change "shall" to "should". W
Dear all,
Please send in your comments on the charter text by Wednesday, September 18,
2019.
Joe and Mohit
On 8/21/19 11:13 AM, Mohit Sethi M wrote:
Dear all,
Thank you for a productive meeting @ IETF 105. We had discussed the new charter
text during the working group session in Montreal
The current re-charter text is now in github for convenient issue and change
tracking:
We have incorporated the suggestions from John and Rene to the current text:
https://github.com/emu-wg/charter/blob/master/emu-charter.md
Joe and Mohit
On 9/11/19 9:50 PM, Mohit Sethi M wrote:
Dear all
/be1bf557355ecba5d5ee35ab27f3e8fae8c06eef
--Mohit
On 9/18/19 11:37 AM, Georgios Z. Papadopoulos wrote:
Dear Joe, Mohit and all,
In overall I find the text well written, while the objectives well defined.
Below I have very few comments :
* TLS is not defined.
* Perfect Forward Secrecy (PFS) is defined twice.
* - An update to
constraining TLS 1.3. But there is
clearl precedent. The original EAP-TLS specification in RFC 5216
(https://tools.ietf.org/html/rfc5216) has no mention of PSKs.
--Mohit
On 10/10/19 10:44 AM, John Mattsson wrote:
Hi Eliot,
I agree that the question boils down to IoT. There are currently a lot of
that it would make tracking of
peers/clients much harder.
There is ongoing work in the TLS working group but the question is how long
should we wait:
https://tools.ietf.org/html/draft-ietf-tls-external-psk-importer-01
--Mohit
On 10/10/19 10:51 AM, Eliot Lear wrote:
I do think this is where w
aft-ietf-emu-eap-tls13-07>
draft if that is what the general consensus is.
--Mohit
On 10/10/19 12:24 PM, Eliot Lear wrote:
Hi Mohit,
On 10 Oct 2019, at 09:55, Mohit Sethi M
mailto:mohit.m.se...@ericsson.com>> wrote:
@Elliot: I understand your discomfort with constraining TLS 1.3.
far EAP-TLS has only been used with certificates. If we are adding
support for external PSKs, we should make sure that implementations know how to
handle them.
--Mohit
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
external PSK before checking for resumption PSKs.
I think we can include EAP-TLS-PSK without major changes to the current
document. I only want to ensure that EAP-TLS-PSK does not leave any
implementation ambiguities.
--Mohit
On 10/10/19 7:18 PM, John Mattsson wrote:
> Mohit Seth
also the last chance before Singapore).
--Mohit
On 10/15/19 3:11 AM, Dr. Pala wrote:
Hi Mohit, all,
sorry for the long delay in replying (probably mute at this point), however I
think the new text looks great. The only possible change I would provide is the
possibility to restrict the scope
k, it is easy to complain about others. I strongly encourage
you to take a pause and self-introspect before accusing other people of not
replying to emails or not writing the text exactly as you want or not doing
things that make you happy.
--Mohit
On 10/24/19 3:11 AM, Dr. Pala wrote:
Hi Mohit, al
etwork operator). Both these
credentials can be used for EAP authentication (albeit with different servers)
and will result in different Session-Ids.
There's a lot of stuff set to happen in Nov 2019; is that all staged and
ready to go?
Yes!
--Mohit
__
Don't forget to include the title of your presentation, related drafts,
and the approximate amount of time that you need.
Please also let us know if you plan to present remotely.
Joe and Mohit
___
Emu mailing list
Emu@ietf.org
https://www.ietf.o
.
Thanks,
Joe and Mohit
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
any issues by December 3, 2019.
Joe and Mohit
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
e with the provisions of BCP 78 and BCP 79 have already been
filed for draft-ietf-emu-eap-session-id?
--Mohit
On 11/26/19 3:08 PM, Mohit Sethi M wrote:
> Dear all,
>
> This email initiates the working group last call (WGLC) for
> draft-ietf-emu-eap-session-id
> (https://tools.ietf.or
e as the EAP Identity.
Is there a case when the PSK identity is not derived by the underlying
TLS implementation? And perhaps you meant to say that it cannot be
controlled by the EAP peer (rather than the EAP authenticator)?
--Mohit
>I find it's easier for people to follow recommendations when
vacy-friendly identities (e.g. encrypted usernames) MAY be used."
While identities MAY be derived from the certificate, they can also be
configured by the user. As a co-author, I don't think we should
over-prescribe only one way of doing it.
--Mohit
>
>I would prefer
e currently doing, with the hope of being able to have a flag day
> many years down the line when the new PKI becomes the only thing that's
> trusted?
This seems like a reasonable way forward to me.
--Mohit
___
Emu mailing list
Emu@ietf.org
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 3
?
--Mohit
On 3/10/20 6:30 PM, Russ Housley wrote:
> I do not understand the reason for Bernard's objection. I looked at the
> minutes, and I do not find any rationale there. Can you help?
>
> Russ
>
>
>> On Mar 9, 2020, at 5:59 AM, John Mattsson wrote:
>>
>> H
(and expanded type
code) space for now. If others are interested in defining some
EAP-TLS-foo method later on, they have the liberty to do that.
--Mohit
On 3/11/20 10:01 AM, John Mattsson wrote:
> Hi,
>
> Russ Housley wrote:
> >> I do not understand the reason for Bernard's
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 ti
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:
>
> *
This is a call for adoption of draft-dekok-emu-tls-eap-types
(https://datatracker.ietf.org/doc/draft-dekok-emu-tls-eap-types/) as a
working group item.
Please indicate if you have any objections by May 4th, 2020.
Joe and Mohit
___
Emu mailing list
d I prefer TEAP being addressed in a
separate update document that fixes all other TEAP errata as well.
However, this can be discussed after adoption.
A working group adoption call is now issued and we intend to move this
document forward rapidly.
--Mohit
>
> Alan DeKok.
>
> __
://doodle.com/poll/vxy5vc4g3cnegpdr
Please indicate your availability!
Joe and Mohit
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
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,
eap-noob.net as a reserved/special use domain.
--Mohit
On 4/22/20 12:29 PM, Max Crone wrote:
> While implementing EAP-NOOB, I found the explanation on the Invalid
> NAI (error code 1001) in the draft to be unclear.
>
> The document formulates it as follows:
> > If the NAI st
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
The poll is now closed. We will have a 90-minute virtual interim meeting
for EMU on May 22nd, 2020 between 15:00-16:30 UTC.
Please send in requests for presentations. Don't forget to include the
title, approximate time needed, and any associated drafts.
--Mohit
On 4/24/20 3:45 PM,
.
Joe and Mohit
On 4/20/20 1:53 AM, Mohit Sethi M wrote:
> This is a call for adoption of draft-dekok-emu-tls-eap-types
> (https://datatracker.ietf.org/doc/draft-dekok-emu-tls-eap-types/) as a
> working group item.
>
> Please indicate if you have any objections by May 4th, 2020.
&g
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:
you can find a few more clarifications for the
changes I made.
--Mohit
On 3/24/20 10:00 AM, Hannes Tschofenig wrote:
> Hi Michael, Hi draft authors,
>
>> I was surprised to get to the end of the document without any suggestions
>> about sending certificates by reference rather th
e 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
&
/materials/minutes-interim-2020-emu-01-202005221800
Bluesheets:
https://www.ietf.org/proceedings/interim-2020-emu-01/bluesheets/bluesheets-interim-2020-emu-01-202005221800-00.txt
Please report any issues by June 1, 2020.
Joe and Mohit
___
Emu mailing
-00) is still 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 Sa
.
--Mohit
On 5/28/20 9:31 PM, Roman Danyliw wrote:
> Hi!
>
> I performed an AD review of draft-ietf-emu-eap-tls13-09. Thanks for the work
> on modernizing existing guidance to cover TLS 1.3.
>
> Two high level things caught my attention:
>
> ** The abstract, introduction and ti
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-04
Please see in-line for some details.
--Mohit
On 6/8/20 3:19 PM, Hannes Tschofenig wrote
.
--Mohit
On 6/10/20 12:02 PM, Hannes Tschofenig wrote:
Thanks for the update.
A few more minor comments on -04:
Section 4.1:
"TLS 1.3 [https://tools.ietf.org/html/rfc8446] requires implementations to support
ECC."
This is only true absent an application profile defining something els
yVdVr8Vjyk9D-vk/
- https://mailarchive.ietf.org/arch/msg/emu/CRh3VXLDnpJFFIbHWJAjiOgfzAg/
- https://mailarchive.ietf.org/arch/msg/emu/nYrIA4PKqk2mrUoNvAtFh7S-Xb8/
- https://mailarchive.ietf.org/arch/msg/emu/hVG357HXqvy0EjZ2yrOLdspH53o/
--Mohit
Ciao
Hannes
IMPORTANT NOTICE: The contents of thi
d an EAP-
Success, an EAP-Failure, or an EAP-Request with a TLS Alert Message.
Thus, the current design decision has been guided by parallel implementation
experience and it is the best solution we could come up with (given all the
practical limitations).
--Mohit
On 6/12/20 11:36 AM, H
Hi Hannes,
On 6/16/20 12:37 PM, Hannes Tschofenig wrote:
Hi Mohit,
I had a chance to read through the emails you provided. A good
discussion.
I can offer three solutions:
1. Use EAP-Success / EAP-Failure as an indication for the completion
of the exchange, even if it is not a
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
33 bytes? And wouldn't it make sense to explicitly say that this is an
octet string in the compressed format while referencing "SEC 1: Elliptic
Curve Cryptography, Version 2.0" for the point to octet string
conversion rules?
--Mohit
On 5/26/20 9:57 AM, internet-dra...@ietf.org wr
is. Compare this with other
EAP methods such as EAP-TEAP (https://tools.ietf.org/html/rfc7170) which
were standardized and went on to become an RFCs with no known
implementations and were later found to contain a bunch of errata
(https://www.rfc-editor.org/errata/rfc7170). Thanks to Eliot, Oleg,
Jorge, Joe, and others who are now fixing them.
I see no actionable points in this review and consider it addressed.
--Mohit
>
>
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
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 "Curve2551
imate amount of time needed.
Joe and Mohit
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
rmat would also be
beneficial.
--Mohit
On 6/24/20 11:04 PM, Russ Housley wrote:
The ECDH public value in RFC 5480 is an OCTET STRING, which means that the
value is exactly 32 bytes. When this gets carried as a subject public key in a
certificate, there is an extra byte only because the type is
1 - 100 of 172 matches
Mail list logo
